[Haskell] Programming language shootout (completing the Haskell entry)

John Hughes rjmh at cs.chalmers.se
Tue Mar 30 12:50:02 EST 2004


Adrian Hey wrote:

>On Monday 29 Mar 2004 3:49 pm, John Hughes wrote:
>  
>
>>Actually the cache behaviour of code generated by GHC isn't at all bad.
>>I know because I ran a student project a couple of years ago to
>>implement cache-friendly optimisations. The first thing they did was
>>cache profiling of some benchmarks, and to our surprise we discovered
>>the cache behaviour of lazy code is already pretty good. You get a lot
>>of structure in the evaluation of lazy code -- it just isn't evident in
>>the source code!
>>    
>>
>
>That's interesting. So why do you think "OCaml is so darned fast
>compared to Haskell" :-)
>
>Seriously though, is this finding consistent with the paper Nicholas
>Nethercote mentioned? I had a quick read of the paper but didn't
>take the time to digest the full significance of all tests done
>and graphs presented. But if I understood the overall conclusions
>correctly there were several reasons for relatively poor performance
>on modern processors (one of which was a high rate of cache misses).
>I suppose we should distinguish code from heap accesses here though.
>
Let me ask Tobias Gedell to comment, since he was directly involved in 
the project and probably has the actual results to hand. I'm not sure 
there's any inconsistency though: that paper finds that 60% of the 
execution time is due to data cache misses, and so a speed up of at most 
2.5x is possible by improving the cache behaviour. That's certainly very 
respectable, but our initial guess was that the potential speed-ups 
might be considerably greater. Given the high penalty of L2 cache 
misses, this still corresponds to a hit rate of 98% or so (couldn't find 
the exact figure in the paper). We were initially expecting that Haskell 
programs would miss more often than that.

The paper reports a 22% speed-up from prefetching to avoid write misses. 
If I remember rightly, we also got some decent speed-ups from 
optimisations aimed at improving the cache behaviour, although this 
wasn't using the GHC code generator, so the results aren't directly 
comparable.

Tobias?

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell/attachments/20040330/d3211b16/attachment.htm


More information about the Haskell mailing list