On 28-11-2010 5:49, Dmitry Olshansky wrote:
On 26.11.2010 23:02, Don wrote:
The code below compiles to a single machine instruction, yet the
results are CPU manufacturer-dependent.
----
import std.math;
void main()
{
assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
== 0x1.bba4a9f774f49d0ap+4L); // Pass on Intel, fails on AMD
}
----
The results for yl2x(0x1.0076fc5cc7933866p+40L, LN2) are:
Intel: 0x1.bba4a9f774f49d0ap+4L
AMD: 0x1.bba4a9f774f49d0cp+4L
The least significant bit is different. This corresponds only to a
fraction of a bit (that is, it's hardly important for accuracy. For
comparison, sin and cos on x86 lose nearly sixty bits of accuracy in
some cases!). Its importance is only that it is an undocumented
difference between manufacturers.
The difference was discovered through the unit tests for the
mathematical Special Functions which will be included in the next
compiler release. Discovery of the discrepancy happened only because
of several features of D:
- built-in unit tests (encourages tests to be run on many machines)
- built-in code coverage (the tests include extreme cases, simply
because I was trying to increase the code coverage to high values)
- D supports the hex format for floats. Without this feature, the
discrepancy would have been blamed on differences in the
floating-point conversion functions in the C standard library.
This experience reinforces my belief that D is an excellent language
for scientific computing.
Thanks to David Simcha and Dmitry Olshansky for help in tracking this
down.
Glad to help!
I was genuinely intrigued because not more then a few weeks ago I
discussed with a friend of mine a possibility of differences in FP
calculations of AMD vs Intel.
You see, his scientific app yielded different results when working at
home/at work, which is a frustrating experience. Since that's exactly
same binary, written in Delphi (no C run-time involved and so on) and
environment is pretty much the same... I suggested to check CPU vendors
just in case... of course, different.
In the meantime, I sort of "ported" the test case to M$ c++ inline asm
and posted it on AMD forums, let's see what they have to say.
http://forums.amd.com/forum/messageview.cfm?catid=319&threadid=142893&enterthread=y
<http://forums.amd.com/forum/messageview.cfm?catid=319&threadid=142893&enterthread=y>
http://forums.amd.com/forum/messageview.cfm?catid=29&threadid=135771
This post also talks about a fyl2x bug. Wonder if it's the same bug.
L.
