<div class="gmail_quote">On 20 September 2012 15:36, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 9/20/12 2:42 AM, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 19 September 2012 12:38, Peter Alexander<br></div><div><div class="h5">
<<a href="mailto:peter.alexander.au@gmail.com" target="_blank">peter.alexander.au@gmail.com</a> <mailto:<a href="mailto:peter.alexander.au@gmail.com" target="_blank">peter.alexander.au@<u></u>gmail.com</a>>> wrote:<br>

<br>
        The fastest execution time is rarely useful to me, I'm almost<br>
        always much<br>
        more interested in the slowest execution time.<br>
        In realtime software, the slowest time is often the only<br>
        important factor,<br>
        everything must be designed to tolerate this possibility.<br>
        I can also imagine other situations where multiple workloads are<br>
        competing<br>
        for time, the average time may be more useful in that case.<br>
<br>
<br>
    The problem with slowest is that you end up with the occasional OS<br>
    hiccup or GC collection which throws the entire benchmark off. I see<br>
    your point, but unless you can prevent the OS from interrupting, the<br>
    time would be meaningless.<br>
<br>
<br></div></div><div class="im">
So then we need to start getting tricky, and choose the slowest one that<br>
is not beyond an order of magnitude or so outside the average?<br>
</div></blockquote>
<br>
The "best way" according to some of the people who've advised my implementation of the framework at Facebook is to take the mode of the measurements distribution, i.e. the time at the maximum density.<br>
<br>
I implemented that (and it's not easy). It yielded numbers close to the minimum, but less stable and needing more iterations to become stable (when they do get indeed close to the minimum).<br>
<br>
Let's use the minimum. It is understood it's not what you'll see in production, but it is an excellent proxy for indicative and reproducible performance numbers.</blockquote><div><br></div><div>If you do more than a single iteration, the minimum will virtually always be influenced by ideal cache pre-population, which is unrealistic. Memory locality is often the biggest contributing performance hazard in many algorithms, and usually the most unpredictable. I want to know about that in my measurements.</div>
<div>Reproducibility is not important to me as accuracy. And I'd rather be conservative(/pessimistic) with the error.</div><div><br></div><div>What guideline would you apply to estimate 'real-world' time spent when always working with hyper-optimistic measurements?</div>
</div>