Re: Why do floating point operations differ between -m64 -O0/-O1 and -m32 -O0?

[Tim Prince <n8tm at aol dot com>]

On 11/24/2010 1:26 AM, Nikos Chantziaras wrote:
> On 11/23/2010 04:23 PM, Vincent Lefevre wrote:
> > On 2010-11-23 08:25:24 +0200, Nikos Chantziaras wrote:
> > > I have a problem figuring out the precision of floating point 
> > > operations.
> > > Basically, DBL_EPSILON seems to give a wrong value.
> > >  [...]
> > >        double epsilon = 1.0;
> > >        while (1.0 + (epsilon / 2.0)>  1.0) {
> > >            epsilon /= 2.0;
> > >        }
> > >        printf("epsilon = %e\n", epsilon);
> > >        printf("DBL_EPSILON: %e\n", DBL_EPSILON);
> > > [...]
> > > The values don't match and DBL_EPSILON gives a much bigger value 
> > > then the
> > > detected one.  Why is that?  It would seem that compiling on 32bit 
> > > with -O0
> > > yields higher precision.  Is this a result of the FPU being used (or 
> > > not
> > > used)?
> >
> > The extended precision is provided by the processor in 32-bit mode
> > (FPU instead of SSE).
>
> Is the FPU hardware still available in x86-64 CPUs (so -mfpmath=387 
> would make use of it) or is it emulated?  On a similar note, is doing 
> floating point computations using SSE faster when compared to the 387?
It depends.  For Intel CPUs, there is no performance gain for single 
precision scalar operations, other than divide and sqrt, where  SSE 
performance could be matched by the (impractical) setting of 24-bit 387 
precision.  Current CPUs (and compilers) support vectorization 
performance gain over a wider variety of situations than early SSE CPUs.
> It's not that I don't want the excess precision (looks like a Good 
> Thing to me; less rounding errors).  It's that I'm not sure if I can 
> count on it being there.  Would the above routine be a good enough 
> check to see whether excess precision is there?
The consistently reliable way to use x87 80-bit precision is with long 
double data types.  This precludes many important optimizations.


--
Tim Prince