Validator discrepancy rates

MarkJ
MarkJ
Joined: 28 Feb 08
Posts: 437
Credit: 132,548,446
RAC: 7,396
Topic 195352

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 X

The 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.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 492,053,972
RAC: 142,681

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

Ver Greeneyes
Ver Greeneyes
Joined: 26 Mar 09
Posts: 140
Credit: 9,562,235
RAC: 0

Regarding accuracy on

Message 99861 in response to message 99860

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.

McSummation
McSummation
Joined: 24 Feb 05
Posts: 18
Credit: 820,944
RAC: 0

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".

MarkJ
MarkJ
Joined: 28 Feb 08
Posts: 437
Credit: 132,548,446
RAC: 7,396

Can anyone shed some light on

Can anyone shed some light on numbers, as per the last sentence of the last paragraph?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.