Pull to refresh

Comments 19

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

Вообще распространенное заблуждение, что раз язык конкурентный и создан для soft realtime систем, то значит, он быстрый. На деле Эрланг — середнячок, не конкурент C++, OCaml, или Java. Но его козырь — отказоустойчивость и предсказуемость.
Он середнячок, пока у Вас 1 процесс. Как только серверу на эрланге дать нагрузку то вдруг неожиданно окажется что ему совершенно индифферентно 1 процесс или 100к.
Вот только не надо про Erlang is a Ghetto :) Этот rant подробно обсудили в рассылке ;)
Erlang is a Ghetto это такой же унылый моветон, как и высказывание о том, что в емаксе есть всё, кроме текстового редактора.
Хмм… Честно говоря я бы понял, если бы вы привели go в качестве примера (с его goroutine), или скалу с актёрами. Но ссылка на сообщение 3х летней давности, которую даже невозможно проверить или посмотреть исходники… Кто то слышал про этот Kilim с тех пор?

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

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

Kilim этот конечно интересно, но что-то пока мало информации. Да и реальный проект бы поглядеть на этом чуде.
по поводу 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 его производительность вполне на уровне.
На java 5,3 сек. на 2.4Ghz CoreDuo на Маке.
Вы знаете, при всем уважении, сравнивать на разных машинах не имеет смысла. Хотя, конечно, я уверен, ява должна работать быстрее чем эрланг на этом тесте.

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

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

А хвостовая рекурсия в любом случае без аккумулятора бы и не получилась.
В нативный удобно компилить модули, содержащие арифметические алгоритмы, наподобие подсчёта чексумм. Можно, конечно, их сделать в виде NIF на C, и работать будет быстрее, чем в HiPE, но если это не является узким местом, то вполне можно использовать и код на ерланге.
Хочу отметить, что в целях оптимизации этот приём используется в ejabberd_logger. То есть в зависимости от того сообщения какого уровня надо логировать на лету генерится текст модуля, компилируется и загружается. Не знаю много ли они от этого выиграли.
В противоположном случае пришлось бы где-то хранить параметры логгирования, как его уровень, и при каждом вызове функции логгирования обращаться в это хранилище. Где его можно хранить? Состояние процесса, либо ETS/DETS/Mnesia. Если хранить в состоянии процесса, то необходим синхорнный вызов к этому процессу, если хранить в базе, то, соответственно, запрос в базу. А вот ежели просто поменять код модуля, то не надо производить этих дополнительных действий, вещь в себе получается.
Sign up to leave a comment.

Articles