Аннотация:
В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...
Мы уже победили, просто это еще не так заметно...
Re: Эпоха параллельности.Способы выживания в эпоху многоядер
Здравствуйте, Иван Бодягин, Вы писали:
ИБ>другой же стороны – действует хорошо известный закон Мура, говорящий, что число транзисторов увеличивается в два раза за год, и при этом означенное увеличение, до недавнего времени, фактически приводило к линейному росту производительности.
Экспоненциальному.
Re: Эпоха параллельности.Способы выживания в эпоху многоядер
... исключение так и не было обработано основным потоком, Task пропихивает это исключение в поток финализации, и оно выбрасывается там, что вызывает отработку стандартной для всех неперехваченных исключений логики.
Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?
Спасибо за статью!
Re[2]: Эпоха параллельности.Способы выживания в эпоху многоя
ИБ>>другой же стороны – действует хорошо известный закон Мура, говорящий, что число транзисторов увеличивается в два раза за год, и при этом означенное увеличение, до недавнего времени, фактически приводило к линейному росту производительности.
Обратно-степенному.
Re[2]: Эпоха параллельности.Способы выживания в эпоху многоя
S>Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?
именно так:
Во времена первого фреймворка с не перехваченными исключениями, сгенерированными в отдельном потоке, предоставленном пулом потоков, поступали довольно цинично – они просто игнорировались. По многим причинам такое поведение нельзя назвать удачным, и поэтому во втором фреймворке его изменили – если исключение, сгенерированное в отдельном потоке, не было перехвачено, то это вызывает падение процесса.
где-то я читал, что в основном это было введено изза исключений в финализаторе, как раз в случае 1 фреймворка если исключение проходило в финализаторе (который происходит в другом потоке) то оно "проглатывалось", что вело к утечкам памяти.
А так не удобно,( в ерланге например, при создание "потока" указывается стратегия что будет происходит в случае exception), но в F# с его async использовать APM удобнее, вот и TPL тоже
поттянулось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re: Эпоха параллельности.Способы выживания в эпоху многоядер
Здравствуйте, Иван Бодягин, Вы писали:
ИБ>В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...
спасибо за статью, в ссылках я бы добавил еще PATTERNS OF PARALLEL PROGRAMMING
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[3]: Эпоха параллельности.Способы выживания в эпоху многоя
Здравствуйте, cadet354!
S>>Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?
C>именно так:
Ну почему???
Вы уточняйте — BCL такой разный. Например исключение в ThreadPool проглатывается. Remoting кидает исключение на клиенте. WinForms Application тоже ведёт себя нестандартно, а петля сообщений драг-дропа вообще молча проглатывает все исключения без шанса увидеть "а шо это было?".
S>Вы уточняйте — BCL такой разный. Например исключение в ThreadPool проглатывается. Remoting кидает исключение на клиенте. WinForms Application тоже ведёт себя нестандартно, а петля сообщений драг-дропа вообще молча проглатывает все исключения без шанса увидеть "а шо это было?".
мы тут вроде про исключения при многопоточности говорим, а не как это сделано в разных библиотеках например ведь еще есть ССR.
S>Не, я логики на понял — зачем изобретать ещё одну политику обработки неотловленных исключений??? Обобщили бы с Thread-пулом уже что ли...
первый подход неудачный, второй так себе, а вот с третьей попытки наконец сделаем как надо
S>Короче говоря, уже пора писать свои обработчики
это ты про что?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[5]: Эпоха параллельности.Способы выживания в эпоху многоя
Здравствуйте, cadet354, Вы писали:
C>мы тут вроде про исключения при многопоточности говорим, а не как это сделано в разных библиотеках например ведь еще есть ССR.
Не понял... а разве TPL не есть ещё одна библиотека? Вон вполне многопоточный пул исключения мирно проглатывает. Я не говорю, что это есть хорошо. Пойнт — в нарастающем разброде в подходах.
C>первый подход неудачный, второй так себе, а вот с третьей попытки наконец сделаем как надо
Ну блин, а что делать бедному коду, завязанному на пул? Его чую побольше будет, чем использующего TPL.
S>>Короче говоря, уже пора писать свои обработчики C>это ты про что?
Про велосипед типа InvokeHelper.InvokeAsync(callback, FailBehavior.ThrowOnSourceThread);
Re[6]: Эпоха параллельности.Способы выживания в эпоху многоя
Здравствуйте, 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!}
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re: Эпоха параллельности.Способы выживания в эпоху многоядер
ИБ>Авторы: ИБ> Иван Бодягин
ИБ>Аннотация: ИБ>В статье рассказывается о борьбе с многоядерным параллелизмом в .NET, о том, что Microsoft планирует сделать в этом направлении и что нас ждет в ближайшем будущем, когда нам придется жить в многоядерную эпоху...
Опечатка:
WithDegreeOfParallelism(...)
Позволяет ограничить число потоков, отданных на распараллеливание данного запроса. Например, следующий код ограничит число потоков четырьмя:
var result = from s in source.AsParallel().WithDegreeOfPErellelism(4) where ... select ...
Здравствуйте, Sinix, Вы писали:
S>Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"?
Угу, типа того. Не перехватил — сам виноват.
S>Спасибо за статью!
Пожалуйсто.. )
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[2]: Эпоха параллельности.Способы выживания в эпоху многоя
Здравствуйте, cadet354, Вы писали:
C>спасибо за статью, в ссылках я бы добавил еще PATTERNS OF PARALLEL PROGRAMMING
она вышла позже, чем я отдал статью в редакцию, ну пусть здесь будет.. )
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[3]: Эпоха параллельности.Способы выживания в эпоху многоя
Здравствуйте, IB, Вы писали:
S>>Что-то я сомневаюсь что исключение бросается в потоке финалайзера. Типа "я умру — все умрут"? IB>Угу, типа того. Не перехватил — сам виноват.
А не слишком ли сурово? Допустим, для хостов с кучей доменов это однозначно big no-no. Почему бы не использовать дефолтное де факто поведение
Re[4]: Эпоха параллельности.Способы выживания в эпоху многоя
Здравствуйте, Sinix, Вы писали:
S>А не слишком ли сурово?
По мне так в самый раз.
S> Допустим, для хостов с кучей доменов это однозначно big no-no. Почему бы не использовать дефолтное де факто поведение
Потому что это поведение не очень корретно и хотели его изменить...
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re: Эпоха параллельности.Способы выживания в эпоху многоядер
ИМХО статья очень слабая. Представлена только справочная информация без аналитики вообще. Какой в ней смысл, всё что описано есть в том же виде в открытых источниках. Хотелось бы например видеть жизненные примеры применения новых примитивов синхронизации/lock free коллекций, а не краткого и местами непонятного их описания
Народная мудрось
всем все никому ничего(с).
Re: Эпоха параллельности.Способы выживания в эпоху многоядер
ну статья похоже о том, как забрать все процессорное время себе Единственное, для чего это может быть полезно, для долгих мат. вычислений. И причем, если они настолько долгие, то опять же забирать все процессорное время выглядит малооправданным — отправить в фон и забыть.
Так что, imho, единственное применением для параллельного программирования по прежнему остается работа с медленным железом. В остальных случаях лучше от него отказываться в пользу более простых решений.
В итоге, если детально рассмотреть возможную предметную область, то можно сделать вывод — паниковать не надо. Актуальность статьи несколько преувеличена. Бросаться переписывать старые программы не надо. По прежнему стоит подумать, зачем заводить лишний поток себе на голову. Речь о выживании точно не идет. Статья может быть интересна только как faq по программированию многопоточных программ. Подсчеты секунд выигрыша вызывают только улыбку. Толку, что сэкономите пару секунд (точнее, отберете у других приложений), если убъете на разработку и отладку в 2 раза больше времени?
p. s. много опечаток.
p. p. s. в целом, статья понравилась, спасибо
Re: Эпоха параллельности.Способы выживания в эпоху многоядер
Возможно, я подзабыл .Net, но мне представляется, что первый наивный вариант и второй, слямзенный с MSDN, сравнивать не вполне корректно: большой объем кода во втором случае привнесен еще и из-за того, что число заданий ставится в зависимость от числа процессоров. Но разве нельзя было положить в пул потоков все size делегатов (так же, как клали size потоков в наивном варианте)? Поскольку под делегат не создается поток сразу же, то по ресурсоемкости такой вариант должен быть близок к варианту из MSDN. А код в этом случае будет весьма мало отличаться от основанного на TPL.
В чем же тогда в этом примере преимущество TPL? Лишь в том, что вместо глобальной очереди задач используется локальная очередь?
Специалист — это варвар, невежество которого не всесторонне :)
Re: Эпоха параллельности.Способы выживания в эпоху многоядер
Здесь метод AsParallel() выполняет преобразование обычного IEnumerable к некоторому типу, а конкретно, к ParallelEnumerable.
Здесь неточность. На самом деле, AsParallel() преобразует IEnumerable<T> к типу ParallelQuery<T>. А ParallelEnumerable — это статический класс, в котом определен метод-расширение AsParallel().