Haskell vs. Erlang: performance
Ertugrul Soeylemez
I'm pretty confused: So many people tell me how code written in Erlang
performs _much_ better than Haskell code (compiled using GHC). How come
the benchmarks at [1] show better performance (in terms of both CPU and
memory usage) for the same algorithms in Haskell than in Erlang?
Is it because GHC actually produces faster code than the Erlang
compiler? Is it because the Haskell implementations are better than the
corresponding Erlang implementations? Is it that Erlang is only good at
doing server stuff, and is otherwise slow? Or am I just misinterpreting
the results?
I have been told and read myself that Erlang provides an excellent
server framework. Especially when it comes to concurrency, Erlang seems
to be a lot superior to Haskell. Is this true, or did I just miss
something?
What has so far kept me from using Erlang is the fact that it isn't
purely functional (I could just as well use C++, maybe together with
FC++). Because of this fact, and because of the unbelievably flexible
type system, I would love to continue using Haskell. Unfortunately so
far I have not found any paper that deals in-depth specifically with
performance. I'd be thankful about useful pointers about this topic.
Regards,
Ertugrul Söylemez.
References:
[1] http://shootout.alioth.debian.org/
--
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
Mark T.B. Carroll
(snip)
> I'm pretty confused: So many people tell me how code written in Erlang
> performs _much_ better than Haskell code (compiled using GHC). How come
> the benchmarks at [1] show better performance (in terms of both CPU and
> memory usage) for the same algorithms in Haskell than in Erlang?
GHC can produce very fast code. Sometimes you have to understand what's
going on and write some awkward code to get the most out of it - take a
look at some of those shootout entries - but some basic rules of thumb,
and some playing with the profiler, will get you a long way. It does
take a little experience, though, or some help from others.
(snip)
> I have been told and read myself that Erlang provides an excellent
> server framework. Especially when it comes to concurrency, Erlang seems
> to be a lot superior to Haskell. Is this true, or did I just miss
> something?
(snip)
Erlang is great for many sorts of concurrent application.
A lot depends on quite what application you have in mind, and how much
work you're willing to do to squeeze the last 5% out of it.
-- Mark
Chris Smith
>
> References:
> [1] http://shootout.alioth.debian.org/
>
First of all, the shootout game isn't supposed to be a serious set of
benchmarks. It approximates the truth, but is nowhere near as
controlled or well thought out as would be needed for a real comparison
of language performance. The results for any given language can vary
greatly depending on how performance-conscious the author of the code
was, how well each language fits the rather arbitrary rules of the game,
etc.
> I'm pretty confused: So many people tell me how code written in Erlang
> performs _much_ better than Haskell code (compiled using GHC). How come
> the benchmarks at [1] show better performance (in terms of both CPU and
> memory usage) for the same algorithms in Haskell than in Erlang?
Many of the benchmarks there are written by Don Stewart using his work
on stream fusion for GHC on ByteStrings, and other techniques. Don is
really good at kludging Haskell to run really fast.
At the same time, this is not a full picture; some of the Haskell code
is rather odd. For example, consider the reverse-complement benchmark;
if you compare the implementation called "Haskell GHC" with the Erlang,
you'll see that they are about similar and perform about the same. Yet
Don contributed "Haskell GHC #2", which doesn't just use ByteString, but
also does the reverse operation in-place using functions in the IO monad
designed for use with the FFI (foreign function interface). In other
words, the faster code gives up many of the advantages of writing in
Haskell to begin with!
> I have been told and read myself that Erlang provides an excellent
> server framework. Especially when it comes to concurrency, Erlang seems
> to be a lot superior to Haskell. Is this true, or did I just miss
> something?
Erlang and Haskell provide very different models of concurrency. The
jury is still out on which is "better" (to the extent that one or the
other can be considered better in the first place). I consider it
likely that Erlang code will scale better up into distributed
applications and clusters, while Haskell is showing great promise on
shared-memory multiprocessors. They are different.
--
Chris Smith
Harald Korneliussen
> Erlang and Haskell provide very different models of concurrency. The
> jury is still out on which is "better" (to the extent that one or the
> other can be considered better in the first place). I consider it
> likely that Erlang code will scale better up into distributed
> applications and clusters, while Haskell is showing great promise on
> shared-memory multiprocessors. They are different.
>
Doesn't the shootout use single-processor machines as well? Not
exactly home field for Erlang.
Joachim Durchholz
> Doesn't the shootout use single-processor machines as well? Not
> exactly home field for Erlang.
Sure, but the benchmark results most definitely won't scale to larger
programs.
Also, most of the code you'll find in the shootout has been intensively
tuned. This skews the bias in favor of those languages that can be
tuned, and in favor of those that need a long time for tuning (because
they get the time to reach the same level of performance as next door's
quickly tuned language).
Most people are after languages where the ratio of programmer time to
performance is good, but the shootout measures just performance.
(Measuring the ratio would be far more difficult, and asking too much
from the shootout page maintainers. It would be interesting to have a
research institute pick programmer samples and let them code away at a
few predefined tasks.)
Regards,
Jo
Mark T.B. Carroll
(snip)
> Most people are after languages where the ratio of programmer time to
> performance is good, but the shootout measures just performance.
Of course, the ICFP Programming Contest is coming up soon. (-:
-- Mark
Isaac Gouy
> Harald Korneliussen schrieb:
> Measuring the ratio would be far more difficult, and asking too much
> from the shootout page maintainers
Phew! :-)
Paul Moore
> Also, most of the code you'll find in the shootout has been intensively
> tuned. This skews the bias in favor of those languages that can be
> tuned, and in favor of those that need a long time for tuning (because
> they get the time to reach the same level of performance as next door's
> quickly tuned language).
Ironically, I'd have said that Haskell is the sort of language that
takes a lot of effort to tune for high performance... (And hence should
benefit from the bias of the shootout). Of course, I haven't written any
Haskell programs that have needed tuning (high performance is not often
a key goal for me) so that's just my impression based on reading tuning
discussions on the mailing lists.
Paul.
Joachim Durchholz
Actually, I find the ICFP contests far more interesting. They don't
really help for discussing imperative vs. functional programming (too
often dismissed as "biased towards FPLs", true or not), but they do help
differentiating between FPLs.
In particular, the team notes are exceedingly helpful. They give
reasons, while statistics just give correlations.
Regards,
Jo
Ertugrul Soeylemez
> I'm pretty confused: [...]
Thank you all for your answers. You have been very helpful.
> What has so far kept me from using Erlang is the fact that it isn't
> purely functional (I could just as well use C++, maybe together with
> FC++). Because of this fact, and because of the unbelievably flexible
> type system, I would love to continue using Haskell. Unfortunately so
> far I have not found any paper that deals in-depth specifically with
> performance. I'd be thankful about useful pointers about this topic.
Unfortunately I have received no pointers. Yes, I have found a lot of
papers about Haskell performance, but they mostly were just too short to
be any helpful. I know myself that I have to write my functions
tail-recursively, if possible. But this is not always a trivial task
and often leads to ugly code, which is difficult to understand.
Further there are other places, where performance can be improved as
well (e.g. when to use, and when avoid lists, how to improve I/O
performance, etc.).
Regards,
Ertugrul Söylemez.
Joachim Durchholz
> Ertugrul Soeylemez <do-not-...@ertes.de> (07-06-30 03:10:02):
>
>> I'm pretty confused: [...]
>
> Thank you all for your answers. You have been very helpful.
>
>
>> What has so far kept me from using Erlang is the fact that it isn't
>> purely functional (I could just as well use C++, maybe together with
>> FC++).
Now that would be the question of Erlang vs. C++, so those who know
about both Erlang and C++ may have missed this question.
Personally, I think there's still a lot of difference between these two.
First of all, you don't need to do manual GC in Erlang; that alone
distinguishes the two. (I think a substantial portion of the advantages
attributed to FP are really due to automatic GC. FP does have additional
important benefits, of course.)
Second, idiomatic Erlang code is "far more functional" than idiomatic
C++. I.e. it makes near-zero use of mutation, and if it does, that's in
well-defined places so you don't have to look very far to find mutating
code. The functional code does not call mutating code (it's the other
way round). Erlang's support for HOFs probably differs from that in FC++
(I don't know FC++ so I cannot say much on this topic, other than that
Erlang's HOF support is syntactically more heavyweight than that of *ML
or Haskell.)
Etc. etc. etc.
>> Because of this fact, and because of the unbelievably flexible
>> type system, I would love to continue using Haskell. Unfortunately so
>> far I have not found any paper that deals in-depth specifically with
>> performance. I'd be thankful about useful pointers about this topic.
>
> Unfortunately I have received no pointers. Yes, I have found a lot of
> papers about Haskell performance, but they mostly were just too short to
> be any helpful. I know myself that I have to write my functions
> tail-recursively, if possible. But this is not always a trivial task
> and often leads to ugly code, which is difficult to understand.
Usually, you don't write recursion yourself, you invoke the recursion
using one of the numerous mapping functions. You leave that ugly,
hard-to-understand and intricate code to the library writers, who're
supposed to deal with that, and reuse just the functionality :-)
Inefficiencies in Haskell seem to grow more out of the "I thought the
Haskell compiler would have optimized that out!" category.
Wich means the approach here would be as elsewhere: Write the code so
that it is beautiful and elegant (and quickly done, too), then
benchmark, then profile for the bottlenecks, then optimize these.
Regards,
Jo