* Rational Apex Ada Linker @ 1996-08-28 0:00 Kirk J Horne 1996-08-29 0:00 ` Jeff Creem ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Kirk J Horne @ 1996-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational Apex Ada Linker 1996-08-28 0:00 Rational Apex Ada Linker Kirk J Horne @ 1996-08-29 0:00 ` Jeff Creem 1996-08-30 0:00 ` Samuel T. Harris 1996-08-30 0:00 ` Samuel T. Harris 1996-09-05 0:00 ` David Emery 2 siblings, 1 reply; 6+ messages in thread From: Jeff Creem @ 1996-08-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational Apex Ada Linker 1996-08-29 0:00 ` Jeff Creem @ 1996-08-30 0:00 ` Samuel T. Harris 1996-09-03 0:00 ` Jeff Creem 0 siblings, 1 reply; 6+ messages in thread From: Samuel T. Harris @ 1996-08-30 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational Apex Ada Linker 1996-08-30 0:00 ` Samuel T. Harris @ 1996-09-03 0:00 ` Jeff Creem 0 siblings, 0 replies; 6+ messages in thread From: Jeff Creem @ 1996-09-03 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational Apex Ada Linker 1996-08-28 0:00 Rational Apex Ada Linker Kirk J Horne 1996-08-29 0:00 ` Jeff Creem @ 1996-08-30 0:00 ` Samuel T. Harris 1996-09-05 0:00 ` David Emery 2 siblings, 0 replies; 6+ messages in thread From: Samuel T. Harris @ 1996-08-30 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Rational Apex Ada Linker 1996-08-28 0:00 Rational Apex Ada Linker Kirk J Horne 1996-08-29 0:00 ` Jeff Creem 1996-08-30 0:00 ` Samuel T. Harris @ 1996-09-05 0:00 ` David Emery 2 siblings, 0 replies; 6+ messages in thread From: David Emery @ 1996-09-05 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1996-09-05 0:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-08-28 0:00 Rational Apex Ada Linker Kirk J Horne 1996-08-29 0:00 ` Jeff Creem 1996-08-30 0:00 ` Samuel T. Harris 1996-09-03 0:00 ` Jeff Creem 1996-08-30 0:00 ` Samuel T. Harris 1996-09-05 0:00 ` David Emery
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox