From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 26 Feb 93 15:10:52 GMT From: prism!jm59@gatech.edu (MILLS,JOHN M.) Subject: Re: Ada Embedded Systems Efficiencies Message-ID: <86800@hydra.gatech.EDU> List-Id: In article <1993Feb24.212146.13157@saifr00.cfsat.honeywell.com> wisniews@saifr0 0.cfsat.honeywell.com (Joe Wisniewski) writes: [...] > I >am involved in a very large Ada project where there is currently much concern about whether >or not we are going to 'fit in the box'. As a result as you can probably imagi ne, there >is an increasing amount of attention being paid to addressing "micro-efficienc ies". This >attention takes on various forms: > 1. Optimizing the compiler (back-end developed in-house) > 2. Addressing issues that the compiler hasn't optimized well or can't o ptimize > well > i.e. getting rid of case statements > limiting the number of parameters that are passed > in procedure calls > pushing for the use of package spec data vs. package body data > accessed by procedures and functions for state data usa ge > in-lining during design > etc. > > Note: Very little prototyping was done and as a result effective early > timing studies were not available or used. > >I am concerned that "good design" macro-efficiencies are going to be "un-done" >due to perceived net overall gain of over-implementing micro-efficiencies. I am also completing an embedded Ada project -- three 68030s and comprising: 266 files, 40,000 total lines 17,000 "semicolons" and running from 0.5 MB RAM in each of the three CPU cards (with plenty of margin). This may be a large or a small program in your experience. Parts of it are fast and tightly coupled; parts are fast and well buffered; parts are real lazy. We looked at assembly listing for some of our common data structures (such as Booch-style managed rings for lots of types), and concluded that we would have to work _very_ hard to improve on the [SD-Scicon] compiler's performance, and we would (naturally) have to resort to assembly language -- we couldn't expect to improve at all in Ada. The compiler was making clever choices for register and stack usage, etc., depending on context. The old advice of: "profile first and optimize after" is really the best. Right now you don't know where your problems will be. You may not even have any. We did find some "religious issues" obstructed our code and slowed it down. Classical encapsulation isolating internal procedures by multiple layers of abstraction was costing us _lots_ of execution time. We went to "Pascal style" local variables and simpler instantiation layering, and picked up up "a lot" of speed. (I didn't do this part, so I can't comment on the amount, but we tripled our throughput in critical processes.) Even more serious, the heavy encapsulation had so concealed our code's functionality that it was unportable and not economically maintainable, _even_by_other_ members_of_our_team_. Watch your dogma, but probably you can trust your language. Figure out for yourself if you can trust your compiler, but don't waste time solving problems you may not have. I'm afraid there's no substitute for good judgement, both in the design phase and in your implementation. If you have a poor top-level design and good low-level functions (i.e., the code was well modularized), you may be able to get big functional improvements with very little recoding -- this is a _design_ issue, _not_ a language issue (and probably not a compiler issue, either). This comes under the heading: "I'ld rather be lucky than good." >I believe that it is possible that some of these micro-efficiencies that are >implemented might actually do more harm than good, in the long-run. The time to get the job re-done, and to reconstruct all your design, documentation, test strategies and suites, etc., etc. will eat you alive, too. That kills even more embedded projects than "not fitting in the box." (IMHO) >I think that this might be of interest to most readers, so I would suggest >posting responses to the net. I will summarize all responses at a later date. It's probably better than the 100-yrs' war [C++ vs Ada]. Regards --jmm-- -- John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59 Internet: john.m.mills@gtri.gatech.edu EBENE Chocolat Noir 72% de Cacao - WEISS - 42000 St.Etienne - very fine