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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

Кто-нибудь знает, почему существует такая разница в восприятии передачи сообщений против разделяемой памяти в мирах ИТ и HPC? Это связано с некоторыми фундаментальными различиями в том, как передача сообщений Erlang и MPI делает передачу сообщений в стиле Erlang намного проще, чем MPI? Или есть еще одна причина?

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

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

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

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

Ответ 6

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

Ответ 7

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

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