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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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