Sizes of executables from Unix compilers

[mfeldman@seas.gwu.edu (Michael Feldman)]

Thought I'd try to shed a little light on the executable-size issue, since
it has come up again. First, a few statistics for "hello, world." Here
are 2 programs:

with Text_IO;
procedure Hello is
begin
  Text_IO.Put_Line("Hello, World.");
end Hello;

#include <stdio.h>
main()
{
   printf("Hello, World\n");
}

I compiled these using 4 Ada compilers and 2 C compilers. Here are the
sizes of the executables, with no optimization switches or anything else,
right out of the box:

C   (HP835)     34816
Ada (HP835)     86016

C   (Sun-3)     32768
Ada1(Sun-3)     57344
Ada2(Sun-3)    106496
Ada3(Sun-3)    139264

I am not identifying vendors because it serves no purpose to do so.
First of all, note that the C programs aren't so tiny either. Second,
the BIG differences in the Ada compilers suggests differing optimization
policies from the 4 vendors, for the _default_ case of no optimization.
My guess is that it has to do with the amount of Text_IO libraries they
are naively hauling into the executable. Given the small size of the
equivalent PC programs (as posted previously), I am conjecturing that
nobody is all that concerned about the _size_ of an executable intended
for a timesharing system, and that all vendors are probably optimizing 
for time rather than space.

To test my conjecture about Text_IO, I will try a program with no IO at all.

Regarding the size of the run-time system: there is absolutely nothing in
the "nature of the language" that precludes Ada programs being small. If
current compilers don't squeeze out every last byte, it's because "the market"
hasn't said it's that critical to do so. In any case the programs have
really come down in size over the successive compiler versions.

There is no need to link in a tasking kernel if no tasking is being done in 
the program. There is also no need to do unnecessary range checking, as the
LRM states very clearly.  The program only needs to check what it _needs_ to
check.

Suppose the programmer can second-guess the compiler about checking,
because (s)he knows that certain types or certain parts of the program
can be guaranteed not to raise Constraint_Error (or Numeric_Error)?
Well, using pragma SUPPRESS to cut out checking that the compiler leaves 
in is perfectly OK - that's why the pragma is in the language. 
This will make the program both smaller and faster, at the possible cost 
of erroneous behavior (because something happened in the program that
would've raised the exception if it hadn't been SUPPRESSed).

Here's another neat optimization issue: I believe that Ada programs have
the potential to be _faster_ than those in other languages if the type
system is used right:

Since A := B is defined for all nonlimited types, then large arrays can
be copied with a single Ada statement instead of the loop that Fortran
or C would require. Assuming the target machine has a fast block copy,
the compiler can potentially implement A := B much faster than it could
do the corresponding explicit loop. Yes, I know that a _really_ smart
compiler could detect that the whole array was being copied and throw
the loop away anyhow, but how many compilers do you know of that are
this smart?

Similarly, the statement

A := (others => (others => (others => 1.0)));

for a 3-level array can be implemented very quickly.

The bottom line: compiler optimization is a function of the maturity of
the compilers and of the marketplace. I believe there is nothing in Ada
that requires its programs to be slower or larger than _comparable_
programs in other languages. Be sure to compare apples to apples. If you
allow Ada to do range checking, for example, make sure your C code has the
corresponding "if" statements to do the same thing.