<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 2:46 PM, Renato Golin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 31 March 2016 at 21:41, Mehdi Amini via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> TLDR: I totally support considering compile time regression as bug.<br>
<br>
</span>Me too.<br>
<br>
I also agree that reverting fresh and reapplying is *much* easier than<br>
trying to revert late.<br>
<br>
But I'd like to avoid dubious metrics.<br>
<span class=""><br>
<br>
> The closest I could find would be what Chandler wrote in:<br>
> <a href="http://reviews.llvm.org/D12826" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12826</a> ; for instance for O2 he stated that "if an<br>
> optimization increases compile time by 5% or increases code size by 5% for a<br>
> particular benchmark, that benchmark should also be one which sees a 5%<br>
> runtime improvement".<br>
<br>
</span>I think this is a bit limited and can lead to which hunts, especially<br>
wrt performance measurements.<br>
<br>
Chandler's title is perfect though... Large can be vague, but<br>
"super-linear" is not. We used to have the concept that any large<br>
super-linear (quadratic+) compile time introductions had to be in O3<br>
or, for really bad cases, behind additional flags. I think we should<br>
keep that mindset.<br>
<span class=""><br>
<br>
> My hope is that with better tooling for tracking compile time in the future,<br>
> we'll reach a state where we'll be able to consider "breaking" the<br>
> compile-time regression test as important as breaking any test: i.e. the<br>
> offending commit should be reverted unless it has been shown to<br>
> significantly (hand wavy...) improve the runtime performance.<br>
<br>
</span>In order to have any kind of threshold, we'd have to monitor with some<br>
accuracy the performance of both compiler and compiled code for the<br>
main platforms. We do that to certain extent with the test-suite bots,<br>
but that's very far from ideal.<br>
<br>
So, I'd recommend we steer away from any kind of percentage or ratio<br>
and keep at least the quadratic changes and beyond on special flags<br>
(n.logn is ok for most cases).<br>
<span class=""><br>
<br>
> Since you raise the discussion now, I take the opportunity to push on the<br>
> "more aggressive" side: I think the policy should be a balance between the<br>
> improvement the commit brings compared to the compile time slow down.<br>
<br>
</span>This is a fallacy.<br>
<br>
Compile time often regress across all targets, while execution<br>
improvements are focused on specific targets and can have negative<br>
effects on those that were not benchmarked on. Overall, though,<br>
compile time regressions dilute over the improvements, but not on a<br>
commit per commit basis. That's what I meant by which hunt.<br>
<br>
I think we should keep an eye on those changes, ask for numbers in<br>
code review and even maybe do some benchmarking on our own before<br>
accepting it. Also, we should not commit code that we know hurts<br>
performance that badly, even if we believe people will replace them in<br>
the future. It always takes too long. I myself have done that last<br>
year, and I learnt my lesson.<br>
<br>
Metrics are often more dangerous than helpful, as they tend to be used<br>
as a substitute for thinking.<br></blockquote><div><br></div><div>One of my favorite quotes:</div><div>"The results are definitely numbers, but do they have very much at all to do with the problem?" - Forman Acton, "Numerical Methods that (usually) Work"</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My tuppence.<br>
<br>
--renato<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>