Validator discrepancy rates
2 Oct 2010 1:32:09 UTC
Topic 195352
(moderation:
Pasquale asked this question over in Orbit, so I was wondering if Bernd or Oliver might be able to answer it.
Quote:
The validator currently allows for up to 1% discrepancy between floating point numbers. This takes care of most rounding-off differences, except when values are extremely small and so their relative difference can be bigger than 1%. We need to look more in detail in these cases to handle them better.
Currently, the pass rate of the Linux app is the highest, 98.5%. Then Windows follows at 96.9%, and Mac OS X at 89.3%. These numbers include two main source of non-success: aborted WUs and WUs that fail to compute. If we neglet the aborted WUs (that's not properly a validation error), then the success rates become:
99.3% on Linux
99.1% on Windows
89.7% on Mac OS XThe Mac OS X version is clearly behind, and needs some more testing, but that does not affect too much orbit@home, as only about 2% of all the WUs are crunched on Mac OS X, compared to 78% on Windows, and 20% on Linux.
There is still some margin for improvement of course, and we know already some of the points in the code that need to be reworked, but overall we are extremely satisfied with the current success rate. I would be curious on the numbers that other BOINC projects get, if you have them please post.
Validator discrepancy rates
)
I guess they should look at discrepancies introduced by different compiler behaviour:
On Mac OS, for Intel targets it's the default to use the SSE2 instruction set and to avoid the "legacy" x87 FPU instructions wherever possible. They can do that because all intel Macs ever sold feature SSE2.
I'd guess that their Windows and Linux apps are compiled so that SSE2 is not used at all (to be compatible with older hosts).
There can be subtle differences in the results because x87 FPU code will represent intermediate results internally in 80 bit precision, while SSE2 offers 64 bit or 32 bit precision only.
CU
HB
Regarding accuracy on
)
Regarding accuracy on floating point numbers: this will hardly catch everything, but are the apps using Kahan summation where needed?
As a side note, I wonder how much slower using MPFR (with a reasonable number of bits) would be. Might be an interesting tool for validation, but porting everything over would be a pain.
I was one of the users on
)
I was one of the users on Orbit that took exception to Pasquale's response and pulled my machine off Orbit. I don't see problems here with validation, except for the one that was recognized a couple of days ago. Pasquale seems to have his head in the sand regarding the problem over there. In my past (48 years of programming) whenever computations didn't compare within a small epsilon, the cause was my code, not the compiler nor "libraries".
Can anyone shed some light on
)
Can anyone shed some light on numbers, as per the last sentence of the last paragraph?
BOINC blog