Re: Efficiency of code generated by Ada compilers

["Elias Salomão Helou Neto" <eshneto@gmail.com>]

On Aug 14, 1:13 pm, csamp...@inetworld.net (Charles H. Sampson) wrote:
> Elias Salomão Helou Neto <eshn...@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.

Dimitry pointed out above that the compiler could suppress the checks
by itself, which would mean my optimization was unnecessary anyway. I
think it was a good point indeed, but I kind of doubt that a compiler
could be smart enough for doing that in my case anyway. Maybe I am
just not smart enough to think of a good optimizing strategy for
compilers :)

And yes, I know how many times guesses about optimization are just
plain and simply 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.")

In my case, things were somewhat different. For example, manually
telling GCC to inline some functions reduced running times in about
15%. Even if I turned GCC's optimizer fully on, it was not able to
automatically inline those functions. That should have been a simple
matter to the optimizer, since I did not use any pointer to that
function or something similar. I guess we are running into different
results here because I am writing numerical software that runs very
tight loops within which I have to address matrices elements in a
_very_ efficient manner.

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

Thank you,
Elias Salomão Helou Neto