Re: GNAT Optimization of Constant Expressions

["Randy Brukardt" <randy@rrsoftware.com>]

"David Smith" <david.smith@gmail.com> wrote in message
news:1179442153.169828.109970@l77g2000hsb.googlegroups.com...
>
> > > I agree for any function call, but in the special case of functions
from
> > > Generic_Elementary_Functions, it is _not_ asking a lot! A decent
compiler
> > > should perform optimizations around these functions as well as around
> > > arithmetic operators.
>
> The purpose in leaving them in was to test this aspect of the
> optimization process.  This is a very common expression to see in
> legacy scientific codes written by novices, and I wanted to know if
> GNAT can handle naive structures as well as Fortran compilers do.  If
> it can't, then many scientists and potential Ada converts will be
> turned off because they'll write a naive bit of code for a benchmark
> and find that Ada is much slower than Fortran without trying to
> understand why.

Fair enough, but this seems to be the wrong question to ask. The question is
whether it is fast enough for the application, not whether it is as fast as
some other language that doesn't have the same requirements. Anything else
is premature optimization. And, in addition, can the code be made fast if it
actually matters. (I have serious doubts about the value of "naive"
numerical code, but I'll leave that rant for some other time...)

> I understand that the FP ops are not associative, but doesn't the gcc -
> O3 imply that the user chooses speed over accuracy?  And especially if
> the user passes -ffast-math the compiler should get the hint.

I don't agree. Ada has fairly strict requirements on accuracy that C and
Fortran don't have. An optimizer shouldn't be providing the *wrong* answer
in order to make code fast; so I doubt that -O3 would have that effect on an
Ada program (where it might for C).. I realize that Ada 95 made those
accuracy requirements optional, but I think that most Ada compilers (which
have Ada 83 roots) make the strict mode their default. And since the strict
mode necessarily encorporates any relaxed mode, it's quite likely that they
never deviate from it. I don't know Gnat well enough to comment on whether
it has a separate relaxed mode.

> > There are optimizations that you can do safely, like common
subexpression
> > evaluation, but there are many fewer of them than you have with integer
> > optimizations. Luckily, most of the code in a program (any program, once
you
> > take address calculations like array indexing into account) is integer
code.
> > It is very important to do a good job on integer expressions, much less
> > valuable of float ones (because of the limited things that you can do).
>
> This may be true, but FP ops are very expensive, so trimming those can
> potentially save more than you might think.    In this example, the
> common expression elimination speeds the code up by a factor of 10,
> roughly.

No, FP isn't very expensive. "Elementary function" library calls that may
execute hundreds of lines of code are expensive! (Keep in mind that Ada's
accuracy rules prevent Ada compilers from using the hardware support for
Sin/Cos/Tan -- it's not accurate enough.) You can write a lot of interesting
FP code (statistics, for instance) without using any elementary functions
other than Sqrt. And the use of constants as arguments to those expensive
routines is pretty silly. (Besides, good Ada practice would be to name your
constants, and when you did that, you got essentially the same code as with
Fortran.)

None of which is to say that common subs shouldn't be handled, but there is
a big difference between hoisting expressions and simply avoiding duplicate
evaluations. The former can make code larger and slower if done
inappropriately. It may simply not be worth doing, if it doesn't help most
programs. Of course, you can always write a program that it does help (like
yours), but one has to allocate ones resources based on the value to all
customers and all programs, not just one.

(And please remember I know nothing at all about Gnat's actual optimization
technology. This might just be a bug in something that is supposed to work.)

                                Randy.