Не слишком ли рано начинать разработку для Task Parallel Library?

Question

Я с большим интересом следил за разработкой .NET Task Parallel Library (TPL) с тех пор, как Microsoft впервые объявила об этом.

Я не сомневаюсь, что в конечном итоге мы воспользуемся преимуществами TPL. Что меня интересует, так это то, имеет ли смысл начать использовать преимущества TPL после выпуска Visual Studio 2010 и .NET 4.0, или имеет смысл подождать немного дольше.

Зачем начинать сейчас?

• Параллельная библиотека задач .NET 4.0 выглядит хорошо разработанной, и некоторые относительно простые тесты показывают, что она хорошо работает на современных многоядерных процессорах.
• Меня очень интересовали потенциальные преимущества использования нескольких легких потоков для ускорения работы нашего программного обеспечения с момента покупки моего первого четырехъядерного процессора Dell Poweredge 6400 около семи лет назад. Эксперименты того времени показали, что это не стоит затраченных усилий, что я во многом приписал накладным расходам на перемещение данных между кешем каждого ЦП (тогда еще не было общего кеша) и оперативной памятью.
• Конкурентное преимущество - некоторые наши клиенты никогда не смогут получить достаточную производительность, и нет никаких сомнений в том, что сегодня мы можем создать более быстрый продукт с использованием TPL.
• Звучит весело. Да, я понимаю, что некоторые разработчики предпочли бы совать себя в глаза острой палкой, но нам действительно нравится максимизировать производительность.

Зачем ждать?

• Представляют ли сегодняшние процессоры Intel Nehalem направление развития многоядерной поддержки? Вы можете приобрести ЦП Nehalem с 4 ядрами, которые сегодня используют кэш-память одного уровня 3, и, скорее всего, к моменту выпуска Visual Studio 2010 / .NET 4.0, 6-ядерный процессор будет использовать кэш-память одного уровня 3. Очевидно, что количество ядер будет со временем увеличиваться, но как насчет архитектуры? По мере увеличения количества ядер они все еще будут использовать кеш? Одной из проблем Nehalem является тот факт, что, несмотря на очень быстрое соединение между ядрами, они имеют неравномерный доступ к памяти (NUMA), что может привести к снижению производительности и менее предсказуемым результатам. Смогут ли будущие многоядерные архитектуры избавиться от NUMA?
• Аналогично, изменится ли библиотека параллельных задач .NET по мере ее развития, что потребует внесения изменений в код, чтобы полностью использовать ее преимущества?

Ограничения

• Наш основной механизм на 100% состоит из C # и должен работать без полного доверия, поэтому мы ограничены использованием .NET API.

Answer 1

Я бы начал сейчас. Я сильно подозреваю, что мы видели большую часть изменений - даже если в кандидате на релиз есть несколько твиков, я уверен, что они будут хорошо документированы в блоге команды PFX и просты. изменить. Даже если чипы изменятся, я ожидал бы, что TPL адаптируется соответствующим образом в будущих версиях - и я лично ожидал бы, что текущий TPL все еще будет лучше справляться с этими новыми чипами, чем любой ручной код, основанный на потоках, таких простых смертных, как мы могли бы написать.

Единственный недостаток, который я вижу, начиная с сегодняшнего дня, это то, что учебные ресурсы еще не созданы. Есть некоторая документация, некоторые посты в блоге (некоторые из которых уже устарели) и некоторые примеры кода - но нет книг, посвященных PFX. Я уверен, что они придут вовремя - и если вы в начале игры, вы могли бы даже написать один:)

В зависимости от вашего приложения вы также можете посмотреть Reactive Extensions , который работает рука об руку с PFX.

Answer 2

Я бы тоже не стал ждать.

На самом деле, я бы пошел дальше и сказал: не ждите VS2010 / .NET 4.0. TPL теперь доступен для .NET 3.5 как часть Реактивных расширений для .NET .

Answer 3

Я бы тоже пошел на это. Большим изменением, на мой взгляд, является переход «парадигмы» от разработки «мы сделали это таким образом в течение последних 8 лет» к более функциональному программированию без побочных эффектов.

Если вы начнете использовать PFX сегодня, я предполагаю, что потребуется некоторое время, чтобы освоиться с ним и буквально перенести ваш код, чтобы извлечь из него максимальную пользу. С другой стороны, если PFX исчезнет через 2 года или принесет серьезные изменения, я ожидаю, что ваш код все еще будет работать намного лучше, используя то, что вы получите. Мы больше не будем уменьшать количество ядер, и большие задачи для лучшего масштабирования не устареют довольно долго.

Относительно изменений архитектуры процессора: я не могу их прокомментировать, за исключением того, что, по моему мнению, ваши инвестиции сейчас приведут к бизнес-преимуществу уже через + X месяц. Вероятно, X меньше времени, когда произойдут серьезные изменения в разработке CPU -> Вы выиграли.

Answer 4

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

Я бы сказал (это только предположение - особенно в области компьютерных наук вы никогда не сможете сказать, что будет дальше): Да, они изменятся. И да, TPL будет изменен в некоторых точках, чтобы максимизировать производительность. Однако некоторые изменения будут скрыты - вы получите выгоду от оптимизации, фактически не изменив ни одной строки кода.

И даже если есть изменения в архитектурах, которые приводят к повышению производительности только в комбинации, которая меняет ваш код: я не думаю, что эти изменения будут влиять на весь ваш код - возможно, некоторые проценты были бы важны каждую миллисекунду.

А где альтернативы? Используя Threadpool? Что ж, тогда TPL намного более актуален. Следовательно, ваш код будет более перспективным при использовании IMHO. Например, демонстрации отладочных функций VS 2010 выглядят довольно неплохо.

Кроме того, мне кажется, что TPL достаточно гибок - если он не подходит для конкретной ситуации, вам не нужно использовать его там. С другой стороны, это упрощает разработку в других местах.

Я думаю, что сегодня самое важное - подумать о распараллеливании и включить его в архитектуру. TPL значительно облегчает этот процесс.

Поэтому мой вывод: используйте это!

Answer 5

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

Я думаю, что сначала нужно ответить на эти вопросы, чтобы у них была более четкая картина, чтобы оценить, может ли TPL помочь в будущем.