Слишком рано начинать разработку для параллельной библиотеки задач?

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

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

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

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

Зачем ждать?

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

Ограничения

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

На самом деле, я бы пошел дальше и говорю, не ждите VS2010/.NET 4.0. TPL доступен для .NET 3.5 теперь как часть Reactive Extensions for.NET.