[erlang-questions] Benchmarks

[Henning Diedrich]

Still reading the link, getting the pun. In the mold you are 
convincingly outlining below, there could be a benchmark designed to 
reflect more realistic application of programming than a too-flat 
benchmark, one that lets Erlang shine without cheating on C in any way 
-- just being more realistic. I think everbody can understand the point 
that flat benchmarks may say next to nothing about real life.

Yet, thanks for zeroing in on the question in depth there.
Henning

James Hague wrote:
>>> they are irrelevant as none of those things are what Erlang is designed to
>>> do REALLY WELL.
>>>       
>> Certainly that's the expected defense. Could you spell that out
>> specifically?
>>     
>
> There isn't an easy answer to this, but I'll try.
>
> The Shootout benchmarks are mostly about doing heavy, straightforward
> data manipulation. The kind of thing that's a best case for C: static
> memory allocation, fixed data sizes. In Erlang you pay the price for
> dynamic typing, garbage collection, data structures full of pointers
> instead of simple structs, and floating point values boxed on the
> heap.
>
> Where Erlang--and indeed any functional language--shines is when
> things get messy. When you're building and rebuilding data structures
> on the fly, when there are lots of complex decisions, when you can
> often go for a symbolic solution instead of just plowing through
> blocks of bytes. Often I've found I can implement optimizations that
> would be too painful in C. And truthfully, C is still faster, usually
> by a lot, but it doesn't matter. The Erlang code is fast enough and
> more reliable.
>
> You might like this:
> http://www.dadgum.com/james/performance.html
>
> James
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>
>