how to interpret these results ?

[Ryan Rawson]

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.

-ryan



On 7/20/06, Ulf Wiger <ulf@REDACTED> wrote:
> Den 2006-07-20 17:46:32 skrev Only OpenSource <onlyopensource@REDACTED>:
>
> > 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.
>
> BR,
> Ulf W
> --
> Ulf Wiger
>