Не слишком ли рано начинать разработку библиотеки параллельных задач?

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, и, скорее всего, 6-ядерный процессор, использующий один кеш уровня 3, к моменту выпуска Visual Studio 2010/.NET 4.0.Очевидно, что количество ядер со временем будет увеличиваться, но как насчет архитектуры?С увеличением количества ядер они по-прежнему будут использовать общий кеш?Одной из проблем Nehalem является тот факт, что, несмотря на очень быстрое соединение между ядрами, они имеют неравномерный доступ к памяти (NUMA), что может привести к снижению производительности и менее предсказуемым результатам.Смогут ли будущие многоядерные архитектуры покончить с NUMA?
• Аналогично, будет ли меняться .NET Task Parallel Library по мере ее развития, требуя внесения изменений в код, чтобы в полной мере воспользоваться ее преимуществами?

Ограничения

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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