Bug 115580 - SunSpider 1.0: 3d-morph: use epsilon to check result
Summary: SunSpider 1.0: 3d-morph: use epsilon to check result
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
: 115553 (view as bug list)
Depends on:
Reported: 2013-05-03 17:32 PDT by Cosmin Truta
Modified: 2013-05-04 02:21 PDT (History)
3 users (show)

See Also:

Patch (1.68 KB, patch)
2013-05-03 17:41 PDT, Cosmin Truta
no flags Details | Formatted Diff | Diff
C reimplementation with intermediate printouts (1.33 KB, text/plain)
2013-05-04 01:42 PDT, Cosmin Truta
no flags Details
Output on Linux/x64 (11.49 KB, text/plain)
2013-05-04 01:50 PDT, Cosmin Truta
no flags Details
Output on QNX/ARM (11.49 KB, text/plain)
2013-05-04 01:50 PDT, Cosmin Truta
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cosmin Truta 2013-05-03 17:32:45 PDT
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.
Comment 1 Cosmin Truta 2013-05-03 17:41:09 PDT
Created attachment 200510 [details]
Comment 2 George Staikos 2013-05-03 18:46:34 PDT
This definitely looks more reasonable.
Comment 3 WebKit Commit Bot 2013-05-03 19:11:01 PDT
Comment on attachment 200510 [details]

Clearing flags on attachment: 200510

Committed r149548: <http://trac.webkit.org/changeset/149548>
Comment 4 WebKit Commit Bot 2013-05-03 19:11:03 PDT
All reviewed patches have been landed.  Closing bug.
Comment 5 Cosmin Truta 2013-05-04 01:18:38 PDT
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.
Comment 6 Cosmin Truta 2013-05-04 01:21:56 PDT
*** Bug 115553 has been marked as a duplicate of this bug. ***
Comment 7 Cosmin Truta 2013-05-04 01:42:31 PDT
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.
Comment 8 Cosmin Truta 2013-05-04 01:50:09 PDT
Created attachment 200524 [details]
Output on Linux/x64
Comment 9 Cosmin Truta 2013-05-04 01:50:41 PDT
Created attachment 200525 [details]
Output on QNX/ARM
Comment 10 Cosmin Truta 2013-05-04 02:21:21 PDT
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.