Haskell performance

Jerzy Karczmarczuk karczma at info.unicaen.fr
Thu Mar 18 12:04:51 EST 2004

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.


 > 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

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

More information about the Glasgow-haskell-users mailing list