Re: small numerical differences in floating point result between wintel and Sun/SPARC

From: Tim Prince (tprince_at_nospamcomputer.org)
Date: 12/15/04 

Date: Wed, 15 Dec 2004 11:54:23 GMT

"Christian Bau" <christian.bau@cbau.freeserve.co.uk> wrote in message
news:christian.bau-01DCCE.08543615122004@slb-newsm1.svr.pol.co.uk...
> In article <nk4vr0ttmj0rrk9ujlg0s49nluph7slt34@4ax.com>,
> JS <someone@somewhere.com> wrote:
>

> > Some posters don't seem to know about /Op option. From Microsoft doc:
> >
> > "By default, the compiler uses the coprocessoršs 80-bit registers to
> > hold the intermediate results of floating-point calculations. This
> > increases program speed and decreases program size. However, because
> > the calculation involves floating-point data types that are
> > represented in memory by less than 80 bits, carrying the extra bits of
> > precision (80 bits minus the number of bits in a smaller
> > floating-point type) through a lengthy calculation can produce
> > inconsistent results.
> >
> > With /Op, the compiler loads data from memory prior to each
> > floating-point operation and, if assignment occurs, writes the results
> > back to memory upon completion. Loading the data prior to each
> > operation guarantees that the data does not retain any significance
> > greater than the capacity of its type."
>
> That isn't enough. First, the x86 FPU must be switched to 64 bit mode,
> otherwise you will occasionally get different result due to double
> rounding (about 1 in 2000 chance for a single random operation). The
> load/store will make sure that overflows and underflows are reproduced
> (let x = 1e300. (x * x) / x should be Inf / x = Inf. Without storing and
> reloading the result of x * x, x * x = 1e600, (x * x) / x = 1e300. You
> still run into trouble because underflow in a multiplication and
> division can give different results due to double rounding.
That Microsoft doc is misleading, given that they always (at least since
VS6)
set the FPU to 53-bit precision, which I assume is what you mean by
"64-bit mode." I couldn't find any reference in the thread as to whether
SSE
code generation was invoked (no such option in VS6, but presumably preferred
in later versions).

Relevant Pages