Почему MPI считается сложнее, чем разделяемая память, а Erlang - проще, если они оба передают сообщения?

Что касается MPI против OpenMP / UPC: MPI заставляет вас разбивать проблему на мелкие кусочки и брать на себя ответственность за перемещение данных. В OpenMP / UPC «все данные есть», вам просто нужно разыменовать указатель. Преимущество MPI состоит в том, что кластеры с 32-512 ЦП намного дешевле, чем отдельные машины с 32-512 ЦП. Кроме того, с MPI расходы оплачиваются авансом при разработке алгоритма. OpenMP / UPC может скрыть задержки, которые вы получите во время выполнения, если ваша система использует NUMA (и все большие системы это делают) - ваша программа не будет масштабироваться, и потребуется время, чтобы выяснить, почему.

Параллелизм в Erlang все еще довольно сложно реализовать. Под этим я подразумеваю, что вам все еще нужно выяснить, как разделить вашу проблему, но есть несколько незначительных вещей, которые облегчают эту трудность по сравнению с некоторой библиотекой MPI на C или C++.

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

Кроме того, все библиотеки Erlang построены на передаче сообщений Erlang. Эта структура поддержки помогает вам перейти на землю параллельной обработки. Взгляните на компоненты OTP, например gen_server, gen_fsm, gen_event. Это очень простые в использовании структуры, которые могут помочь вашей программе стать параллельной.

Я думаю, что отличает передачу сообщений Erlang от других реализаций MPI больше надежность доступной стандартной библиотеки, а не какая-то конкретная особенность самого языка.

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

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

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

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

Я согласен со всеми предыдущими ответами, но я думаю, что ключевой момент, который не совсем ясен, заключается в том, что одна из причин, по которой MPI может считаться сложным, а Erlang easy - это соответствие модели предметной области.

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

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

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

Таким образом, Erlang лучше всего сравнивать с pthreads и другими довольно локальными гетерогенными решениями потоков, а не с MPI, который на самом деле нацелен на совсем другой (и в некоторой степени по своей сути более сложный) набор проблем.

Does anybody know why there is such a difference in the perception of message-passing vs. shared memory in the IT and HPC worlds? Is it due to some fundamental difference in how Erlang and MPI implement message passing that makes Erlang-style message-passing much easier than MPI? Or is there some other reason?

Причина просто в параллелизме и параллелизме. Erlang создан для параллельного программирования. HPC - это параллельное программирование. Это связанные, но разные цели.

Параллельное программирование сильно усложняется из-за сильно недетерминированного потока управления, и задержка часто является важной целью. Использование в Erlang неизменяемых структур данных значительно упрощает параллельное программирование.

Параллельное программирование имеет гораздо более простой поток управления, и цель состоит в максимальной общей пропускной способности, а не в задержке. Здесь гораздо важнее эффективное использование кеша, из-за чего как Erlang, так и неизменяемые структуры данных в значительной степени непригодны. Мутация разделяемой памяти поддаётся обработке и значительно лучше в этом контексте. По сути, согласованность кэша обеспечивает передачу сообщений с аппаратным ускорением.

Наконец, помимо этих технических различий есть еще и политический вопрос. Ребята из Erlang пытаются оседлать многоядерную шумиху, делая вид, что Erlang имеет отношение к многоядерности, хотя это не так. В частности, они рекламируют отличную масштабируемость, поэтому также важно учитывать абсолютную производительность. Erlang легко масштабируется от плохой абсолютной производительности на одном ядре до плохой абсолютной производительности на любом количестве ядер. Как вы понимаете, это не впечатляет сообщество HPC (но этого достаточно для большого количества параллельного кода).

Обычно параллелизм в HPC означает работу с большими объемами данных. Этот вид параллелизма называется параллелизм данных, и его действительно проще реализовать с использованием подхода с общей памятью, такого как OpenMP, потому что операционная система заботится о таких вещах, как планирование и размещение задач, которые нужно было бы реализовать самостоятельно при использовании парадигмы передачи сообщений.

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

Эта модель похожа на то, для чего большинство людей используют PThreads. Он подходит для таких приложений, как веб-серверы, где каждый запрос может обрабатываться отдельным потоком, в то время как приложения HPC делают примерно то же самое с огромными объемами данных, которыми также необходимо обмениваться между рабочими.

Эта статья на самом деле хорошо объясняет это, Erlang лучше всего подходит, когда мы отправляем небольшие фрагменты данных, а MPI намного лучше справляется с более сложными вещами. Также модель Erlang легко понять :-)

Сравнение Erlang и MPI - окончательные результаты и исходный код