Статья:
Эпоха параллельности.Способы выживания в эпоху многоядерного параллелизма

Автор(ы): Иван Бодягин
Дата: 25.01.2010
В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...

Авторы:
Иван Бодягин

Аннотация:
В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>другой же стороны – действует хорошо известный закон Мура, говорящий, что число транзисторов увеличивается в два раза за год, и при этом означенное увеличение, до недавнего времени, фактически приводило к линейному росту производительности.

Экспоненциальному.

Здравствуйте, Иван Бодягин, Вы писали:

Fork/Join без хотя бы поверхностного описания фьючерсов выглядит как то куцо.

Здравствуйте, Иван Бодягин.

... исключение так и не было обработано основным потоком, Task пропихивает это исключение в поток финализации, и оно выбрасывается там, что вызывает отработку стандартной для всех неперехваченных исключений логики.

Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?

Спасибо за статью!

ИБ>>другой же стороны – действует хорошо известный закон Мура, говорящий, что число транзисторов увеличивается в два раза за год, и при этом означенное увеличение, до недавнего времени, фактически приводило к линейному росту производительности.

Обратно-степенному.

Здравствуйте, Sinix, Вы писали:


S>Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?

именно так:

Во времена первого фреймворка с не перехваченными исключениями, сгенерированными в отдельном потоке, предоставленном пулом потоков, поступали довольно цинично – они просто игнорировались. По многим причинам такое поведение нельзя назвать удачным, и поэтому во втором фреймворке его изменили – если исключение, сгенерированное в отдельном потоке, не было перехвачено, то это вызывает падение процесса.

где-то я читал, что в основном это было введено изза исключений в финализаторе, как раз в случае 1 фреймворка если исключение проходило в финализаторе (который происходит в другом потоке) то оно "проглатывалось", что вело к утечкам памяти.

А так не удобно,( в ерланге например, при создание "потока" указывается стратегия что будет происходит в случае exception), но в F# с его async использовать APM удобнее, вот и TPL тоже
поттянулось.

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...
спасибо за статью, в ссылках я бы добавил еще PATTERNS OF PARALLEL PROGRAMMING

Здравствуйте, cadet354!

S>>Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?

C>именно так:
Ну почему???

Вы уточняйте — BCL такой разный. Например исключение в ThreadPool проглатывается. Remoting кидает исключение на клиенте. WinForms Application тоже ведёт себя нестандартно, а петля сообщений драг-дропа вообще молча проглатывает все исключения без шанса увидеть "а шо это было?".

В общем виде и разжёвано — http://msdn.microsoft.com/en-us/magazine/cc793966.aspx

C>вот и TPL тоже
C>поттянулось.

Не, я логики на понял — зачем изобретать ещё одну политику обработки неотловленных исключений??? Обобщили бы с Thread-пулом уже что ли...

Короче говоря, уже пора писать свои обработчики

Здравствуйте, Sinix, Вы писали:



S>Вы уточняйте — BCL такой разный. Например исключение в ThreadPool проглатывается. Remoting кидает исключение на клиенте. WinForms Application тоже ведёт себя нестандартно, а петля сообщений драг-дропа вообще молча проглатывает все исключения без шанса увидеть "а шо это было?".
мы тут вроде про исключения при многопоточности говорим, а не как это сделано в разных библиотеках например ведь еще есть ССR.

S>Не, я логики на понял — зачем изобретать ещё одну политику обработки неотловленных исключений??? Обобщили бы с Thread-пулом уже что ли...
первый подход неудачный, второй так себе, а вот с третьей попытки наконец сделаем как надо


S>Короче говоря, уже пора писать свои обработчики
это ты про что?

Здравствуйте, cadet354, Вы писали:

C>мы тут вроде про исключения при многопоточности говорим, а не как это сделано в разных библиотеках например ведь еще есть ССR.
Не понял... а разве TPL не есть ещё одна библиотека? Вон вполне многопоточный пул исключения мирно проглатывает. Я не говорю, что это есть хорошо. Пойнт — в нарастающем разброде в подходах.

