<div dir="ltr">Thanks Austin.<div><br></div><div style>The program exhibiting these behaviors is shootout/reverse-complement. The performance monitoring I used was Intel&#39;s pcm from</div><div style><br></div><div style>

<a href="http://software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-utilization">http://software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-utilization</a></div>

<div style><br></div><div style>I&#39;ve been working only on my MBP, so no perfmon yet. I plan to investigate this with different architectures/machines when this issue percolates back up my todo list.</div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 11:39 AM, Austin Seipp <span dir="ltr">&lt;<a href="mailto:aseipp@pobox.com" target="_blank">aseipp@pobox.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I mean, it certainly *seems* reasonable a 15% hit could come from<br>
pipelining changes or cache behavior or something. I don&#39;t think<br>
alignment would really be a huge issue; post-Nehalem I believe<br>
non-aligned writes/reads are extremely cheap. Non-intuitive behavior<br>
can totally happen too: I&#39;ve seen cases of adding instructions to a<br>
loop which speeds things up (e.g. by taking the extra step, you may<br>
mitigate a dependency stall, which massively helps pipelining across<br>
the loop body etc.)<br>
<br>
Nicolas, can I ask what benchmark you&#39;re looking at? And what<br>
performance tools are you using, Intels&#39;? If you&#39;re on Linux, the<br>
&#39;perf&#39; tool on a modern kernel can be used to quickly get an overview<br>
of how many cache misses/hits your process has, how many pipeline<br>
stalls occur, etc. You can then use it to drill down a bit into the<br>
assembly that&#39;s problematic.<br>
<br>
That might not give you an exact culprit (it could be many changes and<br>
accumulative hits,) but it&#39;s a start.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Jun 19, 2013 at 10:43 AM, Nicolas Frisby<br>
&lt;<a href="mailto:nicolas.frisby@gmail.com">nicolas.frisby@gmail.com</a>&gt; wrote:<br>
&gt; I&#39;m also seeing performance regressions in the shootout benchmarks that I<br>
&gt; can&#39;t identify in the asm. The new asm looks better but performs worse, with<br>
&gt; a ~15% slowdown.<br>
&gt;<br>
&gt; I fired up the performance counters in my CPU and the free Intel code for<br>
&gt; inspecting them showed that my CPU utilization took about a 10% hit, even<br>
&gt; while executing fewer total instructions.<br>
&gt;<br>
&gt;  1) Jan, perhaps we&#39;re seeing the same sort of behavior  the shootout<br>
&gt; benchmarks have extremely hot loops (hundreds of millions of iterations<br>
&gt; IIRC). I used ticky profiling too, and saw no suspicious changes in any<br>
&gt; counters.<br>
&gt;<br>
&gt;  2) Dear Low-level Gurus: How feasible is it that a ~15% slowdown in a<br>
&gt; program with a very hot loop is due to incidentally inhibiting some caching<br>
&gt; behavior (instr? data?)? Or perhaps effecting alignment? FTR my CPU is a<br>
&gt; Core i7-2620M, Sandy Bridge.<br>
&gt;<br>
&gt; Thanks all.<br>
&gt;<br>
&gt; On Wed, Jun 19, 2013 at 9:27 AM, Jan Stolarek &lt;<a href="mailto:jan.stolarek@p.lodz.pl">jan.stolarek@p.lodz.pl</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; If it&#39;s not sorted out, can you open a ticket, put in the relevant info<br>
&gt;&gt; &gt; (so<br>
&gt;&gt; &gt; we don&#39;t need to look at the email trail), and we can tackle it when you<br>
&gt;&gt; &gt; get here.<br>
&gt;&gt; Currently there&#39;s a temporary workaround: I&#39;m using new folding rules for<br>
&gt;&gt; all primitive types,<br>
&gt;&gt; except for Integer, in which case I left the old folding rules unchanged.<br>
&gt;&gt; This of course should<br>
&gt;&gt; be modified to make all rules uniform, but for now it at least passes<br>
&gt;&gt; validation. I didn&#39;t fill<br>
&gt;&gt; the ticket, because the bug does not exist yet :) It only manifests itself<br>
&gt;&gt; in my patches, which<br>
&gt;&gt; have not been applied yet. I&#39;ll add all the information from this<br>
&gt;&gt; discussion to my github fork of<br>
&gt;&gt; GHC and then move it to Trac once the bug makes it to HEAD.<br>
&gt;&gt;<br>
&gt;&gt; What worries me more about my patches is the performance regression in<br>
&gt;&gt; kahan, because I see no<br>
&gt;&gt; obvious differences in the generated assembly.<br>
&gt;&gt;<br>
&gt;&gt; Janek<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Simon<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -----Original Message-----<br>
&gt;&gt; &gt; From: <a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@haskell.org</a> [mailto:<a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@haskell.org</a>]<br>
&gt;&gt; &gt; On<br>
&gt;&gt; &gt; Behalf Of Jan Stolarek Sent: 20 May 2013 12:35<br>
&gt;&gt; &gt; To: Ian Lynagh<br>
&gt;&gt; &gt; Cc: <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt;&gt; &gt; Subject: Re: Integer constant folding in the presence of new primops<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt; If you remove everything but the quotInteger test from<br>
&gt;&gt; &gt; &gt; integerConstantFolding and compile with -ddump-rule-rewrites then<br>
&gt;&gt; &gt; &gt; you&#39;ll see that the eqInteger rule fires before quotInteger. This is<br>
&gt;&gt; &gt; &gt; presumably comparing against 0, as the definition of quot for Integer<br>
&gt;&gt; &gt; &gt; (in GHC.Real) is<br>
&gt;&gt; &gt; &gt;   _ `quot` 0 = divZeroError<br>
&gt;&gt; &gt; &gt;   n `quot` d = n `quotInteger` d<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yes, I noticed these two rules firing together - perhaps that&#39;s the<br>
&gt;&gt; &gt; explanation why. I created a small program for testing:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; main = print quotInt<br>
&gt;&gt; &gt; quotInt :: Integer<br>
&gt;&gt; &gt; quotInt = 100063 `quot` 156<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I noticed that when I define eqInteger wrapper to be NOINLINE, the call<br>
&gt;&gt; &gt; to<br>
&gt;&gt; &gt; quot is translated to Core as:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Main.quotInt =<br>
&gt;&gt; &gt;  GHC.Real.$fIntegralInteger_$cquot<br>
&gt;&gt; &gt;   (__integer 100063) (__integer 156)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; but when I change the wrapper to INLINE I get:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Main.quotInt =<br>
&gt;&gt; &gt;  GHC.Real.$fNumRatio_$cquot       &lt;-------- NumRatio instead of<br>
&gt;&gt; &gt; IntegralInteger (__integer 100063) (__integer 156)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; All rule firing happens later (I used -ddump-simpl-iterations<br>
&gt;&gt; &gt; -ddump-rule-firings), except that for $fNumRatio_$cquot the quot rules<br>
&gt;&gt; &gt; don&#39;t fire.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt; Do you also still have eqInteger wired in? It sounds like you might<br>
&gt;&gt; &gt; &gt; have given them both the same unique?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; No, they didn&#39;t have the same unique. I modified the existing rules to<br>
&gt;&gt; &gt; work<br>
&gt;&gt; &gt; on the new primops and ignore their wrappers. At the moment I reverted<br>
&gt;&gt; &gt; these changes so that I can make progress and leave this problem for<br>
&gt;&gt; &gt; later.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Janek<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; ghc-devs mailing list<br>
&gt;&gt; &gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt;&gt; &gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; ghc-devs mailing list<br>
&gt;&gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; ghc-devs mailing list<br>
&gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
&gt;<br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards,<br>
Austin - PGP: 4096R/0x91384671<br>
</font></span></blockquote></div><br></div>