<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 28, 2017 at 11:38 PM, George Rimar via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.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"><span class="gmail-">>Now that I have a workstation setup again for doing really stable<br>
>benchmarks I decided to try a quick experiment and benchmark linking<br>
>firefox with the last 1000 revisions or so.<br>
><br>
>I used the last 1000 revision, regardless of what they changed. That<br>
>way we can get an idea of the fluctuation to expect from measurement<br>
>bias when unrelated things change.<br>
><br>
>The results are attached. Data has 3 columns. The first one is the<br>
>revision, the second one is the time and the third is the percentage<br>
>std dev reported by perf over 10 runs.<br>
<br>
</span>Looks great !<br>
<span class="gmail-"><br>
>The plot was created with gnuplot:<br>
><br>
>plot "data" using 1:2:($3 * $2 /100) title "time" with errorlines<br>
><br>
>It is interesting to see that the variation from commit to commit is<br>
>much bigger than the variation in a single commit, but the graph<br>
>allows us to find some significant commits.<br>
<br>
</span>Data in text representation might have one more column: change from<br>
previous revision in percents, that way even with text representation would<br>
be easy to find significant commits probably.<br></blockquote><div><br></div><div>Having a human readable percentage would be useful when backreferencing from the visualization to the revision number.<br></div><div><div>In general though, unless you are looking for a very specific thing (like the exact revision number of a commit you found from a visualization), scanning lists of numbers for outliers (or any insight whatsoever) is extremely unreliable. It is also very time consuming because you are never sure that you "caught everything" and so will keep scanning the data looking for things you missed (and will still miss things).</div></div><div>At the very least, if you need to scan a list of numbers like percentage increase/decrease, I would highly recommend importing it into a spreadsheet and applying conditional formatting to color large values. Then it can be scanned relatively quickly and reliably. Even better, just sort based on the percentage increase/decrease.</div><div><br></div><div>For this reason, I would always recommend printing raw data in the least human-readable format possible (while still being machine readable), e.g. for printf I would recommend something horrible like `%.18e` to mitigate the temptation to look at the raw data without some sort of analysis or visualization.<br></div><div><br></div><div>With a good visualization (in this case, a simple scatter plot; for extra credit, adding error bars like Rafael did), you can instantly see that there are 3 major revisions to look at and no larger-scale "death by 1000 cuts" progressive slowdown.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> In this case, they were:<br>
><br>
>r303689: The test has --buildit ... --build-id=none, and now the<br>
>second one is used.<br>
><br>
>r303925: Uses CachedHashStringRef again for comdat signatures.<br>
><br>
>Cheers,<br>
>Rafael<br>
><br>
>P.S.: It would be truly awesome if someone could setup a bot that does<br>
>this over various tests.<br>
<br>
</span>George.<br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div></div>