Re: Efficiency of code generated by Ada compilers

[csampson@inetworld.net (Charles H. Sampson)]

Elias Salom�o Helou Neto <eshneto@gmail.com> wrote:

> ...
> 
> Well, we are definitely drifting away from the original question. So
> much that I am considering to give up reading answers from this
> post...
> 
> Anyway, someone prematurely implied that I may be doing premature
> optimization. The fact is that I do know, from profiling, how
> important is _not_ to range check in my specific application, so I
> will try to give you a "bottom line" of what have been said that
> really matters to me.
> 
> ...

     I think I'm the guy who implied that you're doing premature
optimization, or at least the guy who you think implied that.

     You appear to have a deep knowledge of your application.  I
certainly don't.  Therefore I have to defer to your judgement on the
question.  But I probably did raise the question that you _might be_
prematurely worrying about optimiziing.  What I remember saying is that
almost every time  _I_ make a guess about optimization, I'm wrong.

     A number of people have given you information about optimization of
a number of Ada compilers.  I'll give you an example of the last one I
worked with.  This compiler uses a not uncommon approach to code
generation.  It initially generates pretty mediocre code, in particular
code that contains a lot of unnecessary range checks and even
unnecessary register loads.  Then, if the user wants, it passes that
code through a pretty good optimizer.  You might say that the compiler
has two modes, development and production.

     My last project was a real-time application.  We hit all of our
deadlines, which is all that counts in the real-time world.  (We
achieved this in the crudest way: We beat it about the head and
shoulders with a very fast CPU and gobs of memory.)  Nonetheless, twice
during my time on the project, I compiled the whole application using
the optimizer (but not with range checks, or any checks, explicitly
suppressed).  The generated code improved dramatically.  Checks that the
optimizer could verify weren't needed disappeared.  Code motion did some
pretty things.  And so on.  However, when I ran this much improved
version, I couldn't see any difference between it and the crude version,
including any increase in the amount of time the application was in its
idle state.  In short, whatever improvement there was in execution,
wasn't worth the increase in compilation time.

     That's a pretty standard story, illustrating that you usally need
to analyze before optimizing.  However, as people love to say, YMMV.
(That's twitter-speak for "This might not apply in your case.")

                        Charlie
-- 
All the world's a stage, and most 
of us are desperately unrehearsed.  Sean O'Casey