Re: Ada Embedded Systems Efficiencies

[prism!jm59@gatech.edu (MILLS,JOHN M.)]

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