<div dir="ltr">Hi Nicolas,<div><br></div><div>In my opinion we should look at nofib (slow) and make sure that</div><div><br></div><div>1) it&#39;s at least neutral on average (runtimes and preferably allocations too),</div>

<div>2) there are some benchmarks that improve significantly (that&#39;s why we&#39;re making the change after all), and</div><div>3) we can attribute the losses to something other than significantly worse Core (or at least more programs get better than get worse).</div>

<div><br></div><div>If these 3 hold and the compile times aren&#39;t up too much, I think it&#39;s a candidate for being on by default in -02.</div><div><br></div><div>In my mind the key is to understand why the programs that got worse got worse. For example, when I enabled -funbox-small-strict-fields by default there were some losers, but the reasons these were losers was more accidental than due to -funbox-small-strict-fields so I was happy to turn it on by default anyway.</div>

<div><br></div><div>-- Johan</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 30, 2013 at 12:28 PM, Nicolas Frisby <span dir="ltr">&lt;<a href="mailto:nicolas.frisby@gmail.com" target="_blank">nicolas.frisby@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>TO: Performance czars and devs</div><div><br></div><div>I pushed a patch yesterday enabling a second demand analysis at the end of the core2core simplification pipeline. The flag is -flate-dmd-anal, and it is off by default.</div>



<div><br></div><div>My question:</div><div><br></div><div>  What&#39;s the protocol for deciding if -O2 should imply it?</div><div><br></div><div>See <a href="http://ghc.haskell.org/trac/ghc/wiki/LateDmd" target="_blank">http://ghc.haskell.org/trac/ghc/wiki/LateDmd</a> for context.<br>



</div><div><br></div><div>In particular, this section includes highlights of some nofib runs I did.</div><div><br></div> <a href="http://ghc.haskell.org/trac/ghc/wiki/LateDmd#Newperformancenumbers" target="_blank">http://ghc.haskell.org/trac/ghc/wiki/LateDmd#Newperformancenumbers</a><br>



<div><br></div><div>For some tests, it decreases allocation by 10% to 20%. But on the platforms I have tried, it causes a couple repeatable slowdowns, up to 10%. I&#39;ve investigated a bit, but haven&#39;t found any clear explanations. I&#39;m worried that it&#39;s caching effects, eg.</div>



<div><br></div><div>Any suggestions on how I should proceed with my investigation?</div><div><br></div><div>Also: I&#39;d appreciate if any developer would generously run some benchmarks on various platforms they might have and add them to the same section in the wiki page.</div>



<div><br></div><div> <a href="http://ghc.haskell.org/trac/ghc/wiki/LateDmd#Newperformancenumbers" target="_blank">http://ghc.haskell.org/trac/ghc/wiki/LateDmd#Newperformancenumbers</a></div><div><br></div><div>NB That it is unfortunately key to build the libraries twice: once with -flate-dmd-anal in GhcLibHcOpts and once without. I have not determined how to do this robustly without a distclean  please let me know if you have a better method.</div>



<div><br></div>So I&#39;ve used<br><br># one of the following<br><div>#GhcLibHcOpts  = -O2 # both with and without -flate-dmd-anal<br>GhcLibHcOpts  = -O2 -flate-dmd-anal<br>SplitObjs     = NO<br>DYNAMIC_BY_DEFAULT  = NO<br>



DYNAMIC_GHC_PROGRAMS = NO<br><br>The last three aren&#39;t necessary, but please record what you use, if you are so generous as to run it :).<br><br><div>Thanks.</div></div></div>
</blockquote></div><br></div>