Rational Apex Ada Linker

Rational Apex Ada Linker

[Kirk J Horne]

The Ada Rational Apex (2.0.8.D) linker appears to include all
subprograms from imported subsystens into an executable, even if the
subprograms aren't referenced by the Ada process being built. This
causes even small Ada processes to become too large and has become an
obstacle on the SGI where the "GOT overflow" link error occurs. 

(1) Are any other Rational users having the same problem?    
(2) Is there a work around?
(3) Does Rational have a "smart" Ada linker?

Thanks,
Kirk Horne
khorne@rsa.hisd.harris.com

Re: Rational Apex Ada Linker

[Jeff Creem]

In article <32249623.7C09@harris.com>, Kirk J Horne <khorne@harris.com> wrote:

> The Ada Rational Apex (2.0.8.D) linker appears to include all
> subprograms from imported subsystens into an executable, even if the
> subprograms aren't referenced by the Ada process being built. This
> causes even small Ada processes to become too large and has become an
> obstacle on the SGI where the "GOT overflow" link error occurs. 
> 
> (1) Are any other Rational users having the same problem?    
> (2) Is there a work around?
> (3) Does Rational have a "smart" Ada linker?
> 
> Thanks,
> Kirk Horne
> khorne@rsa.hisd.harris.com

First,

Its always best to send a report to:

support@rational.com


first since if people don't report these problems they will not get the
attention they deserve. (Maybe you already did and just have not heard
back. I just want to make sure.)


I have been "working" with rational for 6 months or so on this issue and
the completely abismal code generation of the Apex product. I have
gone through the proper chanels but Rational says they have never heard
anyone complain about he code generation or huge executables except for me!

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.

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.

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.

Or use GNAT. It does not produce code that is quite as tight as the
old SunAda 1.1 (VADSself). But for all I know GNAT is as good as the more recent
VADSself.


Oh, on the brighter side, with the VADS compiler (at least for vxWorks targets)
the linker is very selective about what it brings in and it will even eliminate
procedures from within packages if it determines that they can never be called.

Re: Rational Apex Ada Linker

[Samuel T. Harris]

Jeff Creem wrote:

> I have been "working" with rational for 6 months or so on this issue and
> the completely abismal code generation of the Apex product. I have
> gone through the proper chanels but Rational says they have never heard
> anyone complain about he code generation or huge executables except for me!

We've never complained because Apex has never been our target compiler
either.


> 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).

> 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.

> 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
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.

-- 
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!"

Re: Rational Apex Ada Linker

[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!"

Re: Rational Apex Ada Linker

[Samuel T. Harris]

Kirk J Horne wrote:
> 
> The Ada Rational Apex (2.0.8.D) linker appears to include all
> subprograms from imported subsystens into an executable, even if the
> subprograms aren't referenced by the Ada process being built. This
> causes even small Ada processes to become too large and has become an
> obstacle on the SGI where the "GOT overflow" link error occurs.
> 
> (1) Are any other Rational users having the same problem?
> (2) Is there a work around?
> (3) Does Rational have a "smart" Ada linker?
> 
> Thanks,
> Kirk Horne
> khorne@rsa.hisd.harris.com

Being an old Rational hack and a Apex user since it was in Beta,
I find this surprising. While I could not find supporting evidence
to the claim as it is worded above, I did discover that the issue
is more complicated.

I did some contrived tests to see what is going on.
I defined a package in a view of a subsystem.
Then I defined some procedures in a view of another subsystem.
I import the first view into the second.
Each main procedure (in the second view) simple uses text_io.put_line
to print "hello". One procedure withs the package and one does not.
They do have a slight increase in code size (must be simple package
overhead). 

As I added null procedures to the to the package, I again get
slight increases in the execution size. However, as I add actual
code (which cannot be optimized away) I did NOT get an increase
in size in the procedure which makes no calls, and DID get an
increase in size in the procedure which does make calls.
Note that as I add procedures to the body only of the package
and are not visible outside of the package, the main procedure
making no calls does not change in size.

These increases are not affected by combinations of context switch
values for OPTIMIZATION_OBJECTIVE, OPTIMIZATION_LEVEL, and
PROFILING.

I also get slight increases in size when I add global variables
to the package spec or body, but not when I simply add local
variables to the package procedures (that is, the main procedure
which does not make calls).

Both main procedures increase in size identically as I add code
to the body of the package itself.

So, what we have here is elaboration code. Though I'm not sure
what would be actually done to "elaborate" the spec of a procedure,
not having implemented the code generator for any Ada compiler,
something is being done for each visible procedure. Global package
variables also incur overhead whether limited to the body or not.
Of course, package elaboration code is always included. However,
the binder/linker in Apex does appear to correctly eliminate the
bodies of uncalled procedures. Though I did not specifically
test functions (I can only spend so much time on such things)
I would expect similar results.

BTW, I did these tests with Apex 2.0.8D on SGI equipment under
IRIX 5.3. FYI, Apex using the operating systems linker for the
actual link. This caused some problems in Apex 1.4 on Sun/Solbournes
which we used to use.


-- 
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!"

Re: Rational Apex Ada Linker

[David Emery]

Apparently NOT ALL Apex products use the VADS optimizer.  In particular,
it looks as if the HP/UX version of Apex is not using the best Vads 
code generation technology....

Your mileage may vary, ours certainly has...

				dave
--
<.sig is away on vacation>