This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Floating point performance issue
On 2011-12-21 05:35:53 +0100, Segher Boessenkool wrote:
> ...And then, of course, I discover the program does not calculate
> f**(2*S) but f**(2*S-1). Which makes my "correct" results not so
> very correct. Ouch.
>
> >It outputs:
> >
> >nearest = 0.36787944637187158792
> >down = 0.36787944526181193261
> >
> >while we have
>
> correct = 0.36787944576993540330
>
> so both rounding modes are about equal.
>
> >Now you can say that this is because x already is rounded from the
> >true value,
>
> ... and this is indeed ...
>
> >the case: taking S=2**25, we get
> >
> >nearest = 0.36787944391225085860
> >down = 0.36787944204965455918
> >
> >with
>
> correct = 0.36787944391235777181
>
> so in that case round towards zero gets twice as many bits
> wrong as round to nearest, just as a naive analysis would show.
and ideally, you should test programs on many inputs, and also prove
error bounds (which will probably be pessimistic, but guaranteed).
Now, what I wanted to say is that in general, leaving the rounding
to nearest and setting FTZ would be much better than changing the
rounding mode globally. Another drawback of changing the rounding
mode globally is that some libraries may not support it; this is
the case of the math library from the glibc on x86_64 (and other
processors for which the same code is used):
http://sourceware.org/bugzilla/show_bug.cgi?id=3976
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)