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

[John Hughes]

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

_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell