Компиляция «на ходу» в эрланге

[alist]

Интересно сравнение производительность HiPE по сравнению с BEAM. Некоторое время назад читал мнение о том, что HiPE — пока что не более чем hype — раскрученная идея, но недостаточно хорошая реализация.

Вообще распространенное заблуждение, что раз язык конкурентный и создан для soft realtime систем, то значит, он быстрый. На деле Эрланг — середнячок, не конкурент C++, OCaml, или Java. Но его козырь — отказоустойчивость и предсказуемость.

[sleepwalker]

Он середнячок, пока у Вас 1 процесс. Как только серверу на эрланге дать нагрузку то вдруг неожиданно окажется что ему совершенно индифферентно 1 процесс или 100к.

[philpirj]

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

[dmitriid]

Вот только не надо про Erlang is a Ghetto :) Этот rant подробно обсудили в рассылке ;)

[Zert]

Erlang is a Ghetto это такой же унылый моветон, как и высказывание о том, что в емаксе есть всё, кроме текстового редактора.

[OdobenusRosmarus]

Хмм… Честно говоря я бы понял, если бы вы привели go в качестве примера (с его goroutine), или скалу с актёрами. Но ссылка на сообщение 3х летней давности, которую даже невозможно проверить или посмотреть исходники… Кто то слышал про этот Kilim с тех пор?

[philpirj]

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

[sleepwalker]

Там собственно ответ на претензии в самой статье
Erlang is not general purpose

Но он идеален, когда нужно обрабатывать гигантское количество запросов

Kilim этот конечно интересно, но что-то пока мало информации. Да и реальный проект бы поглядеть на этом чуде.

[OdobenusRosmarus]

по поводу hipe. Сделаем простой тест — скажем, число фибоначчи от 40 десять раз. Что то типа

-module(fib).
-export([fib/1,test/0]).

fib(0) ->
0;
fib(1) ->
1;
fib(N) -> fib(N-1)+fib(N-2).

test() ->
test(10,40).

test(0,_) -> ok;
test(I,N) ->
io:format("fib ~w = ~w ~n",[N,fib(N)]),
test(I-1,N).


И смотрим результаты с и без hipe:

Eshell V5.8.4 (abort with ^G)
1> c(fib).
{ok,fib}
2> timer:tc(fib,test,[]).
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
{56356860,ok}
3> c(fib,[native]).
{ok,fib}
4> timer:tc(fib,test,[]).
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
fib 40 = 102334155
{20368048,ok}


56 секунд «без» и 20 секунд «с» hipe. То есть по крайней мере на простых тестах выигрыш очень заметен.

Кстати, аналогичный тест на ocaml дал 9 сек, на go — 13 сек, на lisp (sbcl) — 32 сек, на питоне 9 мин 46 сек, на перле 27 мин 56 сек.

Понятно, что это тест просто «навскидку, по ковбойски» однако дает определенные представления о скорострельности виртуальной машины.

То есть — hipe дает прирост скорости, и erlang не такой уж и медленный. Конечно, он медленнее компилируемых, однако для vm его производительность вполне на уровне.

[miolini]

На java 5,3 сек. на 2.4Ghz CoreDuo на Маке.

[miolini]

core i5

[OdobenusRosmarus]

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

[miolini]

Я согласен с вам. Просто руки так чесались посмотреть на результаты.

[philpirj]

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

[OdobenusRosmarus]

Вы видимо не поняли, для чего писался этот код. Задача была — загрузить vm большим куском бессмысленной работы, и посмотреть, как быстро он справится… С hipe и без.

Тут не ставилась цель получить по настоящему вывод десяти строк со значением числа фибоначчи от 40 как можно скорей, если бы это было так, я бы проще посчитал это число один раз, и вывел 10 раз на экран. Да и промежуточные результаты бы хранил, что дало бы выигрыш намного больший, чем хвостовая рекурсия.

[philpirj]

Я-то понял, что вы имели в виду, но в итоге мы получили сравнение с Java комментарием ниже, которая якобы считает fib быстрее.

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

[Zert]

В нативный удобно компилить модули, содержащие арифметические алгоритмы, наподобие подсчёта чексумм. Можно, конечно, их сделать в виде NIF на C, и работать будет быстрее, чем в HiPE, но если это не является узким местом, то вполне можно использовать и код на ерланге.

[alexxz]

Хочу отметить, что в целях оптимизации этот приём используется в ejabberd_logger. То есть в зависимости от того сообщения какого уровня надо логировать на лету генерится текст модуля, компилируется и загружается. Не знаю много ли они от этого выиграли.

[Zert]

В противоположном случае пришлось бы где-то хранить параметры логгирования, как его уровень, и при каждом вызове функции логгирования обращаться в это хранилище. Где его можно хранить? Состояние процесса, либо ETS/DETS/Mnesia. Если хранить в состоянии процесса, то необходим синхорнный вызов к этому процессу, если хранить в базе, то, соответственно, запрос в базу. А вот ежели просто поменять код модуля, то не надо производить этих дополнительных действий, вещь в себе получается.