Re: Somewhat OT: gcc, x86, ffastmath, and Linux
From: Richard B. Johnson
Date: Fri Mar 26 2004  16:30:20 EST
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 ffastmath 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 singleprecision 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 ffastmath 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 ffastmath
> enabled and the results are always identical.
>
> Any insight would be appreciated.
The gcc `man` page says that ffastmath 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 80bits of precision internally. Its state is
always saved and restored across contextswitches. There
are no "extra bits of precision" as you state.
The FPU's state is not saved during systemcalls 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 floatingpoint 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
fastmath, 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 linuxkernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomoinfo.html
Please read the FAQ at http://www.tux.org/lkml/