Thanks for the Ada Bindings Help. Next Issue: Compilers

Thanks for the Ada Bindings Help. Next Issue: Compilers

[Eric Schallenmueller]

To those of you who have responded to my postings (Dick, Joe, Dave, Tim, 
others), thank you very much.  I will check these out.  I have the STARS tapes 
and will see what I can get from them.

(Barry:  haven't been able to reach you on the net or at your phone.  Call me
 (303) 971-7936)

Some of you have been asking about the Ada climate here.  Well, it's in a 
precarious position due to a rough time we're having with one of our few
Ada programs.  There appears to be an unacceptable delay due to the compiler.
The compile delays may be due to poor structuring of Ada code or from a poor
compiler or both.  Here's the system:

Development is on a Rational.  For compiles, the system is sent to a DEC box
(via wire) and the modules are then configured in the proper libraries.
This takes about eight hours and is done automatically, I think.  
Then the compile begins under VMS 5.3 and ACS 2.1 (the Ada compiler).
The compile takes 20 hours for 2100 modules.  In talking to the software lead,
he said the whole system was thought to be 1/2 Million LOC, but now estimates
it at 250k LOC.  

Is this awful response for the compile time or is it typical for an Ada program
of this size?  How much should structuring of Ada code affect the compile time?

The work I'm doing personally is not related to the program having trouble and
can't really be compared.  I am using the ACS system and having no troubles
at all with response time, but then I'm not building a 250K LOC system -- yet.
I'm asking for this information because I don't want to end up in the same 
situation myself.  If I get some good information, I will relay it back to the
guys on the program.  I'm sure they've tried their best to get all the help
from the vendor they can.  I just thought I'd see what the net has to say about
this kind of experience.

It would be really nice if some of you folks from AFATDS or CCPDS-R or WIS
could post some notes.  You've got lots of papers out there, but hard numbers
seem difficult to find.   Give Ada a hand, eh? 

Thanks again,

Eric
(303) 971-7936

Re: Thanks for the Ada Bindings Help. Next Issue: Compilers

[arny.b.engelson]

In article <1725@dinl.mmc.UUCP>, schallen@dinl.uucp (Eric Schallenmueller) writes:
> Some of you have been asking about the Ada climate here.  Well, it's in a 
> precarious position due to a rough time we're having with one of our few
> Ada programs.  There appears to be an unacceptable delay due to the compiler.
> The compile delays may be due to poor structuring of Ada code or from a poor
> compiler or both.  Here's the system:
> 
> Development is on a Rational.  For compiles, the system is sent to a DEC box
> (via wire) and the modules are then configured in the proper libraries.
> This takes about eight hours and is done automatically, I think.  
> Then the compile begins under VMS 5.3 and ACS 2.1 (the Ada compiler).
> The compile takes 20 hours for 2100 modules.  In talking to the software lead,
> he said the whole system was thought to be 1/2 Million LOC, but now estimates
> it at 250k LOC.  
> 
> Is this awful response for the compile time or is it typical for an Ada program
> of this size?  How much should structuring of Ada code affect the compile time?
> 
> Eric
> (303) 971-7936

Well, which is it?  500K or 250K?  How do you count lines of code?
Are you including link time in this 20 hours?  Are you doing "ACS COMPILE"
or "Ada"?  And, WHAT SIZE VAX ARE YOU USING?

In any case, this seems slow.  Several things could be causing this.

Got a big enough VAX (and one not being overloaded with other tasks)?
(you want speed, get a bigger CPU)

Got enough main memory?  (a problem if other people are using the system)

Is your working set large enough?  (at least 4000 pages, or suffer death by
page faulting)

Using nested sublibraries? (don't)

Your average module size seems about 100-200 LOC.  If many of them are real
small you pay for compiler startup each time.  If some of them are much
larger and your working set isn't big enough, you get hit with lots of
page faulting.  If you are using lots of generics you get slowed down.

These are just some ideas, I'm sure there are more, and not all of the
above will apply to you.

  -- Arny Engelson   att!wayback!arny

P.S. I know you aren't actually doing the work Eric.  "You" is really
addressed to those doing the build.

Re: Thanks for the Ada Bindings Help. Next Issue: Compilers

[Robert I. Eachus]

     Quick arithmetic gives 250k SLOC / 20 hours ~ 200 lines/minute.
Not great, even for Ada compilers, but I'd want a lot more information
before I called it bad...

     What model VAX are you compiling on? (If less than 2 MIPS, stop
here and upgrade.)

     What sort of disks are you using, and how full and/or how
fragmented are they?  On fast machines, Ada compiler performance is
usually dominated by disk performance.  Faster disks mean faster
compiles.

     If it takes 8 hours to transfer the source, the bottleneck on
that path is at about 250K * 40 char * 8 bits/8 * 3600 = 3000 baud.
About the expected throughput for a 9600 BPS line. If the compiler is
sending listings back by the same path, the time to send the listings
may be dominating the process.  Get a faster connection. (Ethernet?)

     One last question, why are you recompiling the world on a regular
basis?  There are times when a design change in an Ada program forces
such a compile, you may need to recompile the world when installing a
compiler upgrade, and there are times when configuration management
policies will require such a compile.  But on most Ada programs I have
been associated with, world compiles are scheduled for nights or
weekends when they don't disrupt development.  If you are recompiling
everything more often than once every two or three months, there is
something wrong with your configuration management system.  Tools
which are fine for small projects don't work well on large projects.

     Now that we have disposed of the non-Ada possibilities there are
a few Ada features which can cause slow recompiles if they are
misused. (Or if they are used correctly which is an entirely different
case... If a project estimated at several hundred thousand lines of
code can be written in 15K lines of Ada by nesting generics 4 or 5
deep, do you care that the compile takes 4 hours?)  There are four
main ways to choke an Ada compiler: with clauses, use clauses,
subunits, and generics.

     If an Ada program is written as lots of small compilation units
(good), but due to poor design or programmer laziness each unit has
dozens of with clauses, then the compiler can spend more time loading
context information than compiling the program.  And since importing
context is a file intensive process, slow disks will really kill you.

     If a program has lots of use clauses for packages with integer
types, the compiler can spend lots of time deciding which plus
operator the programmer wanted.  The compiler will either get it right
or complain, but the time to got through 100 visible definitions of
"+", or GET can cause a major slowdown.  There exist tools to fully
qualify all references, and they make maintenance much easier anyway.
(Except that most don't have a way of determining which use clauses
should be kept. It is a judgement call, but most programmers err on
the side of too many use clauses.

     You really have to be creative to choke an Ada compiler with
subunits, but it can be done.  Most compilers have to do some
processing of all the parent units of a subunit when the subunit is
compiled.  If the parent is, say a 50 line package body with twelve
300 line subunits, no big deal.  But we saw on project where the
subunits were nested 10 or 12 levels deep, with large numbers of
declarations at each level, but the leaf nodes were 30 lines long.

     Last but not least generics.  Generics are a very useful tool
when used right, but often processing unnecessary generic
instantiations will eat lots of compiler time (and some run time too!)
For example, I remember one package body where almost every subprogram
contained an instance of TEXT_IO.INTEGER_IO for STANDARD.INTEGER.
Replacing that with one instance in the package body tripled the
compilation speed.  (Some compilers have a special check for this
particular case to speed up ACVC compiles.)

     I hope that these suggestions help.  I am posting this so that
other people can try to avoid these traps.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...