Bug 115580 – SunSpider 1.0: 3d-morph: use epsilon to check result

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Cosmin Truta]

On QNX ARM, 64-bit float arguments must be aligned. The call to operationArrayPushDouble leads to unpredictable results, because the J_DFGOperation_EDA operation doesn't currently take this into consideration.
A patch will follow.

[Cosmin Truta]

Created attachment 200510 [details]
Patch

[George Staikos]

This definitely looks more reasonable.

[WebKit Commit Bot]

Comment on attachment 200510 [details]
Patch

Clearing flags on attachment: 200510

Committed r149548: <http://trac.webkit.org/changeset/149548>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Cosmin Truta]

I am changing the title of this bug. I had initially intended to file another patch for an unrelated issue (see comment #1), but there was too much excitement at the conference, and I ended up uploading another patch from the wrong place. Apologies for the confusion.

I will open a new bug for the issue mentioned in comment #1, and I will mark bug 115553 as a duplicate of this one.

[Cosmin Truta]

*** Bug 115553 has been marked as a duplicate of this bug. ***

[Cosmin Truta]

Created attachment 200523 [details]
C reimplementation with intermediate printouts

At the WebKit meeting, Filip Pizlo required additional data to back my precision claims regarding 1ULP roundoff errors. I will provide the test program and the intermediate output values, for comparison.
The final result obtained by the C reimplementation on Linux/x64 and QNX/ARM is exactly the same as what is given by JavaScriptCore executing 3d-morph.js on these respective platforms.

[Cosmin Truta]

Created attachment 200524 [details]
Output on Linux/x64

[Cosmin Truta]

Created attachment 200525 [details]
Output on QNX/ARM

[Cosmin Truta]

Here is the discussion:

The results of some of the sin() calls differ rarely, and by not more than 1ULP.

The same is true for the terms of the final sum. Out of 120 terms, one of them differs by 2ULP, and 18 of them differ by 1ULP. Everything else is exact, even though the decimal representation in the attached output files confusingly shows otherwise.

The accumulation of errors in summing is insignificant everywhere except at the terms 29, 32, 89, 92 and 119. That's where the accumulated partial sum gets close to zero. Adding up approximate numbers with magnitudes >10, and then canceling them out, yield roundoff errors which, however small, differ in terms of their exponent, not mantissa, let alone ULPs. In fact, the mantissa at these particular locations is zero, and the exponent differences are significant.

As the error accumulate, the accumulated difference at term 118 is 66ULP, which is not a lot. It is, on the contrary, quite reasonable.

But that becomes very significant when term 119 wants to cancel out everything that had been summed before. 66ULP around the magnitude 8.271 becomes something wildly different when placed around the magnitude 0.