Tue Jan 12 16:03:32 CET 2010
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.
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
> 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
> 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:
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
More information about the erlang-questions