[erlang-questions] About Erlang system performance
Fri Nov 9 15:58:38 CET 2012
On 09/11/2012 08:42, hume npx wrote:
> Hi, all:
> I'am new to erlang, after investigate some benchmark such as at
> 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
> 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.
I'm no expert in Erlang, but I would caution against using small
benchmarks to make significant decisions. They usually measure the wrong
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
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions