<div dir="ltr">On Thu, Mar 28, 2013 at 11:33 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 28 March 2013 18:10, Daniel Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<br>

> I'm fine with this form of cowardice, as long as the changes can be<br>
> reasonably expected to not hide a potential correctness bug (and sqlite is<br>
> not a benchmark I anticipate to be the one to expose FP math errors). I made<br>
> a large number of these changes to try and stabilize the output of<br>
> benchmarks as part of moving to using reference outputs.<br>
<br>
</div>The problem with sqlite3 is that the FP math in is is bogus. The code<br>
abuses of FP precision as if they were real numbers, and that's asking<br>
for trouble.<br>
<br>
For instance, if I round to 5 digits the number 1.55555555, sometimes<br>
it produces 1.55554999999 which doesn't even make sense. So the<br>
problem in sqlite3 is not just the FP math, but also how the result is<br>
converted to strings, which affect the output fidelity.<br></blockquote><div><br></div><div style>Okay, I'll trust you are on top of this. :)</div><div style><br></div><div style>I seem to recall hitting a similar kind of bug in another benchmark, it is possible to just change the sqlite code to use a more standard implementation of the conversion (like sprintf?).</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Please still file the bug with the fpcmp utility, with the two inputs that<br>
> show the problem.<br>
<br>
</div>Will do. I'll try to isolate the issue to fpcmp only.</blockquote><div><br></div><div style>Thanks!</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br>
> One thing I do find a little odd is that all of the tests in the test suite<br>
> pass on ARM on iOS, so I'm a little curious what platform/architecture<br>
> difference causes you to see this. Any ideas?<br>
<br>
</div>SoftFP?<br>
<br>
There are other tests (Burg, anagram, lemon) which fail on ARM (hf)<br>
and on my laptop (x86_64) but coincidentally with the exact same<br>
output. Anagram seems to be due to qsort being different, so the libc<br>
version might be the culprit.<br></blockquote><div><br></div><div style>Makes sense. My preferred fix for those is to augment the input and comparison routine so the array has a total ordering, which makes it independent of the actual sort implementation. However, this can also be a pain.</div>
<div style><br></div><div style>This is another place where it might be very handy to have a platform independent runtime library that we could build once and link in to all the executables, and start accumulating implementations of all the things that platform dependencies in the program output. Honestly, adding that shouldn't even be that much work... maybe if I can scratch some time together...</div>
<div style><br></div><div style>Do you have a comprehensive list of all the tests that are failing presumed due to bogus reference output mismatches?</div><div style><br></div><div style> - Daniel</div><div style><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>