Re: Rational Apex Ada Linker

[jcreem@mv.mv.com (Jeff Creem)]

In article <3227A558.15FB@gsde.hso.link.com>, "Samuel T. Harris"
<u61783@gsde.hso.link.com> wrote:


> > In comparing code generated by Apex to code generated by GNAT or
> > even Rationals SunAda product, Apex produces bloated code which runs about
> > 1.8 - 3.0 time slower.
> 
> I've run PIWG on GNAT, VADS and Apex 2.0 on our SGI's and they each
> consistently
> run within 10% of each other (taking everything in account). Actual
> performance
> varies within each groups of tests, but the execution speed is
> comparable.
> I'll be running the ACES suite when I get a chance.
> 
> Apex 1.4 was another story, being "dismally" slower. With the inclusion
> of
> VADS code generator technology, Apex has become a viable target
> platform.
> 
> I wonder which version of Apex you (Jeff) compared (you didn't specify).

I am using 2.0.8 (version C i think). I have seen Apex produce some
reasonable code and sometimes it has come close to GNAT or VADS but often
it does not (At any optimization level).

Some thoughts.

1) Rational has incorporated the VADS code generator but no matter what
   you fo you can't get it to generate code above -O4 (the VADS optimizer
   can go to -O9)

   source of info: Rational Tech Support

2) Some of the problems appear in the front end and are not cg problems.
   The places where I really see a big differenence are not in areas like
   tasking, array copy or any higher level constructs but in semi-complicated
   math structures. Looking at the assembly language which is generated,
   Apex is indeed producing more instructions (and slower executing) in
   these cases.


3) I think the front end is shared for Apex on all platforms so I doubt this
   could be the issue but maybe there is something Sun specific here that
   I am now aware of.


4) In any case, Hello world is still orders of magnitude larger than
   the other two compilers. (Not quite as bad as it seems because the
   since differential is much more pronounced on small programs than on large
   ones)


> 
> > But you only pay 16,000 to 20,000 for the tool set. The compiler
> > is really just a bonus. The real reason you want to pay that much is for
> > the troublesome Language sensitive Editor (that automatically "fixes"
> > closing parenthesis (like the ] in LISP and we all know what a powerful
> > bug inducer this is).
> > 
> > Anyhow to make a long story short. I know of know of no fix for the problem.
> 
> For large systems, the Apex context switch OPTIMIZATION_OBJECTIVE has a
> lot
> to do with inlining. When set for TIME, many procedure calls will be
> inlined,
> eventhough no pragma is used. This can create large executables.
> Resetting
> this to SPACE will negate automatic inlining. I suggest you (Jeff and
> Kirk
> from a previous post) try this and see if this helps.


I've tried these (and more) And I have been working with tech support on 
my issues. They have not been able to get fix any of these speed issues
with any combination of switches.


 
> 
> > Try going to your management and telling them that even though you've
> > already spent multiple thousands on the Apex environment and compiler that
> > you need a few more thousand to purchase VADSself from rational so that
> > you can get reasonable executable sizes.
> 
> Our main concern with a target compiler is speed. At the moment, we
> extensively
> use the Apex RCI to generate target loads using the VADS compiler. Who
> knows

Thats supposed to be one of the big benefits. I've never felt that the interface
to the tools was all that much of a learning curve. (Granted there is still
a curve.) The question is by the time you do (or pay Rational to do)  the
RCI customizations, download the patch needed to get it to work. Try it for
a while. Download the second patch .... and so on.. Have you really saved
anything over learning the native tool set. 
On a large enough project I think the answer is probably yes. On a ~10 person
 ~80,000 - ~100,000 LOC project I'm not so sure.


> what we'll be using next year. But we'll still be using the Apex for
> development no matter what target compiler we plug into it.
> 
> -- 


I'm not totally anti Apex either. I think it has a lot to offer. (Primarily
the subsystem/view methodology and some of its CM stuff). I think the RCI
system is not a bad idea either.

Its just a lot to pay for a tool when that is all you get from it. A little
more work on the front-end/code generator and it would not be a bad product.


> Samuel T. Harris, Senior Engineer
> Hughes Training, Inc. - Houston Operations
> 2224 Bay Area Blvd. Houston, TX 77058-2099
> "If you can make it, We can fake it!"