Каков наилучший способ выполнения вычислительно-интенсивных задач в Erlang без потерь масштабируемости?

Erlang Interoperability руководство обсуждает различные механизмы взаимодействия. Вот мои выводы:Каков наилучший способ выполнения вычислительно-интенсивных задач в Erlang без потерь масштабируемости?

Порты и программы Erl_Interface: ОС запланирована, ограничена масштабируемость.
Порт Драйверы: опасно, потому что авария в драйвере порта приносит также эмулятор .
C Узлы: серверу узлов необходимо масштабировать, а также приложение Erlang, чтобы избежать жертвы масштабируемости.
NIF: Loic Суммы их хорошо.

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

Использование JInterface и связь с процессом Java, который порождает поток для каждого запроса, может быть вариантом.

Так кто-нибудь сталкивался с решением, которое было проверено на практике и оказалось хорошо работать?

источник

2015-09-29 coolfeature

Описание NIF, ссылки на которые вы видите устаревшим и неточным. Например, NIF, запущенный в планировщике «более нескольких микросекунд», не вызовет проблем; это происходит, только если NIF работает более нескольких миллисекунд. Кроме того, функция ['enif_schedule_nif'] (http://www.erlang.org/doc/man/erl_nif.html#enif_schedule_nif) обеспечивает хороший способ разбить длинные NIF, чтобы избежать проблем с планировщиком, плюс с экспериментальным [грязным планировщик] (http://www.erlang.org/doc/man/erl_nif.html#dirty_nifs) NIF могут работать до тех пор, пока они хотят, не вызывая икоты планировщика. –

Чтобы использовать функцию грязного планировщика, вам необходимо создать эмулятор с поддержкой экспериментальной грязной планировщика.Я не думаю, что идея запуска производственного кода с экспериментальными функциями будет иметь много энтузиастов. В общем, NIF кажутся немного опасными. Как указал Лойк, они могут разрушить вашу виртуальную машину. И компиляция библиотек, которые используют их под Windows, - это кошмар, и я не поклонник запуска Erlang на WIndows. – coolfeature

Экспериментальная грязная функциональность планировщика когда-нибудь станет регулярной функцией, надеюсь, в Erlang 19. Я реализовал грязную функциональность планировщика для Erlang/OTP, и я запустил все свои виртуальные машины Erlang 17 и 18 с включенной поддержкой и не испытывал никаких проблем с ней , Также см. [Эти измерения] (https://medium.com/@jlouis666/erlang-dirty-scheduler-overhead-6e1219dcc7), которые показывают крошечное количество накладных расходов, связанных с переключением процесса на грязный планировщик. –

Фактически все решения имеют место. Поскольку я работал с некоторыми из них, я мог бы сказать следующее:

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

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

источник

2015-09-29 18:25:01 Lol4t0

Согласны ли вы, что тогда нет серебряной пули? Порты являются компромиссом между надежностью масштабируемости v и NIF являются риском для устойчивости Erlang, если не написаны очень хорошо. Масштабируемый узел C или Java может хорошо подходить с точки зрения интеграции. – coolfeature

@coolfeature, автономные узлы по-прежнему медленнее, чтобы общаться с NIF. У Erlang только ограниченный пул сокетов (если я не ошибаюсь), и вам придется сериализовать/десериализовать данные. Если время обработки данных существенно больше времени для сериализации/переноса/десериализации, автономные узлы подойдут вам. – Lol4t0

Каков наилучший способ выполнения вычислительно-интенсивных задач в Erlang без потерь масштабируемости?

ответ

Смежные вопросы