<div class="gmail_quote">On Fri, Nov 13, 2009 at 12:26 AM, Simon Peyton-Jones <span dir="ltr">&lt;<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>&gt;</span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

My goal is for INLINE pragmas to be very predictable.  I can&#39;t decode your message enough to offer any insights; thank you Roman, who is closer to it, for helping.<br></blockquote><div><br></div><div>Things are considerably different with HEAD than with 6.10.4. HEAD is indeed spotting and exploiting many of the opportunities for inlining, while 6.10.4 is a bit of a morass. The difference is stark: my test program runs in 0.7 seconds with HEAD, and 1.2 with 6.10.4.</div>
<div><br></div><div>Here&#39;s a rough table of my results:</div><div><br></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">6.10.4   8.39 seconds</font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">HEAD     0.50</font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace"><span class="Apple-style-span" style="font-family: arial; "><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">HEAD*    0.50</font></div>
<div><span class="Apple-style-span" style="font-family: &#39;courier new&#39;, monospace; ">6.10.4*  0.39</span></div></span></font></div><div><span class="Apple-style-span" style="font-family: &#39;courier new&#39;, monospace; ">6.10.4** 0.34</span></div>
<div><br></div><div>The asterisk above denotes the removal of a single INLINE pragma from the text library.</div><div>The doubled asterisk denotes the removal of a piece of indirection: instead of length defined as lengthI and both marked as INLINE, I manually inlined lengthI into the body of length.</div>
<div><br></div><div>For your amusement, GNU &quot;wc -m&quot; takes 1.1 seconds to count the number of Unicode characters in the same file, so I think that our combination of performance and brevity is <i>wonderful</i>. Thanks!</div>
<div><br></div><div>So HEAD is far better than 6.10.4 (yay!), but a little tweaking of the library code makes the 6.10.4 code faster again (boo!). The HEAD inliner seems, as you hoped, to be behaving far more predictably than its predecessor.</div>
<div><br></div><div>If you&#39;d like to investigate the remaining performance discrepancy between 6.10.4 and HEAD, I&#39;ll create a Trac ticket with instructions on how to reproduce my numbers.</div><div><br></div><div>
In the time between now and the release of 6.14, I wonder what to do. I&#39;m building 6.12 to see how it fares, but my experience with 6.10 so far suggests that the behaviour of the 6.12 inliner will be fragile and difficult to understand, which is a bit of a shame. On that older code base, it seems that I can get really good fused performance, or okay unfused performance, but not both.</div>
</div>