> > 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 d
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 th
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 diff
> +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 suf
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 su
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
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
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 pre
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 refle
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, bu
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:
[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 incre
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 man
[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):
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 bre
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 implementation
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,
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_
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
(32b
19 matches
Mail list logo
