Sizes of executables from Unix compilers

Sizes of executables from Unix compilers

[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.

Re: Sizes of executables from Unix compilers

[Erland Sommarskog]

Michael Feldman (mfeldman@seas.gwu.edu) gives the sizes of some
"hello world" programs:
>C   (HP835)     34816
>Ada (HP835)     86016
>
>C   (Sun-3)     32768
>Ada1(Sun-3)     57344
>Ada2(Sun-3)    106496
>Ada3(Sun-3)    139264

I don't think this is a language issue, but one of operating system.
Shared libraries is apparently not a standard features on Unix, it
has been on VMS as long as I have known. I haven't tried a "Hello
world" on VMS, but it should be less than 10 blocks (= 5120 bytes).

Of course, an Ada system under Unix could do various optmizations
at link time to keep down the size, on the other hand why adopt
to an ancient technology?
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se

Re: Sizes of executables from Unix compilers

[Doug McDonald]

In article <1700@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>Michael Feldman (mfeldman@seas.gwu.edu) gives the sizes of some
>"hello world" programs:
>>C   (HP835)     34816
>>Ada (HP835)     86016
>>
>>C   (Sun-3)     32768
>>Ada1(Sun-3)     57344
>>Ada2(Sun-3)    106496
>>Ada3(Sun-3)    139264
>
>I don't think this is a language issue, but one of operating system.

Perhaps. Let me add:

assembler(IBM-PC)    22
C(IBM-PC)         3-8000 depending

Does anybody recall how many (decimal digits, not bytes) it would be
on an IBM 1620 -  my guess would be 23 or 24 decimal digits (5 bits
per decimal digit). (This would, of course be machine language :-), 
input at the console typewriter.) Anybody out there still remember
the codes? 

Doug McDonald

Re: Sizes of executables from Unix compilers

[diamond@tkovoa]

In article <1990Jun6.230600.4736@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
>In article <1700@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>>Michael Feldman (mfeldman@seas.gwu.edu) gives the sizes of some
>>"hello world" programs [deleted]
>>I don't think this is a language issue, but one of operating system.
>Perhaps. Let me add:
>assembler(IBM-PC)    22
>C(IBM-PC)         3-8000 depending
>Does anybody recall how many (decimal digits, not bytes) it would be
>on an IBM 1620 -  my guess would be 23 or 24 decimal digits (5 bits
>per decimal digit). (This would, of course be machine language :-), 

Awright, you asked for it.
It's impossible.
OK, here goes for a "HELLO WORLD" program (which is possible in upper
case), and I've forgotten the typewriter control digit for carriage
return so I put a ? in the listing below.  Also there's no record
mark in ASCII, so I put a # in the listing.
locn.  instruction   mnemonic
00000  360002700100  WATY 27 (write alpha to ty, starting locn. 00026/00027)
00012  34000000010?  RCTY    (return carriage on typewriter)
00024  484845535356  H2      (halt)  Note that the addresses are ignored
         ||||||||||                  in a halt instruction, so we start
        //////////                   using that space for data instead of
       ||||||||||                    wasting it.
00026  48455353560066565953440#   DAC 12,HELLO WORLD@  (define alpha const)
So you would just type in:
36000270010034000000010?4848455353560066565953440#
Looks like fifty digits.

Typical software management here, underestimated by a factor of 2.

-- 
Norman Diamond, Nihon DEC     diamond@tkou02.enet.dec.com
Proposed group comp.networks.load-reduction:  send your "yes" vote to /dev/null.

Re: Sizes of executables from Unix compilers

[arny.b.engelson]

