Executable File Size Differences

Executable File Size Differences

[Robert P. Kuzmicki]

I tried compiling a simple "Hello World" program with the Thomson Software's ActivAda for Windows
and Thomson's new "ObjectAda". The ActivAda version produces a executable file size of about 288K.
ObjectAda produces an exe of about 788K. Microsoft C++ produces an exe of about 10K. Why are the
executables so substantially different? Are the Ada compilers linking in alot of excess baggage? I
have tried various compiler switches, but nothing seems to shrink the exe file sizes.

Can anyone enlighten me here?

Re: Executable File Size Differences

[Georgi Savov]

Robert P. Kuzmicki wrote:
> 
> I tried compiling a simple "Hello World" program with the Thomson Software's ActivAda for Windows
> and Thomson's new "ObjectAda". The ActivAda version produces a executable file size of about 288K.
> ObjectAda produces an exe of about 788K. Microsoft C++ produces an exe of about 10K. Why are the
> executables so substantially different? Are the Ada compilers linking in alot of excess baggage? I
> have tried various compiler switches, but nothing seems to shrink the exe file sizes.
> 
> Can anyone enlighten me here?
Probably you are looking at the Debug version of the EXE file.
Try making a Release Version. I did. It is 83K.

Georgi Savov

Re: Executable File Size Differences

[Stanley Allen]

Georgi Savov:

> 
> Robert P. Kuzmicki:
> >
> > I tried compiling a simple "Hello World" program with the Thomson
> > Software's ActivAda for Windows and Thomson's new "ObjectAda". The
> > ActivAda version produces a executable file size of about 288K.
> > ObjectAda produces an exe of about 788K. Microsoft C++ produces an
> > exe of about 10K. Why are the executables so substantially different?
> > Are the Ada compilers linking in alot of excess baggage? I have tried
> > various compiler switches, but nothing seems to shrink the exe file sizes.
> >
> > Can anyone enlighten me here?
>
> Probably you are looking at the Debug version of the EXE file.
> Try making a Release Version. I did. It is 83K.
> 
> Georgi Savov

But this is still unacceptable isn't it?  Why should "Hello, world"
take 83K of executable code?  Maybe Microsoft C++ is using a DLL
for the I/O and ObjectAda is including it in the EXE.  But I'll bet
ObjectAda *is* using DLL's too, and that there's another reason.

I'm glad someone brought this topic up, because I've been
waiting for a chance to get on a soapbox.


I am not convinced that current Ada compilers could be used to

produce code for "major" PC software that would have acceptable

memory performance.  I'm thinking of full-featured products,

products that compete in the cut-throat PC software market at

the top echelons, where "feature-itis" issues are critical to
commercial success.  Products like WordPerfect, Netscape
Navigator, and Microsoft Access.  Could Ada be used to develop
commercially successful products in this arena?  I don't think
so.



I think the executable speed of the code produced by current

Ada compilers is up to snuff.  And I believe that, in general,

the number of bytes of executable code produced by current

Ada compilers for this or that section of source code is

competitive with that produced by C/C++ compilers for

functionally equivalent code segments.  But I *don't* believe

that the size of the executables produced by the linkers, and the

amount of RAM necessary to run these executables, is currently

acceptable for producing products in the above-described arena.



The problem is an old one: the lack of "smart linkers" which

would include only the necessary code from an Ada package, and

avoid linking in the unused bulk that never gets invoked.



This is an old complaint but still a valid one.  I've been in

the Ada bidness for about 10 years now, and the only smart

linker I can recall for PCs (my exposure may be weak here) was

Meridian.  Vendors seem to be content with the Ada-binder/

system-loader approach (a special Ada-specific binding step 

is performed to gather all the object files, which are then

passed to a general system-supplied loader, like Microsoft's
linker).  This approach has the advantage of portability and
easy implementation.  But since most Ada implementations
produce one object file for each package, a reference to
a procedure or variable in that package causes the low-level
linker to include the entire object module into the executable,
whether most of it is used or not.  



Not many Ada projects have historically demanded smart linkers
(except perhaps in the embedded controller domain), maybe
becuase not many DoD project managers have squawked about

code size.  The issue has never been "hot" among Ada developers

like other issues, for example speed of code execution, or

tasking/RTL performance.  Memory has generally been cheap

enough to justify upgrading the "project development" machine

and the limited number (sometimes only one) of "target" machines.



But in a large office complex with 100+ PC, careful thinking

must be given to purchasing a new WWW browser that would

require bumping everyone's RAM up by 8Mb or more.  And IMHO,

