This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: FWD: FLOATING-POINT CONSISTENCY, -FFLOAT-STORE, AND X86
- To: hjstein at bfr dot co dot il (Harvey J. Stein)
- Subject: Re: FWD: FLOATING-POINT CONSISTENCY, -FFLOAT-STORE, AND X86
- From: Edward Jason Riedy <ejr at CS dot Berkeley dot EDU>
- Date: Mon, 14 Dec 1998 14:56:20 -0800
- cc: egcs at cygnus dot com
Oh well. And Harvey J. Stein writes:
-
- I think Intel's comments about how great it is to use the extra
- precision is just propaganda. I think that it maybe helps *slightly*
- with badly written code.
No.
Read through chapter four at
http://www.netlib.org/cgi-bin/checkout/blast/blast.pl . The current
draft contains examples of good uses for extended precision. (It's
going to change within the next few days, so if the examples disappear,
I still have a copy of the current draft.)
There are times when a few dabs of extended precision yield accurate
results from poorly-conditioned problems. This is not a result of
poorly written code but rather walking the thin line between performance
and accuracy. Sometimes you can get quadratic efficiency gains with no
loss of precision by using extended precision in hardware at the right
times. In other cases, extended precision can yield a fully backwards
stable algorithm no matter what the input (e.g. iterative refinement of
a linear system's solution).
- I'd think the only drawback to using the FPU in double precision mode
- instead of extended precision mode would be for carefully hand
- optimized numerical routines in assembler which can possibly do things
- quicker by utilizing the 64 bit extended precision mode.
A little thought, planning, and lack of -O flags, and you can get huge
benefits from the 80-bit cells. Of course, this is highly non-portable,
but more than a few folks do use the extended precision with gcc in
exactly that fashion. You just don't hear from them often.
I do agree that setting the precision to the standard double by default
is a reasonable thing to do for the majority of the population. I can
cite cases where it'll break code, or rather I can go upstairs, knock on
Dr. Kahan's door, and be pointed at a few.
I'd prefer a solution that keeps the extra precision whenever possible,
but my view is a somewhat compiler-aware numericist's. I'm sure you'll
agree that it doesn't reflect the majority of users (or, alas, the majority
of numericists). Still, there are ways to fix the problem well. Any
twiddle to the control words ought to be considered temporary.
Jason