Haskell performance

[Jerzy Karczmarczuk]

Simon Peyton-Jones wrote:

 > A wise man once warned about the danger of premature optimisation.  I often
 > spend ages labouring over efficiency aspects of my code (GHC, for example)
 > that turn out to be nowhere near the critical path.  Language choice is
 > another example.


 > My biased impression is that raw speed is seldom the determining factor in
 > language choice.

Etc.
...

 > That said, there are undoubtedly reasons why a high level language is
 > fundamentally never going to be as fast as a low level one.

Well, ... What does it mean a "fast language"?

My favourite example, some centuries old, goes back to times when I was a happy,
young physicist. We wanted to implement a combinatorial problem, the global
effect of individual nucleon-nucleon scattering in alpha-alpha collisions. Some
256 diigraphs to compute, much more for the final result. A friend of mine wrote
a Pascal/Fortran program for a CDC Cyber mainframe, and I took microProlog and
a Sinclair Spectrum with 48K of main storage. His program gave the result after
3 seconds. Mine: after, hm. ... well, after some hours I had to use a cassette
player to store the intermediate results, finally next morning I got something
usable.

So what? - will you ask.


Well, the crux of the matter is that I wrote my program in two days. My friend
spent about two weeks to complete his coding.

Now, who could drink more bottles of beer before obtaining the final results?

===================

And now, again, more and more people curse the laziness, fight against boxed,
shareable data, want to produce lightspeed database interfaces, etc. I am too
lazy to get nervous (unless I do so for theatrical reasons, as an old teacher),
but I sincerely think that it is time that somebody writes a book on Haskell
as a language for the FAST DESIGN of lousy algorithms...

Jerzy Karczmarczuk
Caen, France