<div dir="ltr">Hi Renato,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">Basically, I cannot see<br></span><span style="font-family:arial,sans-serif;font-size:13px">how 50% regressions on any benchmark can be a good thing, regardless<br></span><span style="font-family:arial,sans-serif;font-size:13px">of the wins elsewhere.</span></blockquote><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">The 50% number is code size, not performance. The performance regression is 3.54% for mesa (the largest).</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Cheers,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">James</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 September 2014 13:31, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9 September 2014 11:19, Kevin Qin <<a href="mailto:kevinqindev@gmail.com">kevinqindev@gmail.com</a>> wrote:<br>
> I can give more details on the performance regressions here. Basically, partial unrolling contributes small performance improvement, regressions and code size changes. Most of the regressions are caused by the runtime unrolling prologue. This prologue will do some extra work on checking the loop iterations and execute the reminder times of loop bodies. If the runtime unrolled loop is inside another loop, and inner loop count for each running is quite small, then there's a overhead happened in the prologue and caused the regession.<br>
<br>
</span>One heuristics that is pretty obvious here is not to add dynamic<br>
checks for inner loops. A better one is to check if the inner loop<br>
induction variable depends only on values external to the inner loop.<br>
Any heuristics that determines that you only need one run-time check,<br>
outside the external loop.<br>
<span class=""><br>
<br>
> So I suggest we can enable it first, and then try to get it even better in future.<br>
<br>
</span>That's the point, SPEC is *not* "better".<br>
<br>
Some are better, others are worse. The geomean doesn't mean that much<br>
on artificial benchmarks. It just means that; for the very restrictive<br>
set of scenarios you're considering, you hurt less than made better,<br>
but that doesn't translate to anything in the wild.<br>
<br>
It may be that the conditions that got better here were made<br>
unrealistically large and the ones that got worse weren't, so the<br>
negative impact is proportionally greater, and your geomean would lie<br>
about real world code. You just don't know. Basically, I cannot see<br>
how 50% regressions on any benchmark can be a good thing, regardless<br>
of the wins elsewhere.<br>
<br>
I believe Chandler has a good way of testing performance on real world<br>
code, so I'm copying him to have a look at this change. Others might<br>
try on their work loads (do Chromium folks test performance?).<br>
<br>
<br>
cheers,<br>
--renato<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>