Re: Ada Compilers

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Greg Bek" <gab@rational.com> wrote in message
news:afb6d339.0205211331.30124c52@posting.google.com...
> As a compiler vendor I'd just like to echo MDC's comments.
> Don't just use standard benchmarks, use your application or
> portions of it for testing performance.  Benchmarks like
> the PIWG's are not sufficiently sophisticated to properly
> perform timing of null loops etc.
>
Thanks for the echo. Call me "Marin" - everyone else does. :-)

Artificial benchmarks may tell you something but it is *much* better to use
typical segments of your own apps to try to evaluate performance. Some apps
do lots of data motion, others do lots of comparisons, others do specific
kinds of math, etc. Any given compiler might, for example, generate *really*
tight code for linear equations, but generate slow code for data motion.
Vendors can't do everything, so they spend time optimizing particular
aspects of their products & you'll see as a result that perfectly fine
compilers will have considerable variance in what they come up with for
different applications.


> Ada compilers have many advantages over languages like C/C++
> in that the compiler has greater visibility into the rest of
> a user program.  An Ada compiler can automatically inline
> code across multiple levels of subprogram call, C/C++ have
> difficulty doing this as any called subprogram is usually
> compiled into a different object module.  This means that
> C/C++ must perform a call/return where the Ada code may
> have the call/return (and associated prolog/epilog, stack
> check) eliminated.
>
And of course, as every year goes by in the life of a compiler, more and
more optimizations are found. Every day, in every way, they're getting
better and better. :-) The Ada vendors certainly do have advantages over
some other more popular languages because of how well the language was
designed and the information content of the language being so high.


>
> Modern compilers are very good at producing optimized code
> under most circumstances.
>
We should remember to keep this in perspective too. When I was building
avionics systems, extremely aggressive optimization and really compact, fast
code were life-and-death issues for the projects. I use Ada now mostly for
PC-ish applications and performance is not nearly so critical. What matters
then are other sorts of creature comforts. (development tools, libraries,
etc.) The caveat being that when shopping for a compiler, you need to ask
about what is important for the intended project and not necessarily buy an
avionics-quality compiler just because you are obsessed with speed.

Of course, if someone can give me *everything* for *nothing* I'd be really
thrilled. But I won't hold my breath. :-)


> However there are some subtle issues with Ada that can
> prevent getting the best code possible.  The best example
> of this is using controlled objects within your program.
> Controlled types require the compiler to generate invisible
> code that makes sure any objects are properly finalized when
> a scope is exited.
>
If high performance is an issue for your apps, you need to *really*
understand the language or you can generate inefficient code and be
wondering why. You often have to experiment with alternate ways of
accomplishing the same thing to find the one that fools the compiler into
generating the code you want. I recall once dealing with initialization of
some records where expressing it one way caused the compiler to go off
making a bunch of subroutine calls, but doing it another way we got a single
move of a constant in memory. Know the language and experiment!


>
> As always your milage will vary.
>

Absolutely. And don't besmirch compiler X because it doesn't optimize your
code as nicely as compiler Y. It may optimize someone else's code better
and/or there is a good chance you don't know what you're talking about. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com