Слишком рано, чтобы начать разрабатывать для Библиотеки Параллели Задачи?
Я следовал за разработкой Библиотеки параллели задачи (TPL).NET с большим интересом, так как Microsoft сначала объявила об этом.
Нет сомнения, что в моем уме, что мы в конечном счете используем в своих интересах TPL. То, что я подвергаю сомнению, - имеет ли смысл начинать использовать в своих интересах TPL, когда Visual Studio, 2010 и.NET 4.0 выпущены, или имеет ли смысл ожидать некоторое время дольше.
Почему запускаются теперь?
- .NET 4.0 Библиотеки Параллели Задачи, кажется, хорошо разработаны и некоторые относительно простые тесты, демонстрирует, что они работают хорошо над сегодняшними многоядерными центральными процессорами.
- Я очень интересовался потенциальными преимуществами использования нескольких легких потоков для ускорения нашего программного обеспечения начиная с покупки моего первого квадратического процессора Dell PowerEdge 6400 приблизительно семь лет назад. Эксперименты в то время указали, что это не стоило усилия, которое я приписал в основном издержкам движущихся данных между кэшем каждого ЦП (не было никакого общего кэша тогда), и RAM.
- Конкурентное преимущество - некоторые наши клиенты никогда не могут получать достаточно производительности и нет сомнения, что мы можем создать более быстрый продукт с помощью TPL сегодня.
- Это звучит как забава. Да, я понимаю, что некоторые разработчики ввели бы себя по абсолютному адресу в глазу с резкой палкой, но мы действительно любим максимизировать производительность.
Почему ожидают?
- Действительно ли сегодняшние центральные процессоры Intel Nehalem являются представительными для того, куда мы идем, поскольку многоядерная поддержка назревает? Можно купить ЦП Nehalem с 4 ядрами, которые совместно используют единственный кэш уровня 3 сегодня и скорее всего 6 ядер процессора, совместно использующих единственный кэш уровня 3 к этому времени Visual Studio 2010/.NET 4.0 выпущена. Очевидно, количество ядер будет повышаться со временем, но что относительно архитектуры? Когда количество ядер повышается, они все еще совместно используют кэш? Одной проблемой с Nehalem является то, что, даже при том, что существует очень быстрое межсоединение между ядрами, у них есть неоднородный доступ к памяти (NUMA), который может вести для понижения производительности и менее предсказуемых результатов. Будущая многоядерная архитектура будет в состоянии покончить с NUMA?
- Точно так же Задача.NET будет Параллельна изменению Библиотеки, как это назревает, требуя, чтобы модификации кодировали, чтобы полностью использовать в своих интересах его?
Ограничения
- Наш базовый механизм является 100%-м C# и должен работать без полного доверия, таким образом, мы ограничены использованием API.NET.
5 ответов
Я бы начал сейчас. Я настоятельно подозреваю, что мы видели основную часть изменений - даже если есть несколько твиков в кандидате освобождения, я уверен, что они будут хорошо документированы в блоге PFX Blog и легко изменить. Даже если обломоки меняются, я ожидаю, что TPL адаптировать подходящие в будущих версиях - и я бы лично ожидал, что текущий TPL по-прежнему может сделать лучшую работу по обращению с этими новыми чипами, чем любые ручные резьбы. США могли бы написать.
Один настоящий недостаток я вижу, чтобы начать сейчас, это то, что учебные ресурсы еще не там. Существует некоторое документ, некоторые сообщения в блоге (некоторые из которых будут устареть на сегодняшний день) и какой-то пример код - но никаких книг, посвященных PFX. Я уверен, что те, кто придет вовремя - и если вы рано в игре, вы могли бы даже написать один :)
в зависимости от вашего приложения, вы также можете посмотреть реактивные расширения , который работает рука в руках с PFX.
В конце концов, это важно больше, если ваш основной двигатель может извлечь выгоду из параллелизма в целом. У него много общего состояния, которое необходимо охранять замками? Если это правда, может ли это легко переместить в дизайн, сосредоточенный вокруг безблокированных структур данных?
Я думаю, что эти вопросы должны сначала ответить, чтобы они могли иметь более четкое изображение для оценки, если TPL может помочь Дорога.
Ну - ваша основная причина против использования TPL сегодня кажется следующим:
Вы не знаете, предпримет ли TPL максимум из многократного процессора будущего.
Я бы сказал (это только предположение - особенно в информатике, вы никогда не сможете сказать, что произойдет дальше): Да, они будут измениться. И да, TPL будет изменен в некоторых моментах, чтобы максимизировать производительность. Однако некоторые изменения будут «под капотом» - вы получите прибыль от оптимизаций, не изменяя одну строку кода.
И даже если существуют изменения в архитектурах, которые приводят к более высокой производительности только в комбинации, которые меняют ваш код: я не думаю, что эти изменения повлияют на весь ваш код - возможно, некоторые процентов были каждаями миллисекундами очень важны.
А где альтернативы? Использование ThreadPool? Ну - тогда TPL гораздо больше обновляется. Поэтому ваш код будет более доказательством будущего при использовании IMHO. Например, демонстрация отладки VS 2010 года выглядит довольно приятно.
Кроме того, TPL, кажется, довольно гибкий в моих глазах - если он не вписывается в конкретную ситуацию, вам не нужно его использовать там. С другой стороны, упрощает развитие MUSHC в других местах.
Я думаю, что самое главное, что сегодня - подумайте о параллелизме и включить его в архитектуру. TPL делает этот процесс гораздо проще.
Поэтому мой вывод: используйте его!
Я бы тоже на это пошел. На мой взгляд, большое изменение - это сдвиг «парадигмы» от разработки «мы делали так в течение последних 8 лет» к более функциональному / свободному от побочных эффектов программированию.
Если вы начнете использовать PFX сегодня, я предполагаю, что потребуется некоторое время, чтобы освоить его и буквально перенести свой код, чтобы получить от него максимальную отдачу. Если, с другой стороны, PFX пойдет через 2 года или внесет серьезные изменения, я бы ожидал, что ваш код по-прежнему будет работать намного лучше, используя все, что вы там получите. Мы не будем снова уменьшать количество ядер, и большие задачи по лучшему масштабированию не устареют надолго.
Что касается изменений архитектуры ЦП: я не могу их комментировать, за исключением того, что, на мой взгляд, ваши инвестиции сейчас приведут к бизнес-преимуществу сейчас + через X месяцев. X, вероятно, меньше, чем время до тех пор, пока не произойдут серьезные изменения в развитии ЦП -> Вы выиграете.
Я бы тоже не стал ждать.
На самом деле, я бы пошел дальше и сказал, что не ждите VS2010 /.NET 4.0. TPL теперь доступен для .NET 3.5 как часть Реактивные расширения для .NET.