On 4/16/2011 2:24 PM, dsimcha wrote:
On 4/16/2011 2:15 PM, Timon Gehr wrote:
Could be something somewhere is getting truncated from real to
double, which
would mean 12 fewer bits of mantisa. Maybe the FPU is set to lower
precision
in one of the threads?
Yes indeed, this is a _Windows_ "bug".
I have experienced this in Windows before, the main thread's FPU state
register is
initialized to lower FPU-Precision (64bits) by default by the OS,
presumably to
make FP calculations faster. However, when you start a new thread, the
FPU will
use the whole 80 bits for computation because, curiously, the FPU is not
reconfigured for those.
Suggested fix: Add
asm{fninit};
to the beginning of your main function, and the difference between the
two will be
gone.
This would be a compatibility issue DMD/windows which disables the
"real" data
type. You might want to file a bug report for druntime if my suggested
fix works.
(This would imply that the real type was basically identical to the
double type in
Windows all along!)
Close: If I add this instruction to the function for the new thread, the
difference goes away. The relevant statement is:
auto t = new Thread( {
asm { fninit; }
res2 = sumRange(terms);
} );
At any rate, this is a **huge** WTF that should probably be fixed in
druntime. Once I understand it a little better, I'll file a bug report.
Read up a little on what fninit does, etc. This is IMHO a druntime bug.
Filed as http://d.puremagic.com/issues/show_bug.cgi?id=5847 .
