how to interpret these results ?
Fri Jul 21 04:31:43 CEST 2006
The missing reply-to field of this mailing list caused me to email
this only to 'only':
Apparently for hardcore numerical computations C is better. Most of
those algorithms seem to be of that nature. The one where erlang did
well was entitled 'cheap concurrency'.
I think it's important to realize what Erlang is good at, and what it
isnt as good at. The other thing is correctness - is it easier to
write correct multi-process/threaded applications in erlang or C?
I dont feel that Erlang is as wasteful as Java is however. 20-40
bytes overhead per object?!
Of course I threw in that Java thing because I have and axe to grind.
I did a project and I was not feeling like I got very good bang for my
Java buck. I don't feel that way with Erlang - but I'm still early on
in my project.
On 7/20/06, Ulf Wiger <> wrote:
> Den 2006-07-20 17:46:32 skrev Only OpenSource <>:
> > Hello
> > Here is a comparison of Erlang and C
> > http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=hipe&lang2=gcc
> > What is the recommended approach towards understanding the benchmark
> > numbers ?
> > For starter's do they even make any sense at all ?
> > All observations and suggestions for a newbie will be greatly
> > appreciated !
> The thing to keep in mind is that performance in micro benchmarks
> like these say little about the performance in a more complex
> system. In real applications, Erlang tends to offer much better
> performance than these benchmarks seem to indicate. The only
> way to find out what's valid for your particular applications
> is to prototype and measure.
> Having said this, the benchmarks do indicate that for raw,
> low-level processing, C tends to leave Erlang in the dust.
> A worthwhile strategy can be to prototype the application
> in Erlang, then measure and identify bottlenecks. In some
> cases, rewriting a small part of the program in C can have
> a great impact on performance.
> An interesting point in this particular comparison is the
> concurrency benchmark. It shows that using Erlang for
> concurrency is far better than using C and stock Linux
> processes or threads. Not only is it much faster and more
> scalable - it is also far easier to program.
> A fairly common newbie mistake is to underestimate the
> amount of natural concurrency inherent in a typical
> application. Since most programming languages are pitifully
> bad at modeling concurrency, we get used to hiding the
> concurrency rather than emphasizing it as one of our most
> fundamental modeling techniques.
> Ulf W
> Ulf Wiger
More information about the erlang-questions