lkml.org 
[lkml]   [2004]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Somewhat OT: gcc, x86, -ffast-math, and Linux
On Fri, 26 Mar 2004, Daniel Forrest wrote:

> I've tried Googling for an answer on this, but have come up empty and
> I think it likely that someone here probably knows the answer...
>
> We are testing and breaking in 6 racks of compute nodes, each rack
> containing 30 1U boxes, each box containing 2 x 2.8GHz Xeon CPUs.
> Each rack contains identical hardware (single purchase) with the
> exception that one rack has double the memory per node. The 6 racks
> are located in six different labs across our campus. It is available
> to me only as a "black box" queueing system.
>
> I am running one of our applications that has been compiled using gcc
> with the -ffast-math option. I am finding that the identical program
> using the same input data files is producing different results on
> different machines. However, the differences are all less than the
> precision of a single-precision floating point number. By this I mean
> that if the results (which are written to 15 digits of precision) are
> only compared to 7 digits then the results are the same. Also, most
> of the time the 15 digit values are the same.
>
> My question is this: Why aren't the results always the same? What is
> the -ffast-math option doing? How are the excess bits of precision
> dealt with during context switches? Shouldn't the same binary with
> the same inputs produce the same output on identical hardware?
>
> I have run the same test with the program compiled without -ffast-math
> enabled and the results are always identical.
>
> Any insight would be appreciated.

The gcc `man` page says that -ffast-math allows for ANSI and
IEEE rules to be violated. There is also a statement about
not using it in conjunction with -O options as this will result
in incorrect output.

So you get what you asked for.

The FPU has 80-bits of precision internally. Its state is
always saved and restored across context-switches. There
are no "extra bits of precision" as you state.

The FPU's state is not saved during system-calls so the
kernel is not supposed to use the FPU internally.

Look at <math.h> and the files it includes. Note that the
math library takes and returns type double. If you have
declared your floating-point variables as type float, you
will have serious dynamic rounding errors unless you
closely adhere to the IEEE spec. Even then, it might
be serious. If the IEEE spec gets violated by the
--fast-math, you might have discovered the reason why
you get strange values.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.061 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site