C>первый подход неудачный, второй так себе, а вот с третьей попытки наконец сделаем как надо
Ну блин, а что делать бедному коду, завязанному на пул? Его чую побольше будет, чем использующего TPL.

S>>Короче говоря, уже пора писать свои обработчики
C>это ты про что?
Про велосипед типа InvokeHelper.InvokeAsync(callback, FailBehavior.ThrowOnSourceThread);

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, cadet354, Вы писали:

C>>мы тут вроде про исключения при многопоточности говорим, а не как это сделано в разных библиотеках например ведь еще есть ССR.
S>Не понял... а разве TPL не есть ещё одна библиотека?
библиотека для многопоточности, я к тому что remoting/wcf/winforms тут не причем.
S>Вон вполне многопоточный пул исключения мирно проглатывает. Я не говорю, что это есть хорошо. Пойнт — в нарастающем разброде в подходах.
он проглатывается в случае если APM, а если руками, то все падает:

using System;
using System.Threading;

namespace TestThreadPool
{
    class Program
    {
        static void Main(string[] args)
        {
            AutoResetEvent signal = new AutoResetEvent(false);
            int result = 0;
            ThreadPool.QueueUserWorkItem(delegate(Object o)
            {

                if (o == null)
                    throw new ArgumentNullException();
                result = 1;
                signal.Set();
            });
            signal.WaitOne();
            Console.WriteLine(result);
            Console.ReadLine();
        }
    }
}

C>>первый подход неудачный, второй так себе, а вот с третьей попытки наконец сделаем как надо
S>Ну блин, а что делать бедному коду, завязанному на пул? Его чую побольше будет, чем использующего TPL.
а что кардинально измениться, будет работать/неработь , просто в TPL стало удобно работать с прерыванием работы (интересно как они сделали, в F# прерывание наступит на следующей конструкции типа let! или do!) и исключениями.
S>>>Короче говоря, уже пора писать свои обработчики
C>>это ты про что?
S>Про велосипед типа InvokeHelper.InvokeAsync(callback, FailBehavior.ThrowOnSourceThread);
лучше F# async {let! и do!}

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Эпоха параллельности.Способы выживания в эпоху многоядерного параллелизма

Автор(ы): Иван Бодягин
Дата: 25.01.2010
В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...

ИБ>Авторы:
ИБ> Иван Бодягин

ИБ>Аннотация:
ИБ>В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...

Опечатка:

WithDegreeOfParallelism(...)

Позволяет ограничить число потоков, отданных на распараллеливание данного запроса. Например, следующий код ограничит число потоков четырьмя:

var result = from s in source.AsParallel().WithDegreeOfPErellelism(4) where ... select ...

Здравствуйте, Sinix, Вы писали:

S>Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?
Угу, типа того. Не перехватил — сам виноват.

S>Спасибо за статью!
Пожалуйсто.. )

Здравствуйте, cadet354, Вы писали:

C>спасибо за статью, в ссылках я бы добавил еще PATTERNS OF PARALLEL PROGRAMMING
она вышла позже, чем я отдал статью в редакцию, ну пусть здесь будет.. )

Здравствуйте, IB, Вы писали:

S>>Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?
IB>Угу, типа того. Не перехватил — сам виноват.

А не слишком ли сурово? Допустим, для хостов с кучей доменов это однозначно big no-no. Почему бы не использовать дефолтное де факто поведение

Здравствуйте, Sinix, Вы писали:

S>А не слишком ли сурово?
По мне так в самый раз.

S> Допустим, для хостов с кучей доменов это однозначно big no-no. Почему бы не использовать дефолтное де факто поведение
Потому что это поведение не очень корретно и хотели его изменить...

ИМХО статья очень слабая. Представлена только справочная информация без аналитики вообще. Какой в ней смысл, всё что описано есть в том же виде в открытых источниках. Хотелось бы например видеть жизненные примеры применения новых примитивов синхронизации/lock free коллекций, а не краткого и местами непонятного их описания

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Эпоха параллельности.Способы выживания в эпоху многоядерного параллелизма

