From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!seas.gwu.edu!mfeldman
From: mfeldman@seas.gwu.edu (Michael Feldman)
Newsgroups: comp.lang.ada
Subject: Re: Sizes of executables from Unix compilers
Message-ID: <1948@sparko.gwu.edu>
Date: 9 Jun 90 04:01:36 GMT
References: <1930@sparko.gwu.edu> <1990Jun8.213230.10693@cbnewsl.att.com>
Reply-To: mfeldman@seas.gwu.edu ()
Organization: The George Washington University, Washington D.C.
List-Id: <comp.lang.ada>

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