this is the kind of thing that would happen if current Ada
compilers were used as the development tool for producing
that new browser.



Smart linking is an simple idea which is hard to implement.

But it can be done, and I think it needs to be done as one

of the steps to make Ada a viable option for commercial

software developers, in addition to the work underway to

make Ada work with things like the Windows API.

There is no technical barrier, but it may be just a matter
of market dynamics: the C/C++ compiler vendors for the PC,
particularly Microsoft, Borland, and Symantec, have survived
in an aggressive business environment where their products
are scrutinized in trade journals and mass-market magazines
every few months.  Comparisons between them for code size,
execution speed, ease of use, feature sets, etc., are all
scored by developers and editors who put each product 
through a suite of tests and evaluate the results for the PC
programming community.  Detailed discussion of the merits
and demerits of each system (and subsystem) are provided to
give the readers an understanding of the trade-offs involved.
"Editor's choice" awards are given to the best, and numeric
results for the winners and losers are posted in large type
at the beginning of the article.

I assure you that these results are carefully considered 
as compiler selection criteria by developers and project
managers.


Of course, Ada has not hit the "big time" yet (cross your
fingers), but comparisons can be done on a smaller scale
within the Ada community: there is a standard compiler
evaluation suite (ACES:

    http://sw-eng.falls-church.va.us/AdaIC/testing/aces/README.html

) and I'm always suprised that there is so little published
about the results of such tests.  


Perhaps if such results were published, Ada vendors would be
provoked to go beyond the current state-of-the-art for Ada
compilers & up to the state-of-the-art for C/C++ compilers.


Stanley Allen
sallen@ghgcorp.com

Re: Executable File Size Differences

[Robert Dewar]

Stanley said

"The problem is an old one: the lack of "smart linkers" which

would include only the necessary code from an Ada package, and

avoid linking in the unused bulk that never gets invoked.
"

In the case of GNAT, whether or not unused subprograms get eliminated
is a funcytion of the system linkers, since standard object file formats
are used. On some sysetms they will, on many they will not. In any case
the situation will be the same for Ada as for C.

In practice we find that the size of executables is reasonably comparable
with C. I assume no one is tryingf to sell Hello World programs for the
PC, so that comparison is hardly significant. With programs of reasonable
size, the code sizes are comparable. The difference you see between
Hello Wolrd in GNAT (about 55K bytes) and C (10K bytes) is, as I said
earlier, due to the static linking in GNAT vs DLL linking in C, and also
the fact that more of the standard functionality is brought in for a 
simple program (that's because Text_IO has a lot of capability that
the corresponding C routines do not).

But once you get to larger programs, that 40K bytes becomes an unimportant
difference.

Re: Executable File Size Differences

[Richard A. O'Keefe]

Stanley Allen <sallen@ghgcorp.com> writes:
>I am not convinced that current Ada compilers could be used to
>produce code for "major" PC software that would have acceptable
>memory performance.  I'm thinking of full-featured products,
>products that compete in the cut-throat PC software market at
>the top echelons, where "feature-itis" issues are critical to
>commercial success.  Products like WordPerfect, Netscape
>Navigator, and Microsoft Access.  Could Ada be used to develop
>commercially successful products in this arena?  I don't think
>so.

I took Netscape off my Macintosh Centris 660AV because
- it swiped half of the machine's 16Mb memory for its own use
- and could be relied on to trash the other half.
Maybe if Netscape had been written in Ada I could have afforded
to keep on running it, but I have better things to do with my
time than reboot a Mac every couple of hours.
Now when I run Netscape (which is when Mosaic has trouble) I run
it through a terminal emulator window and just delete the occasional
"core" file.

When you are up around the 8Mb memory size (and I assure you, that
really truly is the amount of memory Netscape wanted), the run-time
library size is irrelevant.

>I think the executable speed of the code produced by current
>Ada compilers is up to snuff.

More than!  When anyone tells me "I'm not going to use Ada for this,
I'm going to use C for efficiency" I laugh at them.

>But I *don't* believe
>that the size of the executables produced by the linkers, and the
>amount of RAM necessary to run these executables, is currently
>acceptable for producing products in the above-described arena.

The trouble with this is that while you may very well have grounds
for your statement, we don't know that unless you tell us.
- How many Ada compilers have you checked the current versions of?
- Which platforms?  Just the PC, or the Mac as well, or UNIX (which)?
- Which kinds of applications have you measured?

For what it's worth, I note that the Encore Multimax "Pascal-2" compiler
generated executables containing only the subprograms reachable from the
main program, _without_ a "smart linker" provided by the operating system.

>The problem is an old one: the lack of "smart linkers" which
>would include only the necessary code from an Ada package, and
>avoid linking in the unused bulk that never gets invoked.

C doesn't have this either, nor do any of the C++ compilers I have used.

In fairness to UNIX (and other) linkers, there is nothing in COFF or ELF
that says a compiler cannot generate a "lib.a" file instead of a "lib.o".
The DOS loaders can handle library files of some sort too.

>But in a large office complex with 100+ PC, careful thinking
>must be given to purchasing a new WWW browser that would
>require bumping everyone's RAM up by 8Mb or more.

Ah.  So you _don't_ use Netscape.  /opt/local/sun4/bin/netscape.bin
is protected so I can't use "size", but "ls" says it's 4.2Mb,   Dear
knows how much data space it needs.

>Smart linking is an simple idea which is hard to implement.

If Encore Pascal-2 could do it, it _can't_ be hard.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Executable File Size Differences

[Ken Cowan]

In article <52o1a8$fre@goanna.cs.rmit.edu.au>,
   ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) wrote:
