Re: Effects of newly introduced -mpcX 80387 precision flag

[Paul Brook]

> > m68k does too, just nobody uses it any more or the ones they use don't
> > have the co-processor or have a different FP instructions now.  In
> > fact this where the problem started, i387 just continued in the same
> > fashion.
>
> Huh? m68k still uses extended precisions and will continue to do so, it's
> ColdFire that doesn't have it anymore.

IIUC excess precision is only a problem on earler m68k implementations. The 
68040 adds instructions that perform correct rounding (fdadd.x etc.), so does 
not suffer from the excess precision problems.

Paul

Re: Effects of newly introduced -mpcX 80387 precision flag

[Roman Zippel]

Hi,

On Fri, 4 May 2007, Andrew Pinski wrote:

> On 5/4/07, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> > Perhaps it should be noted that these libraries are specific to x86
> > processors, since other processors don't have extended precision.
> 
> m68k does too, just nobody uses it any more or the ones they use don't
> have the co-processor or have a different FP instructions now.  In
> fact this where the problem started, i387 just continued in the same
> fashion.

Huh? m68k still uses extended precisions and will continue to do so, it's 
ColdFire that doesn't have it anymore.

bye, Roman

Re: Effects of newly introduced -mpcX 80387 precision flag

[Andrew Pinski]

On 5/4/07, Vincent Lefevre <[EMAIL PROTECTED]> wrote:

Perhaps it should be noted that these libraries are specific to x86
processors, since other processors don't have extended precision.


m68k does too, just nobody uses it any more or the ones they use don't
have the co-processor or have a different FP instructions now.  In
fact this where the problem started, i387 just continued in the same
fashion.

-- Pinski

Re: Effects of newly introduced -mpcX 80387 precision flag

[Vincent Lefevre]

> +Setting the rounding of floating-point operations to less than the default
> +80 bits can speed some programs by 2% or more.  Note that some mathematical
> +libraries assume that extended precision (80 bit) floating-point operations
> +are enabled by default; routines in such libraries could suffer significant
> +loss of accuracy, typically through so-called "catastrophic cancellation",
> +when this option is used to set the precision to less than extended 
> precision. 

Perhaps it should be noted that these libraries are specific to x86
processors, since other processors don't have extended precision.

Also, some libraries (e.g. libxslt) assume double precision to be the
default and can return incorrect results in extended precision.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Effects of newly introduced -mpcX 80387 precision flag

[Uros Bizjak]

Bradley Lucier wrote:



What about "significant loss of accuracy" as these options probably 
won't cause a nuclear reactor meltdown ;)


Well, I did some googling, and the technical term I was thinking of 
was "catastrophic cancellation".  So how about


Note that some mathematical routines in such libraries could suffer 
significant loss of accuracy, typically through so-called 
"catastrophic cancellation", when this option is used to set the 
precision to less than extended precision.


I think this is OK. So if nobody objects, this patch is OK for mainline.


I'm sorry, but I don't have checkin privileges.


I have committed following patch attached patch in your name:

2007-05-04  Bradley Lucier  <[EMAIL PROTECTED]>

   * doc/invoke.texi (i386 and x86-64 Options) [-mpc32, -mpc64, 
-mpc80]:

   Add the note about a significant loss of accuracy of some
   mathematical routines when these options are used.

Patch was tested by building the documentation.

Uros.


Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 124412)
+++ doc/invoke.texi	(working copy)
@@ -10129,13 +10129,22 @@
 @opindex mpc80
 
 Set 80387 floating-point precision to 32, 64 or 80 bits.  When @option{-mpc32}
-is specified, the significand of floating-point operations is rounded to 24
-bits (single precision), @option{-mpc64} rounds the significand of
-floating-point operations to 53 bits (double precision) and @option{-mpc80}
-rounds the significand of floating-point operations to 64 bits (extended
-double precision).  Note that a change of default precision control may
-affect the results returned by some of the mathematical functions.
+is specified, the significands of results of floating-point operations are
+rounded to 24 bits (single precision); @option{-mpc64} rounds the the
+significands of results of floating-point operations to 53 bits (double
+precision) and @option{-mpc80} rounds the significands of results of
+floating-point operations to 64 bits (extended double precision), which is
+the default.  When this option is used, floating-point operations in higher
+precisions are not available to the programmer without setting the FPU
+control word explicitly.
 
