Floating Point + Threads?

dsimcha dsimcha at yahoo.com
Sat Apr 16 11:43:27 PDT 2011


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 .


More information about the Digitalmars-d mailing list