>Stanley Allen <sallen@ghgcorp.com> writes:
>
>>The problem is an old one: the lack of "smart linkers" which
>>would include only the necessary code from an Ada package, and
>>avoid linking in the unused bulk that never gets invoked.
>
>C doesn't have this either, nor do any of the C++ compilers I have used.

Both Visual C++ and ObjectAda for Windows have a smart linker.   If you
have a source file containing hundreds of subprograms but only call
one of them, then only that one gets included into the image.

  KC

---------------------------------------------------------
Ken Cowan                       Thomson Software Products
cowan@east.thomsoft.com         200 Wheeler Rd.
phone: (617) 221-7323           Burlington, MA 01803
fax: (617) 220-6882

Re: Executable File Size Differences

[Stanley Allen]

Ken Cowan (Thompson):

> Both Visual C++ and ObjectAda for Windows have a smart linker.   If you
> have a source file containing hundreds of subprograms but only call
> one of them, then only that one gets included into the image.
> 

Hurray!!!!  I'm happy to be corrected in this way.

Now, is anyone going to publish Ada95 compiler comparisons?
Peter Coffee wrote an article for this week's PC Week (Sept. 30)
touting ObjectAda, with *actual performance figures!*

Gentlemen, start your engines...

Stanley Allen
sallen@ghgcorp.com

Ada 95 - Performance vs. Pervasiveness (was: Executable File Size Diff

[Larry Kilgallen]

In article <32548F78.5D64@ghgcorp.com>, Stanley Allen <sallen@ghgcorp.com> writes:

> Now, is anyone going to publish Ada95 compiler comparisons?

My own preference would be for vendors to spend their time on
porting to additional platforms rather than fighting performance
for uncovered platforms which interest me. To a great extent these
platforms do _not_ overlap those for the other vendors.

> Gentlemen, start your engines...

Gentlemen (and ladies), start your _other_ engines...

Larry Kilgallen

Re: Executable File Size Differences

[Robert I. Eachus]

In article <52o1a8$fre@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

  > If Encore Pascal-2 could do it, it _can't_ be hard.

  Uh, it is hard, but for an unexpected reason.  The standard practice
in Ada is to initialize variables when they are declared, if it makes
sense to do so.  So lots of packages create large executables which
are called at elaboration time to initialize a few variables (often
including one which indicates that the package has been elaborated).

  Now many of these variables may never be referenced again, but there
is code in other uncalled procedures that references them.  Worse,
some of the functions will be called to do those initializations.

  So the "tricky" part is in pulling apart object units created by
packages and first creating a full graph tree, then track set/refs on
all variables and find those that are set but never referenced.
Eliminate the code to set those variables and iterate.  You either
need the debug information in the object module or better the compiler
generated AST to do this.  (Of course, you can get a situation where
two units each reference one variable that is set by the other.  Not
erroneous if there is also an initial value.  We thought about
designing in a test for this case, but in practice we designed it out
when encountered.)

  Finally you can pull all the uncalled code and debug information
out.  We had an Ada compiler at Honeywell that did this.  Even more,
it kept track of opportunities to inline subprograms that were
eventually only called once.  But to get the full treatment, you had
to compile--and link--the entire program as a single source file.
Hello World cooked down under 100 bytes, but it took over ten minutes
to do it if you used Text_IO. ;-) (And yes, even on large projects it
was worth it to compile the final release version in this mode.
Unfortunately we ended up with a couple subsystems that wouldn't fix
into memory otherwise, so they always had to be compiled this way.)

    Note that with dynamic linking and first reference traps or a
