[Haskell] [Fwd: Re: Computer Language Shootout]

Donald Bruce Stewart dons at cse.unsw.edu.au
Fri Jan 26 18:51:29 EST 2007

> It would be enough to exhaustively analyse examples of the kind I gave:
> single algorithm with fast non-Haskell implementation but very slow in
> Haskell. The article describes laborious but unsuccessful attempt to
> pinpoint what makes Haskell over 500 times slower than SML on a genetic
> algorithm. 7 years have passed and nobody cares.

This is wrong. We do care, greatly.

Efforts are underway right now to improve the output of the native code
generator in GHC, great steps have been made in improving the GHC optimiser
over the last year (Larry Wall mentioned that Pugs compiled under ghc
6.6 ran his perl6 programs 60x faster than under ghc 6.4.2). And
numerous new libraries have appeared to allow for high performance
Haskell without sacrificing clarity. Additionally, we have collected
information on standard approaches to optimising Haskell code on the
wiki under haskell.org/haskellwiki/Performance.

Just yesterday a project was announced to provide cross-compiler
low level benchmarks to help focus performance issues.

The Haskell of 2007 is a very different beast from 2000: its
significatnly eaier to reach OCaml, or even C-like performance, now than
it was even a year ago.  Just introducing a strict, packed string type
makes a huge difference.

Performance concerns are very hot right now in the Haskell community!

And compared to ruby or python we're swimming along ;)
> So, for those avoiding fundamental issues I would suggest stretching
> imagination into successors of Wiki and consider something that starts as
> automated online benchmarking. It could:
> (1) initiate research that would answer the questions you asked me:-)
> (2) introduce performance awareness through immediate feedback
> (3) automatically collect test results
> (4) feed databases with classified results and reusable code
> (5) pinpoint bad solutions if combined with inductive database
> (6) evolve into a mighty development platform if combined with prove system.
> (7) in 20 years be referred as Haskell method...

These are all good ideas. Feel free to contribute code! You could start
by modifying the night benchmarks for GHC to include statistics stating
performance changes with respect to previous runs, so we know if things
are getting better or worse.

As a developer of libraries where performance is very important, I know
that once I have performance numbers, I tend to try to make those
numbers smaller! Its good motivation.

-- Don

More information about the Haskell mailing list