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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
