On Wed, Nov 7, 2012 at 12:39 AM, Renato Golin <span dir="ltr"><<a href="mailto:rengolin@systemcall.org" target="_blank">rengolin@systemcall.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 6 November 2012 22:28, Daniel Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<br>

> Is it possible instead to refactor the tests so that each binary corresponds<br>
> to one test? For example, look at how Hal went about integrating TSVC:<br>
<br>
</div>It should be possible. I'll have to understand better what the<br>
preamble does to make sure I'm not stripping out important stuff, but<br>
also what to copy to each kernel's initialization.<br>
<br>
Also, I don't know how the timing functions perform across platforms.<br>
I'd have to implement a decent enough timing system, platform<br>
independent, to factor out the initialization step.<br></blockquote><div><br></div><div>The way we handle timing of all the other tests is just by timing the executable. This isn't perfect, but its what we use everywhere else so we should stick with keeping it outside the tests.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
<br>
> Other things that I would *like* before integrating it:<br>
>  - Rip out the CPU ID stuff, this isn't useful and adds messiness.<br>
<br>
</div>Absolutely, that is meaningless.<br>
<div class="im"><br>
<br>
>  - Have the test just produce output that can be compared, instead of<br>
> including its own check routines<br>
<br>
</div>I can make it print numbers in order, is that good enough for the<br>
comparison routines?<br></blockquote><div><br></div><div>Yup.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

If I got it right, the tests self-validates the results, so at least<br>
we know it executed correctly in the end. I can make it produce "OK"<br>
and "FAIL" either way with some numbers stating the timing.<br></blockquote><div><br></div><div>Yeah, we can get rid of that, the way we check all the other tests is by comparing to reference outputs or output from a reference binary (compiled by the system compiler).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
>  - Have the tests run for fixed iterations, instead of doing their own<br>
> adaptive run<br>
<br>
</div>Yes, that's rubbish. That was needed to compare the results based on<br>
CPU specific features, but we don't need that.<br>
<div class="im"><br>
<br>
>  - Produce reference output files, so it works with USE_REFERENCE_OUTPUT=1<br>
<br>
</div>Is this a simple diff or do you compare the numerical results by value+-stdev?<br></blockquote><div><br></div><div>We have support for value + tolerance. You can set FP_TOLERANCE=.0001 or so in the Makefile to tune the limit. For example see SingleSource/Benchmarks/Misc/Makefile.</div>
<div><br></div><div> - Daniel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
cheers,<br>
--renato<br>
</blockquote></div><br></div>