<div dir="ltr">On 28 February 2013 18:53, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">I'm really confused by what you're saying/getting at.</span></div>
</blockquote><div><br></div><div style>We both are... ;)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">Are you suggesting that these are acceptable tests but that my</span><br>
</div>
proposal to add "execute multiple times until desired confidence is<br>
achieved" on top of them would be problematic? Or are you suggesting<br>
that these are examples of bad ideas that are similar/equivalent to my<br>
idea?<br></blockquote><div><br></div><div style>Linpack and Dhrystone are bad examples of compiler tests (IMHO), since they're developed as platform tests. (see below)</div><div style><br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think they're equivalent & I think they're a bad idea as a test suite.<br></blockquote><div><br></div><div style>I agree the tests we currently run could be much better executed.</div><div><br></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Execution for benchmarks should be deterministic in their behavior<br>
(including execution time/space) not based on clock/wall time<br>
(measuring execution time of an annealing algorithm that spends N<br>
seconds annealing is useless, for example... because it's always going<br>
to take N seconds).<br></blockquote><div><br></div><div style>Yes, you got me wrong, that would be silly. ;)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3 seconds +/- 0.25 of a second" (or something like that - of course we<br>
could keep all the actual run times in the report & summarize it in<br>
different ways for different clients).<br></blockquote><div><br></div><div style>I'd prefer to only output raw numbers and let presentation / crunching logic to the infrastructure.</div><div><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It could even go a step further and use the previous runs to decide<br>
how much confidence was required for the current run (eg: if<br>
yesterday's run was 3+/-0.25 and after a fewer runs today the test<br>
reached 5+/-1 we could stop running even though the confidence<br>
interval was wider - because we're already way outside the bounds<br>
based on yesterday's performance). This is probably overkill but just<br>
an example.<br></blockquote><div><br></div><div style>Not all tests have clear idea of confidence. Changing benchmarks to add the idea of confidence requires target specific behaviour (see Livermore Loops) and that's not a good way to spot compiler regressions (IMHO), but is still a valid platform benchmark.</div>
<div style><br></div><div style>My main point is the difference between platform (CPU+MEM+OS+Software+etc), rather than simply compiler optimization and code quality benchmarks.</div><div style><br></div><div style>The first category allows heuristics and dynamic testing (confidence check, etc), the second doesn't.</div>
<div style><br></div><div style>Things like micro-benchmarks or vectorization tests can suffer a lot from change in one instruction, and if you add heuristics, you can eliminate the problem before even running the test (by detecting the slowness and trying something different, for example), and we'd never spot the regression that will show in user code (where no heuristics is being done).</div>
<div style><br></div><div style>Not to mention that simply increasing the number of cycles by a fixed amount is far simpler to do on a batch of hundreds of completely different benchmarks. :D</div><div style><br></div><div style>
cheers,</div><div style>--renato</div></div></div></div>