This is the mail archive of the
mailing list for the GCC project.
Re: Second Draft "Unsafe fp optimizations" project description.
- To: Gabriel Dos_Reis <gdosreis at sophia dot inria dot fr>
- Subject: Re: Second Draft "Unsafe fp optimizations" project description.
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Mon, 06 Aug 2001 22:18:49 +0200
- CC: gcc at gcc dot gnu dot org
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <3B6D9A51.email@example.com> <firstname.lastname@example.org>
Gabriel Dos_Reis wrote:
> Thanks for reiterating over this.
> | Optimizations that change the meaning of floating point expressions
> It would be more accurate and consistent with latter description to
> say "Transformations" instead of "Optimizations".
Well, the reason I used the word "optimizations" here is that I agree
with Robert's point of view that there is little to gain from these
transformations if they aren't optimizations. So I prefer to keep that
> | Why would someone forego numerical accuracy for speed ? Isn't the fast but
> | wrong answer useless ?
> | Unfortunately, this simple reasoning doesn't cut it in the Real World.
> I think the above description is somehow misleading.
> What about
> In numerical problems, there are roughly two kinds of computations:
> 1) those who need full precision in order to guarantee the results, and
> 2) those which are less sensible to occasional loss of accuracy.
> For the latter category, it is reasaonable to forego the numerical
> accuracy for speed.
Yep, I was in a certain mood when I wrote the above - I'll rewrite it to
something equivalent to your suggestion above. I'll also remove the jab
at "first person shooting game" - it was funny the first time, but it
gets old real fast ...
> | Open issues
> | We should come up with a classification for complex arithmetic too. Just A/B
> | with A and B complex already has a couple of different possible evaluations.
> We should also document cases where the transformations considered in
> this project depend on targets. For example, Power does its
> floating point arithmetics in 64-bit whereas Sparc has two distinct
> categories of floating point arithmetic instructions -- a target may
> choose to use full 64-bits because it is faster (althought I doubt
> that is the case on Sparcs).
Certainly, that's a refinement we have to add later.
Toon Moene - mailto:email@example.com - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)