+Setting the rounding of floating-point operations to less than the default
+80 bits can speed some programs by 2% or more.  Note that some mathematical
+libraries assume that extended precision (80 bit) floating-point operations
+are enabled by default; routines in such libraries could suffer significant
+loss of accuracy, typically through so-called "catastrophic cancellation",
+when this option is used to set the precision to less than extended precision. 
+
 @item -mstackrealign
 @opindex mstackrealign
 Realign the stack at entry.  On the Intel x86, the

Re: Effects of newly introduced -mpcX 80387 precision flag

[Bradley Lucier]

On May 3, 2007, at 3:29 PM, Uros Bizjak wrote:



Bradley Lucier wrote:

What about "significant loss of accuracy" as these options  
probably won't cause a nuclear reactor meltdown ;)


Well, I did some googling, and the technical term I was thinking  
of was "catastrophic cancellation".  So how about


Note that some mathematical routines in such libraries could  
suffer significant loss of accuracy, typically through so-called  
"catastrophic cancellation", when this option is used to set the  
precision to less than extended precision.


I think this is OK. So if nobody objects, this patch is OK for  
mainline.


I'm sorry, but I don't have checkin privileges.

Brad

Re: Effects of newly introduced -mpcX 80387 precision flag

[Uros Bizjak]

Bradley Lucier wrote:

What about "significant loss of accuracy" as these options probably 
won't cause a nuclear reactor meltdown ;)


Well, I did some googling, and the technical term I was thinking of 
was "catastrophic cancellation".  So how about


Note that some mathematical routines in such libraries could suffer 
significant loss of accuracy, typically through so-called 
"catastrophic cancellation", when this option is used to set the 
precision to less than extended precision.


I think this is OK. So if nobody objects, this patch is OK for mainline.

Thanks,
Uros.

Re: Effects of newly introduced -mpcX 80387 precision flag

[Bradley Lucier]

On May 3, 2007, at 2:45 PM, Uros Bizjak wrote:



Bradley Lucier wrote:


On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:

Could you please post a patch with suggested wording about this  
option (I was trying to write something similar to the warning  
that icc has in its documentation about precision settings).


How about this?  It perhaps reflects my own biases, but the term  
"catastrophic loss of accuracy" is sometimes used in the technical  
sense that I mean here.  For the performance figures, I used the  
figures you gave in your e-mail but add "or more" to be on the  
safe side.
What about "significant loss of accuracy" as these options probably  
won't cause a nuclear reactor meltdown ;)


Well, I did some googling, and the technical term I was thinking of  
was "catastrophic cancellation".  So how about


Note that some mathematical routines in such libraries could suffer  
significant loss of accuracy, typically through so-called  
"catastrophic cancellation", when this option is used to set the  
precision to less than extended precision.


Brad

Re: Effects of newly introduced -mpcX 80387 precision flag

[Uros Bizjak]

Bradley Lucier wrote:


On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:

Could you please post a patch with suggested wording about this 
option (I was trying to write something similar to the warning that 
icc has in its documentation about precision settings).


How about this?  It perhaps reflects my own biases, but the term 
"catastrophic loss of accuracy" is sometimes used in the technical 
sense that I mean here.  For the performance figures, I used the 
figures you gave in your e-mail but add "or more" to be on the safe side.
What about "significant loss of accuracy" as these options probably 
won't cause a nuclear reactor meltdown ;)


Uros.

Re: Effects of newly introduced -mpcX 80387 precision flag

[Bradley Lucier]

On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:

Could you please post a patch with suggested wording about this  
option (I was trying to write something similar to the warning that  
icc has in its documentation about precision settings).


How about this?  It perhaps reflects my own biases, but the term  
"catastrophic loss of accuracy" is sometimes used in the technical  
sense that I mean here.  For the performance figures, I used the  
figures you gave in your e-mail but add "or more" to be on the safe  
side.


Brad

[descartes:~/Desktop] lucier% rcsdiff -u invoke.texi
===
RCS file: RCS/invoke.texi,v
retrieving revision 1.1
diff -u -r1.1 invoke.texi
--- invoke.texi 2007/05/03 15:43:01 1.1
+++ invoke.texi 2007/05/03 17:15:24
@@ -10139,12 +10139,21 @@
@opindex mpc80
Set 80387 floating-point precision to 32, 64 or 80 bits.  When @option 
{-mpc32}
-is specified, the significand of floating-point operations is  
rounded to 24

