<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Adrian Hey wrote:<br>
<blockquote type="cite" cite="mid200403300942.30764.ahey@iee.org">
  <pre wrap="">On Monday 29 Mar 2004 3:49 pm, John Hughes wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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!
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Tobias?<br>
<br>
John<br>
<br>
</body>
</html>