floating point inconsistency
Christoph Groth
cwg@falma.de
Tue Feb 16 12:47:00 GMT 2010
Andrew Haley <aph@redhat.com> writes:
>> If I take the second (-O1) binary and execute it on an Opteron it
>> produces the _first_ result. Thus, the same static binary produces
>> different results on different processors!
>
> That is strange. A bit of debugging would be required to understand
> why that happens.
It boils down to sincos giving different results on core2 and opteron,
as demonstrated by the following program (compiled with "g++ test.cc").
################################################################
#include <iostream>
#include <cmath>
using namespace std;
double angle = 0.60066412215710574;
int main()
{
double sinval, cosval;
sincos(angle, &sinval, &cosval);
cout << cosval - cos(angle) << '\n';
}
################################################################
which produces
1.11022e-16
on a core2 and
0
on Opteron.
>> I observe this problem also with g++ 4.4.2. It seems only a tiny
>> difference, but this inconsistency makes my Montecarlo simulation
>> produce different results on different machines.
>>
>> Any help with this would be greatly appreciated.
>
> gcc applies an optimization to code where the same angle is passed to
> sin and cos. This is turned into a single call to sincos() aka
> __builtin_cexpi(). Clearly the lsb is different in the optimized
> case.
Thanks, that clarified it. I can avoid this inconsistency while staying
portable by computing cos(x) as sqrt(1 - sin(x)^2).
Christoph
More information about the Gcc-help
mailing list