I wonder if that's a client program bug (i.e. the results are
complete nonsense, caused by an uninitialized variable or so)
or if it's a validator problem.
(I have a few of those "no consensus yet" things too)
YES!!!!!!!! Was about time the minority strikes back!!
Again, as has been said before: The devs are working on this issue. I guess after we'll see SSE optimized apps (hopefully soon ;-) ) mixed with non-optimized apps in the field, results will even become more "slightly unequal", so this issue is kind of important.
Again, as has been said before: The devs are working on this issue. I guess after we'll see SSE optimized apps (hopefully soon ;-) ) mixed with non-optimized apps in the field, results will even become more "slightly unequal", so this issue is kind of important.
The inaccuracy of the SSE code means extra 0,1% difference in the results.
Again, as has been said before: The devs are working on this issue. I guess after we'll see SSE optimized apps (hopefully soon ;-) ) mixed with non-optimized apps in the field, results will even become more "slightly unequal", so this issue is kind of important.
The inaccuracy of the SSE code means extra 0,1% difference in the results.
Is that small enough for current validators to cope with? Well, maybe the current cross-platform validation problem isn't related to floating point accuracy at all, but to other things? Different implementations of qsort come to mind, so that different permutations of items with equal "weight" may result when sorting candidates.
About half the WU run on Linux failed to validate against Windows :-(.
Usually this kind of validation problem happens less frequently (also the host produced better results with a different datapack in the past).
CU
BRM
Wow. If my Mac was coming out on the short end that frequently, I'd be thinking about putting both cores on CPDN or Rosetta until they had solved the problem here at Einstein. As it is, I've only had one WU that failed to validate against Windows (ID #33893916).
The win got the short end
)
The win got the short end again.
I wonder if that's a client
)
I wonder if that's a client program bug (i.e. the results are
complete nonsense, caused by an uninitialized variable or so)
or if it's a validator problem.
(I have a few of those "no consensus yet" things too)
one were MAC came out short.
)
one were MAC came out short. http://einsteinathome.org/workunit/33877750
Anders n
The Mac was unlucky to be
)
The Mac was unlucky to be paired with two windows.
RE: one were MAC came out
)
Two PowerMacs beat WinXP: http://einsteinathome.org/workunit/33871776
RE: RE: one were MAC came
)
YES!!!!!!!! Was about time the minority strikes back!!
Again, as has been said before: The devs are working on this issue. I guess after we'll see SSE optimized apps (hopefully soon ;-) ) mixed with non-optimized apps in the field, results will even become more "slightly unequal", so this issue is kind of important.
CU
BRM
RE: Again, as has been said
)
The inaccuracy of the SSE code means extra 0,1% difference in the results.
RE: RE: Again, as has
)
Is that small enough for current validators to cope with? Well, maybe the current cross-platform validation problem isn't related to floating point accuracy at all, but to other things? Different implementations of qsort come to mind, so that different permutations of items with equal "weight" may result when sorting candidates.
CU
BRM
Well, if developers are
)
Well, if developers are looking for test data on the cross-platform validation problem, here's an interesting datapack
http://einsteinathome.org/host/777013/tasks
About half the WU run on Linux failed to validate against Windows :-(.
Usually this kind of validation problem happens less frequently (also the host produced better results with a different datapack in the past).
CU
BRM
RE: Well, if developers are
)
Wow. If my Mac was coming out on the short end that frequently, I'd be thinking about putting both cores on CPDN or Rosetta until they had solved the problem here at Einstein. As it is, I've only had one WU that failed to validate against Windows (ID #33893916).