-bits (single precision), @option{-mpc64} rounds the significand of
-floating-point operations to 53 bits (double precision) and @option{- 
mpc80}
-rounds the significand of floating-point operations to 64 bits  
(extended

-double precision).  Note that a change of default precision control may
-affect the results returned by some of the mathematical functions.
+is specified, the significands of results of floating-point  
operations are

+rounded to 24 bits (single precision); @option{-mpc64} rounds the the
+significands of results of floating-point operations to 53 bits (double
+precision) and @option{-mpc80} rounds the significands of results of
+floating-point operations to 64 bits (extended double precision),  
which is
+the default.  When this option is used, floating-point operations in  
higher

+precisions are not available to the programmer without setting the FPU
+control word explicitly.
+
+Setting the rounding of floating-point operations to less than the  
default
+80 bits can speed some programs by 2% or more.  Note that some  
mathematical
+libraries assume that extended precision (80 bit) floating-point  
operations
+are enabled by default; routines in such libraries could suffer  
catastrophic
+loss of accuracy when this option is used to set the precision to  
less than

+extended precision.
@item -mstackrealign
@opindex mstackrealign

Re: Effects of newly introduced -mpcX 80387 precision flag

[Uros Bizjak]

Bradley Lucier wrote:

I just (re-)discovered these tables giving maximum known errors in 
some libm functions when extended precision is enabled:


http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html

and when the precision of the mantissa is set to 53 bits (double 
precision):


http://people.inf.ethz.ch/gonnet/FPAccuracy/linux64/summary.html

This is from 2002, and indeed, some of the errors in double-precision 
results are hundreds or thousands of times bigger when the precision 
is set to 53 bits.


I think the warning in the documentation is very mild considering the 
possible effects.


Perhaps the manual should also mention that sometimes this option 
brings a 2% improvement in the speed of FP-intensive code along with 
massive increases in the error of some libm functions, and then people 
could decide if they want to use it.  (I'm not opposed to a switch 
like this, my favorite development environment sets the precision to 
53 bits globally just as this switch does, but I think the 
documentation should be more clear about the trade-offs.)


Could you please post a patch with suggested wording about this option 
(I was trying to write something similar to the warning that icc has in 
its documentation about precision settings).


Thanks,
Uros.

Re: Effects of newly introduced -mpcX 80387 precision flag

[Tim Prince]

[EMAIL PROTECTED] wrote:


On Apr 29, 2007, at 1:01 PM, Tim Prince wrote:





It makes no sense at all for sqrt() to break down with change in 
precision mode.


If you do an extended-precision (80-bit) sqrt and then round the result 
again to a double (64-bit) then those two roundings will increase the 
error, sometimes to > 1/2 ulp.


To give current results on a machine I have access to, I ran the tests 
there on


vendor_id   : AuthenticAMD
cpu family  : 15
model   : 33
model name  : Dual Core AMD Opteron(tm) Processor 875

using

euler-59% gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/pkgs/gcc-4.1.2
Thread model: posix
gcc version 4.1.2

on an up-to-date RHEL 4.0 server (so whatever libm is offered there), 
and, indeed, the only differences that it found were in 1/x, sqrt(x), 
and Pi*x because of double rounding.  In other words, the code that went 
through libm gave identical answers whether running on sse, x87 
(extended precision), or x87 (double precision).


I don't know whether there are still math libraries for which Gonnet's 
2002 results prevail.


Double rounding ought to be avoided by -mfpmath=sse and permitting 
builtin_sqrt to do its thing, or by setting 53-bit precision.  The 
latter disables long double.  The original URL showed total failure of 
sqrt(); double rounding only brings error of .5 ULP, as usually assessed.
I don't think the 64-/53-bit double rounding of sqrt can be detected, 
but of course such double rounding of * can be measured.  With Pi, you 
have various possibilities, according to precision of the Pi value 
(including the possibility of the one supplied by the x87 instruction) 
as well as the 2 choices of arithmetic precision mode.

Re: Effects of newly introduced -mpcX 80387 precision flag

[Bradley Lucier]

On Apr 29, 2007, at 1:01 PM, Tim Prince wrote:


[EMAIL PROTECTED] wrote:

I just (re-)discovered these tables giving maximum known errors in  
some libm functions when extended precision is enabled:

