Seems fairly reasonable to me.<div><br></div><div>I don't know what size of arrays you are dealing with, if they are reasonably small it is probably also fine to just output each element in the result.</div><div><br></div>
<div>It's fine to start by just setting FP_TOLERANCE to a small value and if it breaks in the future because of an actual precision change we can tweak it.</div><div><br></div><div>Thanks for the reformatting, its great to see new benchmarks getting added!</div>
<div><br></div><div> - Daniel</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 16, 2012 at 12:28 PM, Renato Golin <span dir="ltr"><<a href="mailto:rengolin@systemcall.org" target="_blank">rengolin@systemcall.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Daniel, Nadav, Hal,<br>
<br>
So, after some painstakingly boring re-formatting, I've split the 24<br>
kernels into 24 files (and left a horrible header file with code in<br>
it, which I'll clean up later).<br>
<br>
Since we're taking times in the benchmark tool, and we're trying to<br>
assert the quality of the FP approximation by the vectorization, I'll<br>
try to come up with a reasonable watermark for each test. Maybe adding<br>
the values of all elements in the result vector, or something, and<br>
printing that value, using FP_TOLERANCE to detect errors in the<br>
vectorized code.<br>
<br>
Does this seem sensible?<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div>