appropriate optimization technology

[Thomas M. Breuel]

David Hough writes:
 > There's been interesting exchanges on the numeric-interestavalidgh.com
 > mailing list about the optimization issues I raised a couple of weeks ago
 > with respect to loops like
 > 
 >       while (tmp == zero) {
 >          a = a+a;
 >          tmp = a+one;
 >          tmp1 = tmp-a;
 >          tmp = tmp1-one;
 >       }
 > 
 > Regardless of what one thinks about language standards, arithmetic standards,
 > or standard mathematical software, it must be alarming that so much effort
 > is going into optimizations that do so little good for performance.
 > [goes on to describe optimizations for parallel machines, vector
 > machines, ...]

I find it alarming that so many people believe that such optimizations do
little for performance.

The restrictions that have been proposed here to make such loops
"work" require that any floating point optimization results in bitwise
equal results to the "unoptimized version" (of course, such loops
don't "work" even with the restrictions in place). I don't know the
full consequences of this restriction, but I suspect they might be
far-reaching.

In particular, on some machines, they may eliminate all register
allocation of floating point variables (since registers may give you
extra precision), they may eliminate many opportunities for CSE,
pulling expressions out of loops, etc. Such proposed restrictions
might have even more far-reaching consequences for multiprocessor or
other modern architectures.

Now, fortunately, short of mandating a particular floating point model
or format, there is little that NCEG can do to try to enforce "bitwise
equal results". At worst, any compiler vendor can simply claim that
they have two different compilers (cc-unopt and cc-opt), which happen
to use different floating point formats.

So, fortunately, this discussion is rather inconsequential for the
standard. Hopefully, some writers of numerical libraries will have
realized that floating point inquiry using loops like the one given
above is unportable and a bad idea (NCEG might consider providing
standard header files to provide such implementation specific
information).

With respect to floating point optimization, I think what NCEG should
do is recommend (intentionally) vaguely that "optimization should not
decrease the accuracy of any floating point computation" and leave it
at that.  Without a more specific model of floating point comptuation,
I think that's all that can be done.

					Thomas.