Когда параллелизм Эрланга преодолевает его недостатки в числовых вычислениях? - PullRequest
36 голосов
/ 21 августа 2009

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

Я начал читать Learn You Some Erlang . По мере того, как все больше людей учатся (включая меня), Эрланг обрабатывает параллелизм очень впечатляющим и элегантным способом.

Тогда автор утверждает, что Erlang не идеален для сокращения чисел . Я могу понять, что такой язык, как Erlang, будет медленнее, чем C, но модель для параллелизма кажется идеально подходящей для таких вещей, как обработка изображений или умножение матриц, даже если автор специально говорит, что это не так.

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

Чтобы было ясно: я не пытаюсь начать дебаты; Я просто хочу знать.

Ответы [ 5 ]

46 голосов
/ 25 августа 2009

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

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

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

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

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

12 голосов
/ 21 августа 2009

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

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

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

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

10 голосов
/ 21 августа 2009

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

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

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

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

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

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

6 голосов
/ 21 августа 2009

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

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

Теперь, когда серверы с 128 ГБ оперативной памяти не являются чем-то необычным, и нет никаких причин, по которым они получат еще больше памяти, некоторые проблемы с вводом-выводом могут быть перенесены на процессор. Это может быть водитель.

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


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

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

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

Архитектура Cell также хороша для векторизованных задач.

1 голос
/ 21 августа 2009

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

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

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