In article <1930@sparko.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>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 can't believe I'm doing this.  I got curious enough to go run these on
a VAX/VMS system using DEC's Ada and C compilers.  Given the results, I
decided to post them (and start a war I'm sure, but what the hell)...

First of all, I ran the compilers with their default settings, no special
optimizations, pragmas, options, nothing.  Second, the source looks exactly
like Mike's programs above.  Last, the results:

Ada executable =  6 blocks (512 byte blocks)
C   executable = 87 blocks   "

Obviously, I now conclude that Ada is 14.5 times more efficient than C.

Go and analyze this to death if you want, it's still one of the stupidest
language comparison tests I've ever seen; I just found the results amusing
enough to post.  But then I didn't get enough sleep last night and it's
been a long week.

  -- Arny Engelson   att!wayback!arny

Re: Sizes of executables from Unix compilers

[Michael Feldman]

In article <1990Jun8.213230.10693@cbnewsl.att.com> arny@cbnewsl.att.com (arny.b.engelson) writes:
>In article <1930@sparko.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
[ a bunch of stuff deleted ]
>
>I can't believe I'm doing this.  I got curious enough to go run these on
>a VAX/VMS system using DEC's Ada and C compilers.  Given the results, I
>decided to post them (and start a war I'm sure, but what the hell)...
>
>First of all, I ran the compilers with their default settings, no special
>optimizations, pragmas, options, nothing.  Second, the source looks exactly
>like Mike's programs above.  Last, the results:
>
>Ada executable =  6 blocks (512 byte blocks)
>C   executable = 87 blocks   "
>
>Obviously, I now conclude that Ada is 14.5 times more efficient than C.
>
>Go and analyze this to death if you want, it's still one of the stupidest
>language comparison tests I've ever seen; I just found the results amusing
>enough to post.  But then I didn't get enough sleep last night and it's
>been a long week.

This may sound really humorless, but the whole point of the "stupid"
language comparison tests I originally posted was to show precisely that
it is stupid to judge a language based on silly things like the size of
executables for trivial programs like these. I was responding to a posting
from Ted Holden (who else?) that made a preposterous claim about the size of
a "hello world" in Ada, and asserting that the reason for the humongous
executables was somehow in the nature of the language. In case I didn't
make the points articulately, here they are:

1. even programs of apparently trivial nature CAN lead to nontrivially-large
   executables, because of library stuff that gets linked in;

2. this characteristic is by no means unique to Ada, and has _very little_
   to do with the "nature of the language" - it has much more to do with
   the engineering tradeoffs made by compiler/linker implementers;

3. the whole point of showing 4 different Ada compilers was to demonstrate
   point (2) - that implementers make lots of decisions that have little
   to do with the "nature" of the language;

4. it's also the case that large executables aren't necessarily bad.
   Pragma INLINE comes to mind as an example of a time/space tradeoff in
   which a procedure is in-lined at each invocation, saving the time
   (and stack space!) of a subroutine call per invocation. But for an
   inlined procedure with a nontrivial number of invocations, this will
   increase the size over the non-inlined one. This is good, not bad,
   as it will speed the program's execution up.

Please don't anyone think I was trying to make a serious comparison of Ada
vs. C here. It was just the opposite, really - to show how foolish these
generalizations are. Sorry if I misled any readers.
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052
+1-202-994-5253
mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: Sizes of executables from (UNIX) VMS compilers

[tdhammer]

In article <1700@enea.se>, sommar@enea.se (Erland Sommarskog) writes:
> Michael Feldman (mfeldman@seas.gwu.edu) gives the sizes of some
> "hello world" programs:
>>C   (HP835)     34816
>>Ada (HP835)     86016
>>
>>C   (Sun-3)     32768
>>Ada1(Sun-3)     57344
>>Ada2(Sun-3)    106496
>>Ada3(Sun-3)    139264
> 
> I don't think this is a language issue, but one of operating system.
> Shared libraries is apparently not a standard features on Unix, it
> has been on VMS as long as I have known. I haven't tried a "Hello
> world" on VMS, but it should be less than 10 blocks (= 5120 bytes).
> -- 
> Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se


Just did a quick compile of Feldman's 4 programs under VAX/VMS Ver 5.2.
Here are the results:

		  Hello, World		   Null Program

C  		    128 blocks		    122 blocks
Ada		      6 blocks		      5 blocks

Very interesting!  (A block is 512 bytes.)  Apparently the sharable
libraries under VMS do make a big difference.  Why the big numbers
with the C code?

I also compiled the hello, world program in Ada using the "bad" :-;
USE-clause.  The executable was also 6 blocks, however, I believe that
VMS only makes allocation in 3-block groups, therefore, there could be
a almost 1536 bytes difference between the two versions.

		Tim .D.
-------------------------------------------------------------------------------
Tim .D. Hammer                         BITNET: TDHAMMER@TWSUVAX
Teaching/Research Assistant            UUCP: (currently no good address)
Computer Science Dept.                 INTERNET: tdhammer@wsuiar.wsu.UKans.EDU
Wichita State University               
Wichita, Ks.  67208-1595               TalkNET: (316)689-3156
-------------------------------------------------------------------------------
"A little learning is a dangerous thing." Alexander Pope

Re: Sizes of executables from VMS (was UNIX) Compilers

[RCAPENER]

In article <1990Jun8.213230.10693@cbnewsl.att.com>,
arny@cbnewsl.att.com (arny.b.engelson) writes:

	[ Hello World code and other stuff deleted ]

> I can't believe I'm doing this.  I got curious enough to go run these on
> a VAX/VMS system using DEC's Ada and C compilers.  Given the results, I
> decided to post them (and start a war I'm sure, but what the hell)...
> 
> First of all, I ran the compilers with their default settings, no special
> optimizations, pragmas, options, nothing.  Second, the source looks exactly
> like Mike's programs above.  Last, the results:
> 
> Ada executable =  6 blocks (512 byte blocks)
> C   executable = 87 blocks   "
>

I can't either, since I assume you already know that Ada (and almost all
other languages on VAX-VMS) link in the shared libraries by default, while
C does not.  To do that you need a file (name it SHARE.OPT) in your SYS$LOGIN
directory that has the following line in it:

sys$share:vaxcrtl/share

then you link your files as follows:

link file1,file2,file3,sys$login:share.opt/opt

You can also create a simple clink.com file for handling one *.obj file
that was created from one C source file.  Put it in your SYS$LOGIN dir.
It is as follows:

$ if "''p1'" .nes. "" then goto$ setlinkfile
$ if "''shlinkprevfile'" .eqs. "" then goto$ getfile
$ $goto dolink
$ getfile:
$ inquire p1 "enter filename"
$ setlinkfile:
$ shlinkprevfile == "''p1'"
$ dolink:
$ link 'shlinkprevfile',sys$login:share.opt/opt
$ assign/user sys$command sys$input
$ exit

You also need the following line in your LOGIN.COM file:

$ clink :== @sys$login:clink

You will notice that now that the C code is linked with the shareable
libraries, it shrinks drastically in size, and is usually smaller than
the equivalent Ada *.exe file.

This blurb was provided for the enlightenment for those in the Ada
community that work strictly on UNIX and DOS machines.  If you link
the non-shared libraries with C (the default), and link the shared
libraries with Ada (also the default) on VAX-VMS, you are comparing
apples with oranges.  Link the C generated code shared, and we have
a fairer apples - apples comparison.  I am sure Arny knew this, and
produced it solely for the entertainment of the VAX-VMS community.


Happy times with Ada (pun intended)

Re: Sizes of executables from (UNIX) VMS compilers

[David Kassover]

In article <204.2670cec6@wsuiar.uucp> tdhammer@wsuiar.uucp writes:
...
>Just did a quick compile of Feldman's 4 programs under VAX/VMS Ver 5.2.
>Here are the results:
>
>		  Hello, World		   Null Program
>
>C  		    128 blocks		    122 blocks
>Ada		      6 blocks		      5 blocks
>
>Very interesting!  (A block is 512 bytes.)  Apparently the sharable
>libraries under VMS do make a big difference.  Why the big numbers
>with the C code?

just to confuse things a little more:  When you linked the C
program, did you scan the C run time library explicitly, or use
the shareable image for that, too?

Also bear in mind that the VMS linker does "demand-zero
compression" of pages that are known to contain zero, so that
these pages, while part of the address space of the program, do
not appear in the file that contains the executable image.

There are lots of other linker options that can be used to
"optimize" the image.  Some of them have significant effects on
the size of the file that is used to store the image.

>I also compiled the hello, world program in Ada using the "bad" :-;
>USE-clause.  The executable was also 6 blocks, however, I believe that
>VMS only makes allocation in 3-block groups, therefore, there could be
>a almost 1536 bytes difference between the two versions.

File allocation clusters are properties of the volume on which
they are stored, not the language used to create object, nor the
linker option used to create the executable.


Sheesh.  Comparing VMS to other operating systems which may or
may not run on the same hardware is almost as inapropos as
comparing C and Ada.  As if *any* one implementation was the
be-all and cure-all for the universe.


--
David Kassover             "Proper technique helps protect you against
kassover@ra.crd.ge.com	    sharp weapons and dull judges."
kassover@crd.ge.com			F. Collins

Re: Sizes of executables from VMS (was UNIX) Compilers

[arny.b.engelson]

In article <68773@cc.utah.edu> RCAPENER@cc.utah.edu writes:
>In article <1990Jun8.213230.10693@cbnewsl.att.com>,
>arny@cbnewsl.att.com (arny.b.engelson) writes:
>
>	[ Hello World code and other stuff deleted ]
>
>> Ada executable =  6 blocks (512 byte blocks)
>> C   executable = 87 blocks   "
>
>I can't either, since I assume you already know that Ada (and almost all
>other languages on VAX-VMS) link in the shared libraries by default, while
>C does not.  To do that you need a file (name it SHARE.OPT) in your SYS$LOGIN
>
>You will notice that now that the C code is linked with the shareable
>libraries, it shrinks drastically in size, and is usually smaller than
>the equivalent Ada *.exe file.
>
>This blurb was provided for the enlightenment for those in the Ada
>community that work strictly on UNIX and DOS machines.  If you link
>the non-shared libraries with C (the default), and link the shared
>libraries with Ada (also the default) on VAX-VMS, you are comparing
>apples with oranges.  Link the C generated code shared, and we have
>a fairer apples - apples comparison.  I am sure Arny knew this, and
>produced it solely for the entertainment of the VAX-VMS community.


Well, yes, if you link the C code with the shareable libraries it gets much
smaller (actually I believe it ends up to be almost the same size as the
Ada executable, give a block one way or the other), and yes this then becomes
more of an apples to apples comparison.  But, the problem is a lot of people
DON'T take these issues into account when doing language comparisons.  When
your novice programmer (or an experienced programmer in a new environment)
sits down to write some code, they will come up with the results I posted,
since there will probably be nobody there to enlighten him/her.  Depending on
when you receive the articles, you may already have seen another post of VMS
results with even worse numbers for C than mine (FYI, I am running different
versions of the products than he is).  Sure gets your attention, doesn't it?

In any case, this is part of the reason such language comparison results are
often meaningless, despite the fact that they ignore the larger issues such
as life cycle costs.  Reminds me a lot of statistics.  Which language is more
efficient?  Well, which language do you WANT to be more efficient?

  -- Arny Engelson   att!wayback!arny

Re: Sizes of executables from (UNIX) VMS compilers

[Paul A. Varner]

I am afraid, I started something idiotic here.  I posted sizes of executible
programs compiled using C and Ada as a response to Ted Holden's claim that
part of the reason Ada was bad was because it created huge executible files
for trivial programs (i.e Hello, World!).  I posted the sizes to show that his
claim was ludicrous.  Instead that the size depended on the Compiler not the
language.  I think that this group has shown this point, so I am asking that 
we get back to more important subjects.  BTW Thanks to Prof. Feldman for also
showing this point as well.  

						Paul Varner
 

Re: Sizes of executables from Unix compilers

[Erland Sommarskog]

arny.b.engelson (arny@cbnewsl.att.com) gives some figures for
"Hello World" programs on VMS:
>First of all, I ran the compilers with their default settings, no special
>optimizations, pragmas, options, nothing.  Second, the source looks exactly
>like Mike's programs above.  Last, the results:
>
>Ada executable =  6 blocks (512 byte blocks)
>C   executable = 87 blocks   "

Again, an operating system issue. C doesn't really fit with VMS.
Linking C is not as straightforward for other languages. I don't
use C myself, but I think a link command like

   $ LINK prog,sys$input/option
   vaxcrtlg/share

or something similar will cut down the C executable to reasonable sizes.

I like to restress the point I made a while ago: if your tiny "hello
world" program makes the disk explode, don't blame the langauge,
blame the operating system which doesn't provide shareable images.
If the OS does, blame the compiler who doesn't use them.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se