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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,344332f209947007
X-Google-Attributes: gid103376,public
From: Bryce Bardin <bbardin@home.com>
Subject: Re: Gnat Executable Size
Date: 1998/10/11
Message-ID: <3620F843.39465221@home.com>#1/1
X-Deja-AN: 399992102
Content-Transfer-Encoding: 7bit
References: <6volj0$250$1@uuneo.neosoft.com>
Content-Type: text/plain; charset=us-ascii
Organization: @Home Network
MIME-Version: 1.0
Reply-To: bbardin@home.com
NNTP-Posting-Date: Sun, 11 Oct 1998 11:25:28 PDT
Newsgroups: comp.lang.ada
Date: 1998-10-11T00:00:00+00:00
List-Id: <comp.lang.ada>

Robert B. Love wrote:
> 
> Over in the Modula-2 newsgroup somebody was asking about free compilers.
> Another person pointed out GNAT as suitable for his task and free.
> Ada vs. M2 wasn't the issue.  The original poster said he'd tried GNAT
> on a simple "hello world" program and was surprised to see a 200K
> executable.  Others said their favorite M2 compiler yielded about 10K
> executables for this.

This is a naive view of program size.  The size of executables depend on
several factors, including:

  1) the target machine architecture;
  2) the size and complexity of the program source code;
  3) the amount of debugging information included, if any;
  4) the degree and kinds of optimization performed by the compilation
     system and linker; and
  5) the size of any libraries used (which must be bound into the
     image).

Let us assume that you want to make a "fair" comparison between two
languages, comparing "oranges" with "oranges" and "apples" with
"apples".  
Then you need to control all of the above factors, and make
sure that the programs really are doing the same work:

  1) use the same target (this is easy); 
  2) make sure the program has as nearly as possible the same
semantic    
     effect in both languages (this is *much* harder than it appears at
     first sight);
  3) make sure that debugging information is stripped out (easy);
  4) compile and build using the options that lead to the smallest
     executable size (which will, in general, be *slower* to execute
     and may change the semantics of the program!) (this is
non-trivial);
     and
  5) use libraries with identical or very similar capabilities 
     (again hard to do between languages).

In comparing languages with differing semantics, the issue of program
behavior under stress must be accounted for.  For example, in Ada,
many checks that help to improve robustness are performed, both at
compile-time and at run-time.  If the comparison language doesn't
perform similar checks, then the comparison may be unfair (and there 
ain't no such thing as a free lunch, or in this case, a free check).  
Since most languages don't perform similar checks automatically, 
usually checks are turned off in the Ada executable to improve the 
comparison.  This defeats much of the ability for a well-designed Ada
program to perform reliably, but brings the semantics closer to the
norm for most other languages. 

Making sure that no debugging information is included is often 
overlooked.  Making sure that the "best" size optimizations are
performed 
can be surprisingly difficult.  You need to understand how both 
compilation systems work and all of the options quite well in order to 
do this correctly.
  
But the most difficult (and at the same time the easiest) parameter to 
control is the size of the libraries bound into the image.  The
capabilities of Ada's Text_Io package are much more sophisticated
than those of other languages' I/O libraries, so the Ada library size
will inevitably be larger.  On the other hand, an Ada program using I/O 
can be made more reliable.  

If the only measure of size that you use is the size of the "standard"
"hello world" program, Ada will always lose!

But there is also a simple way of making the comparison *very* fair: 
  use the same library!  
In Ada, import the other languge's I/O library and call it the
same way the other languges does.  Then the executable sizes will
be *very* similar (and in the case of gcc and gnat, the executables
may, in fact, actually be identical).

In the end, however, the best measure of executable size will not be a 
trivial program like "hello world", because most programs are not that 
small and simple. 

This is just one of the reasons why both hardware and software vendors 
and sophisticated developers find both hardware and application and 
development software benchmark testing to be a difficult and frustrating 
task.

 
(snip)

> 
> ----------------------------------------------------------------
>  Bob Love                                   MIME & NeXT Mail OK
>  rlove@neosoft.com
> ----------------------------------------------------------------