Когда Erlang parallelism преодолеет свои недостатки в числовых вычислениях?

Ответ 1

Ошибочно думать о parallelism, как о только том, что хрустальное количество сырого количества. Эрланг ближе к тому, как работает кластерный компьютер, чем, скажем, GPU или классический суперкомпьютер.

В современных графических процессорах и суперкомпьютерах старого стиля производительность связана с векторизованной арифметикой, аппаратным обеспечением специального назначения и связью с низкой задержкой между обрабатывающими блоками. Поскольку латентность связи низкая, и каждый отдельный вычислительный блок работает очень быстро, идеальный шаблон использования заключается в загрузке машинного ОЗУ с данными и его одновременном хрусте. Эта обработка может включать в себя большое количество данных, проходящих между узлами, как это происходит при обработке изображений или 3D, где есть множество задач, связанных с процессором, чтобы преобразовать данные из формы ввода в форму вывода. Этот тип машины является плохим выбором, когда вам часто приходится обращаться к диску, сети или другому медленному каналу ввода-вывода для данных. Это простаивает как минимум один дорогостоящий специализированный процессор и, вероятно, также забивает конвейер обработки данных, и ничего больше не делается.

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

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

Классический случай, когда вам абсолютно необходим классический суперкомпьютер, - предсказание погоды. Здесь вы разделяете атмосферу на кубики и выполняете физическое моделирование, чтобы узнать, что происходит в каждом кубе, но вы не можете использовать кластер, потому что воздух перемещается между каждым кубом, поэтому каждый куб постоянно общается с его 6 соседними соседями. (Воздух не проходит через края или углы куба, будучи бесконечно точным, поэтому он не разговаривает с другими 20 соседними кубами.) Запустите это на кластере, будь то работа Эрланг на нем или какая-то другая система, и он мгновенно становится границей ввода/вывода.

Ответ 2

Есть ли переломная точка, в которой сила Эрланга преодолевает локальную слабость скорости?

Ну, конечно, есть. Например, при попытке найти медиану триллиона чисел:):

http://matpalm.com/median/question.html

Как раз перед тем, как вы отправили сообщение, мне показалось, что это сообщение номер 1 на странице erlang.reddit.com.

Ответ 3

Почти любой язык может быть распараллелен. На некоторых языках это просто, в других - боль в прикладе, но это можно сделать. Если вы хотите запустить С++-программу через 8000 CPU в сетке, продолжайте! Вы можете сделать это. Это было сделано раньше.

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

То, что делает Erlang, делает этот вид parallelism удобным для работы. Это экономит время разработчика и снижает вероятность ошибок.

Итак, я собираюсь сказать "нет", нет переломного момента, при котором Erlang parallelism позволяет ему превосходить пронумерованную численную численность численного числа.

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

И, конечно же, не забывайте о доброй старой точке, что языки не имеют скорости. Достаточно хороший компилятор Erlang даст совершенно оптимальный код. Достаточно плохой компилятор C даст код, который работает медленнее, чем что-либо еще.

Ответ 4

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

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

Теперь, когда серверы с 128 ГБ ОЗУ не так уж необычны, и нет причин, по которым они получат еще больше памяти, некоторые проблемы с привязкой к IO могут переместиться, чтобы быть связанными с несколькими CPU. Это может быть драйвер.

Вы должны следовать за HiPe для разработки.

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

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

Лучшей архитектурой для сильно параллельных задач являются графические процессоры. Для программирования графических процессоров на функциональном языке я вижу лучший потенциал в использовании Haskell для создания программ, ориентированных на них. Графический процессор в основном представляет собой чистую функцию от входных данных до выходных данных. См. Проект Lava в Haskell для создания схем FPGA, если можно создать схемы так чисто в Haskell, это не может быть сложнее для создания данных программы для графических процессоров.

Архитектура ячеек очень хороша и для векторизуемых проблем.

Ответ 5

Я думаю, что более широкая необходимость заключается в том, чтобы указать, что parallelism не обязательно или даже обычно о скорости.

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