Для тяжелых вычислений и т.п., чисто функциональных языков как Haskell легко parallelizable без любого усилия со стороны программиста. Кроме изучения Haskell, который является.

Однако я не думаю, что это - способ (почти) будущее, просто потому что слишком много программистов слишком привыкли к парадигме императивного программирования.

Для приложения.NET я выбираю" .NET Parallel Extensions (PLINQ)", это чрезвычайно просто в использовании и позволяет мне параллелизировать существующий код в минутах.

1. просто учиться
2. Используемый для выполнения сложных операций по большим массивам объектов, таким образом, я не могу прокомментировать другие приложения
3. , задачи Поддержек и piplines
4. Должны поддерживаться для следующих нескольких годы, но кто знает наверняка?
5. версия CTP имеет некоторые проблемы производительности, но уже выглядит очень перспективной.

Моно , вероятно, доберется поддержка PLINQ, таким образом, это могло быть межплатформенное решение также.

mapreduce/hadoop парадигма полезна, и релевантна. Специально для людей, которые привыкли к языкам как жемчуг, идея отобразиться по массиву и сделать некоторое действие с каждым элементом должна прибыть довольно жидко и естественно, и mapreduce/hadoop просто берет его к следующему этапу и говорит, что нет никакой причины, что каждый элемент массива должен быть обработанным на той же машине.

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