similar mechanism, all the pain goes away, and you can have an
executable for Hello World that is under 50 bytes--in any language.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Executable File Size Differences

[John Howard]

On 2 Oct 1996, Robert I. Eachus wrote:
> (Richard A. O'Keefe) writes:
> > If Encore Pascal-2 could do it, it _can't_ be hard.
>
>   Uh, it is hard, but for an unexpected reason.  The standard practice
> in Ada is to initialize variables when they are declared, if it makes
> sense to do so.  So lots of packages create large executables which
> are called at elaboration time to initialize a few variables (often
> including one which indicates that the package has been elaborated).
>
>   Now many of these variables may never be referenced again, but there
> is code in other uncalled procedures that references them.  Worse,
> some of the functions will be called to do those initializations.
>
>   So the "tricky" part is in pulling apart object units created by
> packages and first creating a full graph tree, then track set/refs on
> all variables and find those that are set but never referenced.
> Eliminate the code to set those variables and iterate.  You either
> need the debug information in the object module or better the compiler
> generated AST to do this.

[snip]

The programmers are the first to notice code bloat.  That's why Hello
World measurements are useful.  Otherwise who is to say that a Hello World
program should be less than a megabyte?

Eliminating dead-code still does not seem like too big a problem with the 
aid of an automated cross-reference tool.  Even only eliminating the
non-referenced objects and subprograms would be a big improvement.

Turbo Pascal compiles its "packages" into AST's called TPU's.  Debug code 
is optional.  The recursive structure of the TPU is the reason for the
fast link times while allowing dead-code elimination.  A Turbo Pascal
package can provide an initialization section which gets elaborated once
during run-time.  That's how variables were initialized by a controlled
mechanism but it was not common to flag when initialization happened.
With Turbo Pascal you get small executables in a hurry.  Smart linking and
quickness largely enables rapid prototyping during design-time.  Rapid
Application Development (RAD) really changes the way common programs get
developed.  Borland Delphi is an example of a RAD tool that adds an
interactive and interpretive stage during design-time.

Whatever Delphi can do, the GNAT compilation model is flexible enough to
do likewise.  GNAT documentation indicates the cross-reference tool will
eventually be used in a smart linking system.  GNAT compiling with
semantic checking turned ON and code generation OFF provides the rapid
feedback that Turbo Pascal users enjoy.  In general, GNAT's missing
elements are a smart linker and an interactive design environment.  The 
smart linker is needed first.  Volunteers can produce custom design
environments.

>     Note that with dynamic linking and first reference traps or a
> similar mechanism, all the pain goes away, and you can have an
> executable for Hello World that is under 50 bytes--in any language.
>
> 					Robert I. Eachus

We can always benefit from smaller executables.  And we need the option to 
share DLL's.  But we should not have to use a DLL in order to quote a 
smaller size for an executable.

If a DLL is not shared by other executables then it typically wastes disk
space.  Also I think of the large VBRUN DLL's required by trivial Visual 
Basic programs.  There were several incompatible versions of the VB
run-time and people ended up keeping them all around.  The large DLL's
waste storage space and cost bandwidth to distribute.  Consequently VB
programmers lose the opportunity to enter some niche markets.  That will
become more important to them as their pool of opportunities shrink.  I've
seen the pool shrink for Turbo Pascal programmers but for different 
reasons.  Ada 95 and GNAT solved the problems I encountered with Turbo
Pascal.  Though GNAT needs work to create a Delphi-like environment.

The reason we need dead-code elimination is because a smaller resource
requirement is always better than waste.  And waste on a large scale is
a form of pollution which somebody sometime is going to have to clean up.

-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --

RE: Executable File Size Differences

[Simon FitzMaurice]

There are two flavours of debugging information (Ada debugging and
CodeView - see the checkboxes on the link tab) optionally included in the
executables in *non-loadable* segments.  The use of each of these
significantly affects the size of "hello.exe" as the following table
indicates:

				   Ada debug
				Y		N
Codeview debug	Y	732104	331712
			N	732032	84480

Note that it is possible to remove debugging information from an
executable using the command "cvpack /strip".  The true memory footprint
is always most accurately determined from the link map.

In future versions it will be possible to link to the runtime in a DLL;
this further reduces the size of "hello.world" to around 10k without debug
(like MSVC).

Simon FitzMaurice
Principal Software Engineer
Thomson Software Products
200 Wheeler Road
Burlington MA 01803


On Wednesday, September 25, 1996, Georgi Savov wrote...
> Robert P. Kuzmicki wrote:
> > 
> > I tried compiling a simple "Hello World" program with the Thomson
Software's ActivAda for Windows
> > and Thomson's new "ObjectAda". The ActivAda version produces a
executable file size of about 288K.
> > ObjectAda produces an exe of about 788K. Microsoft C++ produces an exe
of about 10K. Why are the
> > executables so substantially different? Are the Ada compilers linking
in alot of excess baggage? I
> > have tried various compiler switches, but nothing seems to shrink the
exe file sizes.
> > 
> > Can anyone enlighten me here?
> Probably you are looking at the Debug version of the EXE file.
> Try making a Release Version. I did. It is 83K.
> 
> Georgi Savov
> 

Re: Executable File Size Differences

[Jon S Anthony]

In article <324D6631.4F3F@ghgcorp.com> Stanley Allen <sallen@ghgcorp.com> writes:

> But this is still unacceptable isn't it?  Why should "Hello, world"
> take 83K of executable code?  Maybe Microsoft C++ is using a DLL
> for the I/O and ObjectAda is including it in the EXE.  But I'll bet
> ObjectAda *is* using DLL's too, and that there's another reason.

First it is a constant overhead.  Second you are wrong - ObjectAda
does not currently use a DLL for this and will move to the size of the
MSVC version when it does (as noted by a Thomson engineer in another
reply).  So you are just wrong.



> I'm glad someone brought this topic up, because I've been
> waiting for a chance to get on a soapbox.

Well, your soapbox just collapsed - being based on completely
erroneous ideas and unsound thinking.  This in turn makes your
subsequent rant make you look like a fool.


> But in a large office complex with 100+ PC, careful thinking must be
> given to purchasing a new WWW browser that would require bumping
> everyone's RAM up by 8Mb or more.  And IMHO, this is the kind of
> thing that would happen if current Ada compilers were used as the
> development tool for producing that new browser.

You can't be serious.  MSWord alone can't be usefully used anymore
without vast amounts of RAM and even then it is dead slow.  In fact,
much common PC software (typically MS produced...) is hugely bloated
and snail paced.  If any of what you said about size issues affecting
PC usability were true, none of these packages would be used.  But we
all know that they are (unfortunately).

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Executable File Size Differences

[Robert I. Eachus]

   I said:

   >     Note that with dynamic linking and first reference traps or a
   > similar mechanism, all the pain goes away, and you can have an
   > executable for Hello World that is under 50 bytes--in any language.


In article <Pine.GSO.3.93.961006144724.15733A-100000@sky.net> John Howard <jhoward@sky.net> writes:

  > We can always benefit from smaller executables.  And we need the option to 
  > share DLL's.  But we should not have to use a DLL in order to quote a 
  > smaller size for an executable...

   No DLL in sight!  The trick is that with first reference traps all
the (Text_IO) variables never referenced in this program are actually
initialized by the first reference traps.  The compiler front-end
may generate code to update all this junk (column number, line number,
page number, etc.), but since there are no visible references, the
compiler backend can (and will) delete all the assignments to them.
Now all we are left with is a single in-lined system call to write a
string literal to standard out.

   Actually, hmmm...

with System;
procedure Syswrite is
   use System;
   procedure system(X: in Address);
   pragma Interface(C, system);
   Temp: String(1..20) := "echo ""Hello World!""" & Ascii.Nul;
begin
   System(Temp'Address);
end Syswrite;

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

  SunAda (VADS):

-rw-r--r--  1 eachus        226 Oct 10 19:37 syswrite.a
-rw-r--r--  1 eachus         85 Oct 10 19:43 hello.a
-rwxr-xr-x  1 eachus      81920 Oct 10 19:40 SYSWRITE
-rwxr-xr-x  1 eachus     270336 Oct 10 19:44 HELLO

  GNAT 3.05 on SunOS 4.1.3:

-rw-r--r--  1 eachus        219 Oct 10 20:15 syswrite.adb
-rw-r--r--  1 eachus         93 Oct 10 20:01 hello.adb
-rwxr-xr-x  1 eachus      65536 Oct 10 20:15 syswrite
-rwxr-xr-x  1 eachus     286720 Oct 10 20:05 hello

   (Slight differences in sources sizes are because I eliminated the
constraint on Temp and added "Ada." to Text_IO for GNAT.  Force of habit. ;-)

   Well there is a lot of extra stuff in there still.  Anyone want to try
some more?

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...