Автор(ы): Иван Бодягин
Дата: 25.01.2010
В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...

ну статья похоже о том, как забрать все процессорное время себе Единственное, для чего это может быть полезно, для долгих мат. вычислений. И причем, если они настолько долгие, то опять же забирать все процессорное время выглядит малооправданным — отправить в фон и забыть.
Так что, imho, единственное применением для параллельного программирования по прежнему остается работа с медленным железом. В остальных случаях лучше от него отказываться в пользу более простых решений.
В итоге, если детально рассмотреть возможную предметную область, то можно сделать вывод — паниковать не надо. Актуальность статьи несколько преувеличена. Бросаться переписывать старые программы не надо. По прежнему стоит подумать, зачем заводить лишний поток себе на голову. Речь о выживании точно не идет. Статья может быть интересна только как faq по программированию многопоточных программ. Подсчеты секунд выигрыша вызывают только улыбку. Толку, что сэкономите пару секунд (точнее, отберете у других приложений), если убъете на разработку и отладку в 2 раза больше времени?

p. s. много опечаток.
p. p. s. в целом, статья понравилась, спасибо

Возможно, я подзабыл .Net, но мне представляется, что первый наивный вариант и второй, слямзенный с MSDN, сравнивать не вполне корректно: большой объем кода во втором случае привнесен еще и из-за того, что число заданий ставится в зависимость от числа процессоров. Но разве нельзя было положить в пул потоков все size делегатов (так же, как клали size потоков в наивном варианте)? Поскольку под делегат не создается поток сразу же, то по ресурсоемкости такой вариант должен быть близок к варианту из MSDN. А код в этом случае будет весьма мало отличаться от основанного на TPL.
В чем же тогда в этом примере преимущество TPL? Лишь в том, что вместо глобальной очереди задач используется локальная очередь?

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Эпоха параллельности.Способы выживания в эпоху многоядерного параллелизма

Автор(ы): Иван Бодягин
Дата: 25.01.2010
В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...

Здесь метод AsParallel() выполняет преобразование обычного IEnumerable к некоторому типу, а конкретно, к ParallelEnumerable.

Здесь неточность. На самом деле, AsParallel() преобразует IEnumerable<T> к типу ParallelQuery<T>. А ParallelEnumerable — это статический класс, в котом определен метод-расширение AsParallel().

Здравствуйте, IB, Вы писали:

S>> Допустим, для хостов с кучей доменов это однозначно big no-no. Почему бы не использовать дефолтное де факто поведение
IB>Потому что это поведение не очень корретно и хотели его изменить...

Зато теперь корректно, но в случае ASP.NET одно непойманное исключение в рабочем потоке убивает все приложения в процессе, даже если они в других доменах.

Здравствуйте, ausergiy, Вы писали:

A>Подсчеты секунд выигрыша вызывают только улыбку. Толку, что сэкономите пару секунд (точнее, отберете у других приложений), если убъете на разработку и отладку в 2 раза больше времени?

А как насчёт экономии десятков минут при убиении на разработку и отладку пары секунд?

Здравствуйте, Иван Бодягин, Вы писали:

Не знаю, возможно когда статья писалась то использовалась более старая версия TPL, или просто опечатка, но в TPL которая включена в Release Candidate
вместо

      for (int i = 0; i < size; i++)
      {
        tasks.Add(new Task(ti =>
        {
          int ii = (int)ti;
          for (int j = 0; j < size; j++)
          {
            result[ii, j] = 0;
            for (int k = 0; k < size; k++)
            {
              result[ii, j] += m1[ii, k] * m2[k, j];
            }
          }
        }, i));
      }

нужно использовать

for (int i = 0; i < size; i++)
{
    var task = new Task(ti =>
    {
        int ii = (int)ti;
        for (int j = 0; j < size; j++)
        {
            result[ii, j] = 0;
            for (int k = 0; k < size; k++)
            {
                result[ii, j] += m1[ii, k] * m2[k, j];
            }
        }
    }, i);
    task.Start();
    tasks.Add(task);
}