[Haskell-cafe] Climbing up the shootout...
jules at jellybean.co.uk
Tue Sep 23 06:21:34 EDT 2008
Bulat Ziganshin wrote:
> and this work obviously doesn't speed up every Haskell program. so
> that we have in Haskell world now is heroic efforts to speed up
> shootout test which doesn't say anything about real Haskell
> performance. what we have on prcatice is 10-20% speedup of ghc 6.8 and
> several libs which may improve speed in some usages
If you understand performance as well as you claim to - and from your
previous postings, I believe you *do* understand performance well - then
you will know that "10-20% speedup" is almost entirely meaningless in
Any given particular program has a bottleneck; this bottleneck may be
different depending on the OS/hardware configuration, although normally
it won't be. Improvements which touch that bottleneck can have
staggering benefits in the 40-500% range; improvements which are
elsewhere have tiny <5% or non-measurale effects.
In fact, various improvements made to GHC in the 6.4-6.10 timeline have
had enormous, order-of-magnitude improvements to particular code
patterns which had particular bottlenecks. Meanwhile they may well have
had no effect at all on other code patterns which had different bottlenecks.
You may ask, what are the common code patterns? What are the common
bottlenecks? I'm not aware of good studies to answer these questions
although they probably exist; I don't read widely the research in this
area. [Naive C programs tend to IO bottleneck or Memory bottleneck; I
strongly suspect naive haskell programs tend to GC bottleneck; but I
don't think either of these observations is particularly profound or useful]
What matters to a particular programmer of course it not actually common
patterns and common bottlenecks. It is the bottleneck in his particular
However: The Shootout is a *game*.
It even says that in its name.
It's a game which many of us enjoy playing; if you don't enjoy, please
feel free not to play. Many of us find that, by playing the game, we
learn a lot of interesting things about the low-level performance of GHC
in interesting edge-cases. The quad-core machine recently added to the
benchmark has enabled us to learn interesting things about `par` and
Control.Parallel. Learning these things, and sharing them, may help us
write better programs, help us teach other people to write better
programs, and help the GHC team write a better compiler.
More information about the Haskell-Cafe