http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html
and when the precision of the mantissa is set to 53 bits (double  
precision):

http://people.inf.ethz.ch/gonnet/FPAccuracy/linux64/summary.html
This is from 2002, and indeed, some of the errors in double- 
precision results are hundreds or thousands of times bigger when  
the precision is set to 53 bits.
This isn't very helpful.  I can't find an indication of whose libm  
is being tested, it appears to be an unspecified non-standard  
version of gcc, and a lot of digging would be needed to find out  
what the tests are.


The C code for the tests is in a subdirectory of:

http://people.inf.ethz.ch/gonnet/FPAccuracy/

There is also a file "all.tar.Z" there, and a few html files with  
commentary.


It makes no sense at all for sqrt() to break down with change in  
precision mode.


If you do an extended-precision (80-bit) sqrt and then round the  
result again to a double (64-bit) then those two roundings will  
increase the error, sometimes to > 1/2 ulp.


To give current results on a machine I have access to, I ran the  
tests there on


vendor_id   : AuthenticAMD
cpu family  : 15
model   : 33
model name  : Dual Core AMD Opteron(tm) Processor 875

using

euler-59% gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/pkgs/gcc-4.1.2
Thread model: posix
gcc version 4.1.2

on an up-to-date RHEL 4.0 server (so whatever libm is offered there),  
and, indeed, the only differences that it found were in 1/x, sqrt(x),  
and Pi*x because of double rounding.  In other words, the code that  
went through libm gave identical answers whether running on sse, x87  
(extended precision), or x87 (double precision).


I don't know whether there are still math libraries for which  
Gonnet's 2002 results prevail.


Brad

The only change I made to the code was

euler-63% rcsdiff header.h
===
RCS file: RCS/header.h,v
retrieving revision 1.1
diff -r1.1 header.h
66c66,68
< double scalb( double x, double n );
---
> /* double scalb( double x, double n ); */
> #include 
> #include 

and the scripts I used to run the code were

euler-60% cat generate-results
#! /bin/tcsh
set files = `ls *.c | sed 's/\.c//'`
foreach file ( $files )
  gcc -O3 -mfpmath=sse -o $file $file.c -lm
  ./$file >! $file.-mfpmath=sse
  gcc -O3 -mfpmath=387 -o $file $file.c -lm
  ./$file >! $file.-mfpmath=387
  gcc -O3 -mfpmath=387 -DFORCE_FPU_DOUBLE -o $file $file.c -lm
  ./$file >! $file.-mfpmath=387-DFORCE_FPU_DOUBLE
  rm $file
end
euler-61% cat compare
#! /bin/tcsh
set files = `ls *.c | sed 's/\.c//'`
foreach file ( $files )
echo comparing $file.-mfpmath=387 $file.-mfpmath=387- 
DFORCE_FPU_DOUBLE

diff $file.-mfpmath=387 $file.-mfpmath=387-DFORCE_FPU_DOUBLE
echo comparing $file.-mfpmath=387 $file.-mfpmath=sse
diff $file.-mfpmath=387 $file.-mfpmath=sse
end

Re: Effects of newly introduced -mpcX 80387 precision flag

[Tim Prince]

[EMAIL PROTECTED] wrote:



I just (re-)discovered these tables giving maximum known errors in some 
libm functions when extended precision is enabled:


http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html

and when the precision of the mantissa is set to 53 bits (double 
precision):


http://people.inf.ethz.ch/gonnet/FPAccuracy/linux64/summary.html

This is from 2002, and indeed, some of the errors in double-precision 
results are hundreds or thousands of times bigger when the precision is 
set to 53 bits.


This isn't very helpful.  I can't find an indication of whose libm is 
being tested, it appears to be an unspecified non-standard version of 
gcc, and a lot of digging would be needed to find out what the tests 
are.  It makes no sense at all for sqrt() to break down with change in 
precision mode.
Extended precision typically gives a significant improvement in accuracy 
of complex math functions, as shown in the Celefunt suite from TOMS.
The functions shown, if properly coded for SSE2, should be capable of 
giving good results, independent of x87 precision mode. I understand 
there is continuing academic research.
Arguments have been going on for some time on whether to accept 
approximate SSE2 math libraries.  I personally would not like to see new 
libraries without some requirement for readable C source and testing.
I agree that it would be bad to set 53-bit mode blindly for a library 
which expects 64-bit mode, but it seems a serious weakness if such a 
library doesn't take care of precision mode itself.
The whole precision mode issue seems somewhat moot, now that years have 
passed since the last CPUs were made which do not support SSE2, or the 
equivalent in other CPU families.

