Комментарии 29
Спасибо за статью.
Рад стараться :) Во второй части расскажу про уже про конкретные библиотечные классы, как с ними работать, какие потенциальные подводные камни.
Следующая статья будет по Task и объектам синхронизации как я понимаю?
Лично мне было бы чуть более интересней почитать про практику использования PLINQ с .NET 4.0 — в основном примеры значимого отличия простого выполнения и AsParallel
Просто кроме них в 4.0 разве что слимовые варианты некоторых классов (те же барьеры) да и все.
В общем ждем PLINQ :)
Просто кроме них в 4.0 разве что слимовые варианты некоторых классов (те же барьеры) да и все.
В общем ждем PLINQ :)
А что там не понятного то в plinq. директива AsParallel спасет мир. Ставится ограничение на количество выполняемых потоков, если правельон помню, можно еще Шедулер свой подставить.
Вроде бы ранее еще и ошибка могла выпасть не 1 а множество, и по этому отлавливать надо было не nullreference exeption, а другую(упамятовал сейчас какую. Общий смысл, что это ошибка, которая внутри себя имеет массив ошибок, с длинной от 1, до числа потоков, на которых запускалось вычисление выражения )
Так, что вроде как plinq- это вторая часть по прозрачности, после FOR, Foreach
В книге, как раз по моему это и указывается. Там постоянно паттерн- map-reduce и получатель отправитель фигурирует. Так, что особо ничего сложного вроде.
Вроде бы ранее еще и ошибка могла выпасть не 1 а множество, и по этому отлавливать надо было не nullreference exeption, а другую(упамятовал сейчас какую. Общий смысл, что это ошибка, которая внутри себя имеет массив ошибок, с длинной от 1, до числа потоков, на которых запускалось вычисление выражения )
Так, что вроде как plinq- это вторая часть по прозрачности, после FOR, Foreach
В книге, как раз по моему это и указывается. Там постоянно паттерн- map-reduce и получатель отправитель фигурирует. Так, что особо ничего сложного вроде.
Ну дело в том, что лично я пробовал использовать AsParallel в реальных проектах, но даже при практически полной независимости блоков итерирования, паралеливания я не замечал. Даже когда указывал точные параметры в виде количества потоков и т.д.
Может я что-то не так делал, но вот по этому и интересуют простые практические примеры, которые можно загрузить-запустить-посмотреть как именно идет выполнение.
В сети довольно много скорее академических примеров — типа «а вычислим число пи» или «отсортируем ка...» и т.д., но на практике основные ботл-неки где нужно паралелить идут в других местах.
Может я что-то не так делал, но вот по этому и интересуют простые практические примеры, которые можно загрузить-запустить-посмотреть как именно идет выполнение.
В сети довольно много скорее академических примеров — типа «а вычислим число пи» или «отсортируем ка...» и т.д., но на практике основные ботл-неки где нужно паралелить идут в других местах.
Надо понимать, что эта книга (статья, на самом деле) доступна ко свободному скачиванию всеми желающими.
www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=86b3d32b-ad26-4bb8-a3ae-c1637026c3ee
www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=86b3d32b-ad26-4bb8-a3ae-c1637026c3ee
Спасибо за статью. Как раз столкнулся с подобным случаем. Только у меня вопрос — не лучше ли использовать для таких вещей F#? Я уже какое-то время ищу повод познакомиться с ним поближе.
Честно говоря, я слышал, что в F# есть весьма нативная поддержка параллельности, но не знаю подробностей, поэтому не могу сказать, лучше или нет)
Во всяком случае, познакомиться с тем, что F# умеет в этой сфере, я думаю, очень полезно.
А тут рассмотрены общие подходы, реализация на C# просто для удобства. А во второй части будет про библиотечные классы, и весьма вероятно, что реализация параллелизма в F# строится на них же.
Во всяком случае, познакомиться с тем, что F# умеет в этой сфере, я думаю, очень полезно.
А тут рассмотрены общие подходы, реализация на C# просто для удобства. А во второй части будет про библиотечные классы, и весьма вероятно, что реализация параллелизма в F# строится на них же.
Меня вот поражает сила pr технологий.
На F# как и на остальных языках пишут 1% людей, но в каждой статье про C#, кто-нибудь о функциональщине да вспомнит.
openmp для плюсов, tpl для C#-это способ быстрого распараллеливания последовательного кода. находится тяжелый цикл и быстро правится на Parallel.For Parallel.Foreach.(#pragma omp parallel for).
Это идеология. Быстро распараллелить последовательный код.
Если пишешь на функциональном языке- то это уже не укладывается в рамки идеологии, быстрого распараллеливания последовательного кода. Тут сразу сидишь и взрываешь мозг как это вообще представить в функциональной парадигме.
Нужно провести опрос:
Вот сколько читателей этой статьи написало больше, чем Hellow Word на F#
И при этом, кто задумывался о том, что бы вообще F# попробовать.
Думаю благодаря рекламе, хотели попробовать все, а сложнее hellow word писала 1-2 человека на тысячу .net программистов
Если хочется писать, что то более специфичное, чем банальные параллельные for foreach тут придется писать уже на Task в .net 4.0.
На F# как и на остальных языках пишут 1% людей, но в каждой статье про C#, кто-нибудь о функциональщине да вспомнит.
openmp для плюсов, tpl для C#-это способ быстрого распараллеливания последовательного кода. находится тяжелый цикл и быстро правится на Parallel.For Parallel.Foreach.(#pragma omp parallel for).
Это идеология. Быстро распараллелить последовательный код.
Если пишешь на функциональном языке- то это уже не укладывается в рамки идеологии, быстрого распараллеливания последовательного кода. Тут сразу сидишь и взрываешь мозг как это вообще представить в функциональной парадигме.
Нужно провести опрос:
Вот сколько читателей этой статьи написало больше, чем Hellow Word на F#
И при этом, кто задумывался о том, что бы вообще F# попробовать.
Думаю благодаря рекламе, хотели попробовать все, а сложнее hellow word писала 1-2 человека на тысячу .net программистов
Если хочется писать, что то более специфичное, чем банальные параллельные for foreach тут придется писать уже на Task в .net 4.0.
F# пиарят знатно, не спорю. Но интерес к ФП как таковому, мне кажется, вещь очень правильная, для структурирования сознания.
В конце концов, именно благодаря возросшему интересу к ФП в сообществе в целом (в том числе и внутри команды MS) мы сейчас на C# пишем в гораздо более функциональном (и удобном) стиле, чем раньше.
Цепочки запросов LINQ; функции высшего порядка везде в FCL; Resharper норовит всё что можно объявить как readonly — это всё ведь следствия сближения mainstream languages с миром ФП.
Nemerle был очень классным примером тоже, многое из него вошло частью в современный C#, частью в F#.
В конце концов, именно благодаря возросшему интересу к ФП в сообществе в целом (в том числе и внутри команды MS) мы сейчас на C# пишем в гораздо более функциональном (и удобном) стиле, чем раньше.
Цепочки запросов LINQ; функции высшего порядка везде в FCL; Resharper норовит всё что можно объявить как readonly — это всё ведь следствия сближения mainstream languages с миром ФП.
Nemerle был очень классным примером тоже, многое из него вошло частью в современный C#, частью в F#.
Кругозор, общее понимание- это не плохо. Я сейчас python в реинкорнации ironpython изучаю, тк функциональные языки я не воспринимаю. Так сказать, первый шаг к пониманию, а то совсем закостенеет мозг.
Что из функциональных языков в C# пришло только простое и лучшее-это хорошо. Но даже Linq довольно не просто для начала, и далеко не все его применяют. Меня вот научил именно Resharper применять простейшие linq выражения для агрегации данных. То, что Resharper пытается все пометить какReadOnly- это не ФП, это элементарный принц минимума привилегий. Переменные, которые не меняются, должно быть объявлены константами.
Есть многие вещи, которые не понятны. То же каррирование, функции высших порядков. Вот какие вещи как цитирование в Nemerlie лично для меня остается загадкой. Был 7 числа доклад в НИВЦ МГУ про расширяемые языки, как раз на примере nemerlie. Я в итоге понял, что это все попахивает шаманизмом.
Код даже элементарный становится ну совершенно не читабельным.
Просто от этой Рекламы, у многих уже башня съела. Все уверены стали, что одни они F# не знают и не пишут на нем. И надо срочно его изучать. Это прям как вирус. Все быстро встали и пошли бороться за демократию и отдавать деньги в МММ. 50 лет функциольные языки не могут составить достойной конкуренции обычным императивным в энтерпрайз разработке, да и много еще где, а вот как вышел F# и реклама по нему такая пошла убойная, так все срочно поверили, что функциональщина- это круто.
Извините, за оффтоп. Просто накипело. Есть тут коллеги, такие же молодые как и я, у них просто мозг промыт этой рекламой.
Что из функциональных языков в C# пришло только простое и лучшее-это хорошо. Но даже Linq довольно не просто для начала, и далеко не все его применяют. Меня вот научил именно Resharper применять простейшие linq выражения для агрегации данных. То, что Resharper пытается все пометить какReadOnly- это не ФП, это элементарный принц минимума привилегий. Переменные, которые не меняются, должно быть объявлены константами.
Есть многие вещи, которые не понятны. То же каррирование, функции высших порядков. Вот какие вещи как цитирование в Nemerlie лично для меня остается загадкой. Был 7 числа доклад в НИВЦ МГУ про расширяемые языки, как раз на примере nemerlie. Я в итоге понял, что это все попахивает шаманизмом.
Код даже элементарный становится ну совершенно не читабельным.
Просто от этой Рекламы, у многих уже башня съела. Все уверены стали, что одни они F# не знают и не пишут на нем. И надо срочно его изучать. Это прям как вирус. Все быстро встали и пошли бороться за демократию и отдавать деньги в МММ. 50 лет функциольные языки не могут составить достойной конкуренции обычным императивным в энтерпрайз разработке, да и много еще где, а вот как вышел F# и реклама по нему такая пошла убойная, так все срочно поверили, что функциональщина- это круто.
Извините, за оффтоп. Просто накипело. Есть тут коллеги, такие же молодые как и я, у них просто мозг промыт этой рекламой.
Абсолютно согласен, и самое плохое, что в ФП вообще и F# в частности ринулись все кому не лень. Даже те, кто толком на императивных языках не научился писать и «думать». Напоминает ситуацию с бумом UML, когда на курсы по нему посылали всех и все считали своим долгом потом показать «корочки», а когда пришлось применять его на практике они такое воротили, что потом живые мёртвым завидовали, самое главное они считали, что нужно нарисовать диаграмму, а код сам напишется. Сейчас фишка — ФП, и все бросились его срочно учить. ФП требует довольно серьёзной мат.подготовки и писать на ФП языках эффективно по брошюркам от Майкрософт не получится. Для начала нужно разобраться, что такое языки программирования и чем функциональные отличаются от императивных. И что такое лямбда-исчисление, карринг, категории и их частный случай монады, порядок функций и пр. нужно изучить и самое главное понять до того как учить какой-либо функциональный язык программирования. Вот когда всё это вы станете понимать, тогда запись программы на функциональном языке вам покажется простой и естественной. И ещё раз подчеркну — для понимания и эффективного использования ФП нужна серьёзная база и заинтересованность, а не курсы повышения квалификации и не книжки ФП за 21 день.
Согласен. С непривычки «Практику ФП» с примерами на Haskell было непросто прорабатывать, и пришлось многое узнать, чтобы оно «пошло».
Ну, волна как нашла, так и схлынет, вместе со всеми поверхностно подошедшими товарищами. А те, кто смог подойти к вопросу более серьёзно, думаю, неплохо повысят свой профессиональный уровень.
Ну, волна как нашла, так и схлынет, вместе со всеми поверхностно подошедшими товарищами. А те, кто смог подойти к вопросу более серьёзно, думаю, неплохо повысят свой профессиональный уровень.
А каких проблем мне это должно помочь избежать?
У меня в TPL есть заранее определенный ParallelFor — им и небходимо пользоваться, а не изобретать велосипед.
Или же предлагается для каждого отдельного случая писать свою реализаю, читай делать копипаст из этой книги?
Отдельно: То что в TPL нет единого/глобального механизма управления Scheduler'ом (извините, русского слова не вспомнил) — это минус TPL.
Да, не спорю, есть возможность переопределить для некоторых конструкций свой, но это не панацея и Scheduler два экрана текста занимает.
ЗЫ. Спасибо, Вы вдохновили меня написать серию статей с обзором PPL, TPL, TBB, Cilk.
У меня в TPL есть заранее определенный ParallelFor — им и небходимо пользоваться, а не изобретать велосипед.
Или же предлагается для каждого отдельного случая писать свою реализаю, читай делать копипаст из этой книги?
Отдельно: То что в TPL нет единого/глобального механизма управления Scheduler'ом (извините, русского слова не вспомнил) — это минус TPL.
Да, не спорю, есть возможность переопределить для некоторых конструкций свой, но это не панацея и Scheduler два экрана текста занимает.
ЗЫ. Спасибо, Вы вдохновили меня написать серию статей с обзором PPL, TPL, TBB, Cilk.
Смысл первой части — дать представление о том, грубо говоря, между чем и чем мы выбираем, распарралеливая код.
Да, пользоваться надо готовым методом, но надо же понимать, в чём смысл его настроек, чтобы пользоваться им эффективно. Для этого и нужно иметь представление о том, как он может быть реализован.
Да, пользоваться надо готовым методом, но надо же понимать, в чём смысл его настроек, чтобы пользоваться им эффективно. Для этого и нужно иметь представление о том, как он может быть реализован.
В том то дело — как пользоваться настройками вы и не написали, а дали три готовых реализации.
А как подкрутить их в говотом методе, так и не объяснили.
Например через настройку Scheduler'а, о которой я упоминал:
ParallelOptions options = new ParallelOptions();
// Construct and associate a custom task scheduler
options.TaskScheduler = new TwoThreadTaskScheduler();
Parallel.For(
0,
10,
options,
(i, localState) =>
{
Console.WriteLine(«i={0}, Task={1}, Thread={2}», i, Task.CurrentId, Thread.CurrentThread.ManagedThreadId);
}
);
А как подкрутить их в говотом методе, так и не объяснили.
Например через настройку Scheduler'а, о которой я упоминал:
ParallelOptions options = new ParallelOptions();
// Construct and associate a custom task scheduler
options.TaskScheduler = new TwoThreadTaskScheduler();
Parallel.For(
0,
10,
options,
(i, localState) =>
{
Console.WriteLine(«i={0}, Task={1}, Thread={2}», i, Task.CurrentId, Thread.CurrentThread.ManagedThreadId);
}
);
Таки поэтому-то я несколько раз написал, что про работу с библиотечными классами будет вторая часть — habrahabr.ru/blogs/net/104103/ :)
Вот ещё кстати на эту же тему неплохая статья msdn.microsoft.com/ru-ru/magazine/cc163340.aspx
Я кстати тоже когда-то под влиянием PFX написал код для .NET Fw 2: www.rsdn.ru/forum/dotnet/2961492.1.aspx
Кто бы написал про многопоточность вне контекста распараллеливания расчета эталанного фрактала мендельбра… мендельбро… ну вообщем этого самого :(. Ведь ее, родимую, еще и для выноса блокирующих операций используют. Но всем неинтересны блокирующие операции а интересно побыстрее фрактал рассчитать :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распараллеливание задач. Случай «идеальной параллельности». Часть 1