[erlang-questions] About Erlang system performance

[Ian]

On 09/11/2012 08:42, hume npx wrote:
> Hi, all:
>   I'am new to erlang, after investigate some benchmark such as at 
> http://shootout.alioth.debian.org/u64q/which-programs-are-fastest.php, 
> I found that erlang compiler is not so good at speed? the benchmark 
> shows that erlang Hipe is 13x slowdown compared to C++, as compared to 
> Haskell GHC (3.3x slowdown), go 2.98x slowdown or even javascript v8 
> is about 1x faster than erlang, I investigated the erLLVM project 
> which reported similar results to Hipe, you know performance is so 
> important nowadays, what caused the hard to improve performace of 
> erlang or just there are not people working on it? Erlang is 
> attractive to me after several days studying, but with great 
> performance will be more attractive and competitive to some languages 
> such as go etc.

Hi,

I'm no expert in Erlang, but I would caution against using small 
benchmarks to make significant decisions. They usually measure the wrong 
things.

Most significant systems are speed limited due to I/O and networking: 
the CPU usage can be surprisingly low. Erlang handles async and 
simultaneous I/O and networking extremely well - by design.

 From my experience, and the research of others, anything from 20% to 
60% of code in multi-threaded applications is spent checking that other 
threads have not changed things when they shouldn't, getting and freeing 
locks and similar overhead. Erlang by its nature, avoids this.

Erlang has a "let it crash" approach. You code the "happy path" and get 
restarted after error conditions. This means that complicated error 
conditions do not need to be understood (= less development), detected 
(less code) or recovered from (much less code).

Multi-threaded processes use operating system threads, which have very 
very heavy creation and clean up costs, and heavy scheduling costs. 
Erlang, is between 100 and 10000 times faster at this.

While both traditional and Erlang sytems will wait for I/O and 
networking, traditional systems under load will wait for worker threads 
to be free or created. Erlang can proceed directly.

Traditional systems tend to crash under heavy load, while Erlang slows 
down, and recovers when load eases.

Erlang's garbage collection is superbly designed for soft real-time 
processing, while most multi-threaded systems either suffer from 
periodic pauses, or they have considerable code to test and check 
everything is deallocated when it should be (and not before). Erlang 
automatic and ridiculously easy to build by comparison.

So, Erlang has so much less overhead, and so much better threading, no 
locks to contend with (other than the internal ones) and a much lighter 
scheduling algorithm, and it has less to do.

If you use it for number crunching, it will be slow. For more typical 
applications Erlang will be built faster, be more reliable, and be 
smaller and easier to modify, but it might not be quite as fast.  For 
complicated event-driven and soft-real time processing, Erlang will win 
on all measures.

So fake up some meaningful test of your proposed load, before making a 
decision.

Regards

Ian

>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121109/cb103f98/attachment.htm>