[Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability]

[Don Stewart]

andrewcoppin:
> Don Stewart wrote:
> >I've written an extended post on how to understand and reliably optimise
> >code like this, looking at it all the way down to the assembly.
> >
> >The result are some simple rules to follow for generated code as good
> >as gcc -O2.
> >
> >Enjoy,
> >
> >    http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast
> >  
> 
> A well-written piece, as always.
> 
> My feelings are ambivilent. On the one hand, it's reassuring that such 
> good performance can be obtained without resorting to calling C, 
> explicit unboxed types, GHC-specific hacks, strictness annotations, 
> manual seq calls, strange case expressions, or really anything remotely 
> odd. It's fairly plain Haskell '98 that most beginners would be able to 
> read through and eventually understand. And yet it's fast.
> 
> On the other hand, this is the anti-theisis of Haskell. We start with a 
> high-level, declarative program, which performs horribly, and end up 
> with a manually hand-optimised blob that's much harder to read but goes 
> way faster. Obviously most people would prefer to write declarative code 
> and feel secure that the compiler is going to produce something efficient.
> 
> If the muse takes me, maybe I'll see if I can't find a less ugly way to 
> do this...
> 

I don't understand what's ugly about:

        go s l x | x > m      = s / fromIntegral l
                 | otherwise  = go (s+x) (l+1) (x+1)

And the point is that it is *reliable*. If you make your money day in, day out
writing Haskell, and you don't want to rely on radical transformations for
correctness, this is a sensible idiom to follow.

Nothing beats understanding what you're writing at all levels of abstraction.

-- Don