[erlang-questions] Erlang again!

[Jesper Louis Andersen]

On Fri, Jul 23, 2010 at 1:33 AM, Richard O'Keefe <ok@REDACTED> wrote:

> One expects a Haskell compiler to expand calls to zip.
> One expects an Erlang compiler NOT to, and it doesn't.

There are a lot of wisdom in those two sentences. A Haskell compiler
can, in general, transform a program much more and get away with it. I
believe it is one of the arguments John Hughes make in his "Why
functional programming matters" paper (I may be wrong, it is a long
time since I read the paper). An Erlang compiler can in principle make
the transformations but only after some extensive analysis and not
always. The beauty of Haskell is when you write succinct, modular
building blocks and then string them together AND the Haskell compiler
optimizes it. When it fails to optimize you have succinct, modular and
slow code.

A couple of years ago I would expect a Haskell compiler to produce
faster code than an Erlang compiler. As it stands currently, I am in
doubt: CPU cycles have become very cheap and the new bottleneck seem
to be memory bandwidth to the CPU. Lazy evaluation tend not to be
especially nice to the memory bandwidth. This can affect all programs
but those with a small heavy computation kernel. Even with a bytecode
interpreter (a state-of-the-art BC-interpreter though) my last
exploration into bittorrent clients told a story where Erlang and
Haskell were more or less on par with each other from a CPU-resource
perspective. A recent new IO manager for Haskell might change this
picture however.

-- 
J.