Какую модель параллельного программирования вы рекомендуете сегодня, чтобы использовать преимущества многоядерных процессоров завтрашнего дня?

Question

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

Меня особенно интересуют ответы по этим осям:

1. Программист производительность / простота использования (могут ли смертные успешно использовать его?)
2. Область целевого приложения (с какими проблемами это (не) хорошо?)
3. Стиль параллелизма (поддерживает ли он задачи, конвейеры, параллелизм данных, сообщения ...?)
4. Ремонтопригодность / будущее (кто-нибудь еще будет использовать его через 20 лет?)
5. Производительность (как она масштабируется на каких видах оборудования?)

Я намеренно размываю природу приложения в ожидании получения хороших общих ответов, полезных для различных приложений.

Answer 1

Для многоядерного программирования может потребоваться более одной парадигмы. Некоторые текущие претенденты:

1. MapReduce . Это хорошо работает, когда проблему можно легко разложить на параллельные куски.
2. Параллелизм вложенных данных . Это похоже на MapReduce, но на самом деле поддерживает рекурсивное разложение проблемы, даже когда рекурсивные порции имеют неправильный размер. Ищите NDP как большой выигрыш в чисто функциональных языках, работающих на массово параллельном, но ограниченном оборудовании (например, графических процессорах).
3. Программная транзакционная память . Если вам нужны традиционные темы, STM делает их терпимыми. Вы платите 50% -ое снижение производительности в критических секциях, но вы можете без проблем масштабировать сложные схемы блокировки до сотен процессоров. Однако это не будет работать для распределенных систем.
4. Параллельные потоки объектов с обменом сообщениями . Эту действительно умную модель использует Эрланг. Каждый «объект» становится легким потоком, а объекты связываются с помощью асинхронных сообщений и сопоставления с образцом. Это в основном правда параллельная ОО. Это удалось успешно в нескольких реальных приложениях, и это прекрасно работает для ненадежных распределенных систем.

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

Answer 2

Мне действительно нравятся два решения: исчисление соединений ( JoCaml , Полифонический C # , Cω ) и модель актера ( Erlang , Scala , E , Io ).

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

kamaelia - это Python Framework для создания приложений с множеством взаимодействующих процессов.

Kamaelia - Параллелизм стал полезным, веселым

В Kamaelia вы строите системы из простых компонентов, которые взаимодействуют друг с другом . Это ускоряет разработку, значительно облегчает обслуживание, а также означает, что вы создаете естественно параллельное программное обеспечение . Он должен быть доступен для любого разработчика, включая новичков. Это также делает это забавным :)

Какие системы? Сетевые серверы, клиенты, настольные приложения, игры на основе Pygame, системы перекодировки и конвейеры, системы цифрового телевидения, средства искоренения спама, средства обучения и многое другое

См. Также вопрос Многоядерность и параллелизм - языки, библиотеки и методы разработки

Answer 7

Я делаю ставку на сообщение о циклах событий с обещаниями, реализованными в таких системах, как Twisted , E , AmbientTalk и других. Они сохраняют способность писать код с теми же предположениями модели выполнения, что и в не параллельных / параллельных приложениях, но масштабируемыми для распределенных и параллельных систем. (Вот почему я работаю над Ecru .)

Answer 8

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

Answer 9

Я удивлен, что никто не предложил MPI (интерфейс передачи сообщений). Разработанные для распределенной памяти, программы MPI с существенным и частым глобальным связыванием (решение линейных и нелинейных уравнений с миллиардами неизвестных) были масштабированы до 200 тыс. Ядер.

Answer 10

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

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

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