<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 12:19 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 18 February 2015 at 20:10, Jack Howarth<br>
<<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br>
> Well, I assumed that llvm releases were supposed to be more than just<br>
> glorified semi-annual snapshots.<br>
<br>
It's that time of the year that we get all together and run some tests<br>
and benchmarks we normally don't run the rest of the year, but we stop<br>
the analogy short of giving each other presents. :)<br>
<br>
So far we've being pretty good at spotting regressions like that and<br>
fixing them later, and people like Michael will keep us on our toes if<br>
we deliver it again with the regression, or if we deviate too much<br>
from GCC.<br>
<br>
cheers,<br>
--renato<br>
_______________________________________________<br></blockquote></div><br><br><br></div><div class="gmail_extra">By looking at some numbers only and say that "Performance increased"  or "Performance decreased" is not a correct way of decision making .<br><br></div><div class="gmail_extra">It is necessary to specify a set of programs which will be a representative sample of real life usage population ( it is necessary to exceed at least 60 programs to be able to assume "Central Limit Theorem" is valid , i.e. , sample is from a "Normal Distribution" ) .<br><br><br></div><div class="gmail_extra">Then by using the SAME execution environment ( means the SAME programs running in the computers , best is not to run any programs other than compilation and running the program , the computers may be in any model , from 500 MHz to 5 GHz , with different operating systems )  .<br><br><br></div><div class="gmail_extra">After obtaining compilation times , they should be analysed by using a convenient statistical package <br></div><div class="gmail_extra">to test equality of variances and equality of means by using   "Pair-wise correlated values" .<br><br><br></div><div class="gmail_extra">Assume tests revealed that "Differences are not significant" , then to say that "There is a performance loss" is not correct .<br><br><br></div><div class="gmail_extra">If variances are different ( populations are not from the SAME distribution ) , either variability of computations are increased or decreased : Decrease is good , increase requires inspection .<br><br><br><br>If means
 are different ( populations are not from the SAME distribution ) , 
either average time of computations are increased or decreased : Decrease
 is good , increase requires inspection .<br><br><br></div><div class="gmail_extra">Repeat the above computations for -<br></div><div class="gmail_extra">- No optimization <br></div><div class="gmail_extra">- Optimizations applied<br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra">Then reasons should be checked one by one , for example :<br><br></div><div class="gmail_extra">(1) Assume a bug is corrected by introducing a check : Is it possible to remove the corrections and keep the bug to increase the speed ? Obviously  NO .<br><br></div><div class="gmail_extra">(2) In one point , optimization is ignoring a feature , but it is not a bug ( assume optimization is not applied ) .<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">(3) During code generation , there are redundant parts which may be eliminated .<br></div><div class="gmail_extra">This is not a bug , but slowing down computation , because the computed values will not be affected .<br><br><br></div><div class="gmail_extra">(4) Instead letting the programs crash blindly some new checks are introduced to prevent blind crashing : Is it necessary to eliminate such checks .<br><br></div><div class="gmail_extra">Then , it will be decided which points need improvement , and which points will be kept as it is .<br><br><br></div><div class="gmail_extra">Without doing such analyses , and pursuing a discussion on some pure different numbers and making decisions will not contribute anything to development of Clang/LLVM .<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you very much .<br><br></div><div class="gmail_extra">Mehmet Erol Sanliturk<br><br></div><div class="gmail_extra"><br><br><br><br></div><div class="gmail_extra"> <br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra"><br><br><br><br><br></div></div>