[Haskell-cafe] Climbing up the shootout...

[Jules Bean]

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 
isolation.

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 
program.

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.

Jules