From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac9fffa36bbbedcb X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Rational Apex Ada Linker Date: 1996/08/30 Message-ID: <3227A558.15FB@gsde.hso.link.com>#1/1 X-Deja-AN: 177672884 references: <32249623.7C09@harris.com> content-type: text/plain; charset=us-ascii organization: Hughes Training Inc. - Houston Operations mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (X11; I; IRIX 5.3 IP19) Date: 1996-08-30T00:00:00+00:00 List-Id: 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!"