Два решения, которые я действительно люблю, исчисление соединения ( JoCaml, Полифонический C#, ‰ CП ) и модель агента ( Erlang, Scala, E, Io).

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

1. Люди понимают транзакции в базах данных
2. уже существует разговор о транзакционных аппаратных средствах RAM
3. так, как все мы желаем им уведенный, потоки, вероятно, будут доминирующей моделью параллелизма в течение следующих нескольких десятилетий, печальных, как это может быть. STM мог значительно уменьшить боль.

Очередь заданий с системой с несколькими рабочими (не уверены в правильной терминологии - очередь сообщений?)

Почему?

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

Кроме того, в отличие от причин, по которым, скажем, Haskell или Erlang настолько параллельны / параллелизованы (?), Он полностью независим от языка - вы можете легко реализовать такую ​​систему на C, Python или любом другом языке (даже с использованием сценариев оболочки), тогда как я сомневаюсь, что bash получит программную транзакционную память или объединенное исчисление в ближайшее время.

Кажется, этот вопрос продолжает появляться в разных формулировках - возможно, в StackOverflow есть разные группы. Программирование на основе потоков (FBP) - это концепция / методология, которая существует уже более 30 лет и используется для обработки большей части пакетной обработки в крупном канадском банке. Он имеет реализации на основе потоков в Java и C #, хотя более ранние реализации были основаны на волокне (C ++ и Ассемблер мэйнфрейма - тот, который использовался в банке). Большинство подходов к проблеме использования преимуществ многоядерности включают попытку взять обычную однопоточную программу и выяснить, какие части могут работать параллельно. FBP использует другой подход: приложение с самого начала спроектировано в виде нескольких «черных ящиков». компоненты, работающие асинхронно (представьте производственную сборочную линию). Поскольку интерфейс между компонентами представляет собой потоки данных, FBP по существу не зависит от языка и, следовательно, поддерживает многоязыковые приложения и предметно-ориентированные языки. По этой же причине минимизированы побочные эффекты. Его также можно описать как модель «ничего не разделять» и MOM (промежуточное программное обеспечение, ориентированное на сообщения). MapReduce кажется частным случаем FBP. FBP отличается от Erlang главным образом тем, что Erlang оперирует множеством короткоживущих потоков, поэтому зеленые потоки здесь более уместны, тогда как FBP использует меньше (обычно от нескольких десятков до нескольких сотен) долгоживущих потоков. Для части пакетной сети, которая использовалась ежедневно более 30 лет, см. часть пакетной сети . Для высокоуровневого дизайна интерактивного приложения см. Маклерское приложение высокого уровня . Было обнаружено, что FBP приводит к созданию гораздо более удобных в обслуживании приложений и сокращению затраченного времени - даже на одноядерных машинах!

Мы использовали PARLANSE , язык параллельного программирования с явной спецификацией параллелизма в частичном порядке за последнее десятилетие, реализовать масштабируемую систему анализа и преобразования программ ( DMS Software Reengineering Toolkit ), которая в основном выполняет символьные, а не числовые вычисления. PARLANSE - это скомпилированный C-подобный язык с традиционными скалярными типами данных: символьный, целочисленный, с плавающей запятой, динамические типы данных: строка и массив, структура и объединение составных типов данных, а также функции с лексической областью видимости. Хотя большая часть языка является ванильным (арифметические выражения над операндами, операторы if-then-else, циклы do, вызовы функций), параллелизм - нет. Параллелизм выражается путем определения отношения «предшествует» по блокам кода (например, a до b, a до c, d до c) составные типы данных структура и объединение, а также функции с лексической областью видимости. Хотя большая часть языка является ванильным (арифметические выражения над операндами, операторы if-then-else, циклы do, вызовы функций), параллелизм - нет. Параллелизм выражается путем определения отношения «предшествует» по блокам кода (например, a до b, a до c, d до c) составные типы данных структура и объединение, а также функции с лексической областью видимости. Хотя большая часть языка является ванильным (арифметические выражения над операндами, операторы if-then-else, циклы do, вызовы функций), параллелизм - нет. Параллелизм выражается путем определения отношения «предшествует» по блокам кода (например, a до b, a до c, d до c) записывается как

(|;  a  (... a's computation)
     (<< a) b ( ... b's computation ... )
     (<< a) c ( ....c's computation ...)
     (>> c) d ( ... d's computation...)
)|;

, где операторы << и >> относятся к «порядку во времени». Компилятор PARLANSE может видеть эти параллельные вычисления и заранее выделять все структуры, необходимые для вычислений. зерна a, b, c, d, и сгенерировать собственный код для запуска / остановки каждого из них, тем самым минимизируя накладные расходы на запуск и остановку этих параллельных гранул.

См. эту ссылку для параллельного итеративного поиска углубления для оптимальные решения головоломки 15 , которая является старшим братом 4x4 головоломки 8. Он использует только потенциальную параллель в качестве конструкции параллелизма (|| abcd) , которая говорит, что нет ограничений частичного порядка на вычисления a b c d , но он также использует предположения и асинхронно прерывает задачи, которые не могут найти решения. Много идей в очень небольшом фрагменте кода.

PARLANSE работает на многоядерных компьютерах. В большой программе PARLANSE (мы построили многие с более чем 1 миллионом строк) будут тысячи таких частичных заказов, До сих пор у нас были хорошие результаты с использованием до 8 процессоров и скромная отдача с использованием до 16, и мы все еще настраиваем систему. (Мы думаем, что реальная проблема с большим количеством ядер на современных ПК - это пропускная способность памяти: 16 ядер, перегружающие подсистему памяти, создают огромную потребность в пропускной способности).

Большинство других языков не раскрывают параллелизм, поэтому его трудно найти, и системы времени выполнения платят высокую цену за планирование вычислений с помощью примитивов планирования общего назначения. Мы думаем, что это рецепт катастрофы или, по крайней мере, плохой производительности из-за закона Амдала: если количество машинных инструкций для планирования зерна велико по сравнению с работой, вы не сможете работать эффективно. OTOH, если вы настаиваете на вычислительных зернах с множеством машинных инструкций, чтобы снизить затраты на планирование, вы можете: • находить независимые вычислительные гранулы, поэтому у вас нет полезного параллелизма для планирования. Таким образом, ключевая идея PARLANSE состоит в том, чтобы минимизировать затраты на планирование зерен, чтобы зерна могли быть маленькими, чтобы их можно было найти в реальном коде. Понимание этого компромисса пришло из вопиющего провала парадигмы чистого потока данных, которая делала все параллельно с крошечными параллельными порциями (например, оператором добавления).

Мы работали над этим время от времени в течение десятилетия. Трудно понять это правильно. Я не понимаю, как у людей, которые не создавали параллельные языки и не использовали / не настраивали их для этого периода времени, есть серьезные шансы на создание эффективных параллельных систем.

Таким образом, ключевая идея PARLANSE состоит в том, чтобы минимизировать затраты на планирование зерен, чтобы зерна могли быть маленькими, чтобы их можно было найти в реальном коде. Понимание этого компромисса пришло из вопиющего провала парадигмы чистого потока данных, которая делала все параллельно с крошечными параллельными фрагментами (например, с оператором добавления).

Мы работали над этим время от времени в течение десятилетия. Трудно понять это правильно. Я не понимаю, как у людей, которые не создавали параллельные языки и не использовали / не настраивали их для этого периода времени, есть серьезные шансы на создание эффективных параллельных систем.

Таким образом, ключевая идея PARLANSE состоит в том, чтобы минимизировать затраты на планирование зерен, чтобы зерна могли быть маленькими, чтобы их можно было найти в реальном коде. Понимание этого компромисса пришло из вопиющего провала парадигмы чистого потока данных, которая делала все параллельно с крошечными параллельными порциями (например, оператором добавления).

Мы работали над этим время от времени в течение десятилетия. Трудно понять это правильно. Я не понимаю, как у людей, которые не создавали параллельные языки и не использовали / не настраивали их для этого периода времени, есть серьезные шансы на создание эффективных параллельных систем.

это делало все параллельно с крошечными параллельными фрагментами (например, с оператором добавления).

Мы работали над этим время от времени в течение десяти лет. Трудно понять это правильно. Я не понимаю, как у людей, которые не создавали параллельные языки и не использовали / не настраивали их для этого периода времени, есть серьезные шансы на создание эффективных параллельных систем.

который делал все параллельно с крошечными параллельными фрагментами (например, с оператором добавления).

Мы работали над этим время от времени в течение десяти лет. Трудно понять это правильно. Я не понимаю, как у людей, которые не создавали параллельные языки и не использовали / не настраивали их для этого периода времени, есть серьезные шансы на создание эффективных параллельных систем.

Полезным путем может быть OpenCL , который обеспечивает средства распределения определенных видов вычислительных нагрузок по разнородным вычислительным ресурсам, IE тот же код будет работать на многоядерном ЦП и также обычные графические процессоры. ATI недавно выпустила именно такую ​​ инструментальную цепочку . Набор инструментов NVidia CUDA аналогичен, хотя и несколько более ограничен. Также похоже, что у Nvidia есть OpenCL sdk в разработке

. Следует отметить, что это, вероятно, не сильно поможет там, где рабочие нагрузки не являются параллельными по характеру данных, например, это не сильно поможет с типичной обработкой транзакций. OpenCL в основном ориентирован на математические вычисления, такие как научное / инженерное моделирование или финансовое моделирование.

Мне очень нравится модель, которую выбрала Clojure . Clojure использует комбинацию неизменяемых структур данных и программной транзакционной памяти.

Неизменяемые структуры данных никогда не изменяются. Новые версии структур могут быть созданы с измененными данными, но если у вас есть «указатель» на структуру данных, он никогда не изменится из-под вас. Это хорошо, потому что вы можете получить доступ к этим данным, не беспокоясь о проблемах параллелизма.

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

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

Возможно, сегодня наиболее широко применимыми являются очереди задач в стиле Cilk (теперь они доступны в .NET 4). Они отлично подходят для задач, которые можно решить с помощью «разделяй и властвуй» с предсказуемой сложностью для подзадач (таких как параллельное отображение и сокращение по сравнению с массивами, где сложность аргументов функции также известна как алгоритмы вроде быстрой сортировки), и это решает многие реальные проблемы.

Более того, это применимо только к архитектурам с разделяемой памятью, таким как современные многоядерные. Хотя я не верю, что эта базовая архитектура исчезнет в ближайшее время, я считаю, что в какой-то момент ее необходимо объединить с распределенным параллелизмом. Это будет либо в форме кластера из многоядерных процессоров на многоядерном ЦП с передачей сообщений между многоядерными процессорами, либо в форме иерархии ядер с предсказуемым временем связи между ними. Для достижения максимальной эффективности они потребуют существенно разных моделей программирования, и я не верю, что о них много известно.