[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