Re: Effects of newly introduced -mpcX 80387 precision flag

[Bradley Lucier]

Richard Henderson wrote:


On Tue, Apr 03, 2007 at 10:56:42AM +0200, Uros Bizjak wrote:
> ...  Note that a change of default precision control may
> affect the results returned by some of the mathematical functions.
>
> to the documentation to warn users about this fact.

Eh.  It can seriously break some libm implementations that
require longer precision.  It's one of the reasons I'm not
really in favour of global switches like this.


I just (re-)discovered these tables giving maximum known errors in  
some libm functions when extended precision is enabled:


http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html

and when the precision of the mantissa is set to 53 bits (double  
precision):


http://people.inf.ethz.ch/gonnet/FPAccuracy/linux64/summary.html

This is from 2002, and indeed, some of the errors in double-precision  
results are hundreds or thousands of times bigger when the precision  
is set to 53 bits.


I think the warning in the documentation is very mild considering the  
possible effects.


Perhaps the manual should also mention that sometimes this option  
brings a 2% improvement in the speed of FP-intensive code along with  
massive increases in the error of some libm functions, and then  
people could decide if they want to use it.  (I'm not opposed to a  
switch like this, my favorite development environment sets the  
precision to 53 bits globally just as this switch does, but I think  
the documentation should be more clear about the trade-offs.)


Brad

Re: Effects of newly introduced -mpcX 80387 precision flag

[Richard Henderson]

On Tue, Apr 03, 2007 at 10:56:42AM +0200, Uros Bizjak wrote:
> ...  Note that a change of default precision control may
> affect the results returned by some of the mathematical functions.
> 
> to the documentation to warn users about this fact.

Eh.  It can seriously break some libm implementations that
require longer precision.  It's one of the reasons I'm not
really in favour of global switches like this.


r~

Re: Effects of newly introduced -mpcX 80387 precision flag

[Uros Bizjak]

On 4/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote:


> It should be noted, that rendered picture in -mpc32 case developed a
> strange halo around rendered object (nice special effect ;), and this
> is clearly the effect of too low FP precision. -mpc64 and -mpc80
> rendered pictures were equal, as far as my vision in concerned (well,
> not quite a scientific approach).
>
> It should be noted, that ifort defaults to -pc64 and this brings some
> 2% better runtimes on FP intensive code.

Is ifort able to provide extended precision arithmetic in that case?  I think
the documentation should mention that 'long double' will no longer work
as expected if you pass -mpc64, likewise for 'double' and -mpc32.


I have added:

...  Note that a change of default precision control may
affect the results returned by some of the mathematical functions.

to the documentation to warn users about this fact.

Uros.

Re: Effects of newly introduced -mpcX 80387 precision flag

[Richard Guenther]

On 4/3/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:

Hello!

Here are some effects of newly introduced -mpcX flag on a povray-3.6.1
(as kind of representative FP-heavy application to measure FP
performance).

The code was compiled using:

-O3 -march=native -funroll-all-loops -ffast-math -D__NO_MATH_INLINES
-malign-double -minline-all-stringops

(32bit code) and final binary was linked using -mpc32, -mpc64 or -mpc80.

The testfile was abyss.pov in default resolution (320 x 240) and the
timings were performed on 'Intel(R) Xeon(TM) CPU 3.60GHz'. Following
are averages of 5 runs:

-mpc80: average runtime 13.273s  (baseline)
-mpc64: average runtime 12.977s  (2.2 % faster than baseline)
-mpc32: average runtime 12.160s  (9.2 % faster than baseline)

It should be noted, that rendered picture in -mpc32 case developed a
strange halo around rendered object (nice special effect ;), and this
is clearly the effect of too low FP precision. -mpc64 and -mpc80
rendered pictures were equal, as far as my vision in concerned (well,
not quite a scientific approach).

It should be noted, that ifort defaults to -pc64 and this brings some
2% better runtimes on FP intensive code.


Is ifort able to provide extended precision arithmetic in that case?  I think
the documentation should mention that 'long double' will no longer work
as expected if you pass -mpc64, likewise for 'double' and -mpc32.

Richard.