GNAT Executables: How low can you go?

GNAT Executables: How low can you go?

[Geert Bosch]

Boring stuff
~~~~~~~~~~~~
Last week I've done a rewrite of a full featured regular expression 
matcher (the one that comes with EMX) for Ada. The C-version was awkward
to use because of the need of a terminating NUL character, bad error 
handling and use of global variables which makes tasking nearly 
impossible. The final RE matcher is 55 kB of source (I guess just 15% 
comments) and 1600 lines and doesn't need dynamic memory allocation. 

This is better...
~~~~~~~~~~~~~~~~~
Using GNAT v3.01 for OS/2 and default compilation, but with optimizations
on and checks suppressed resulted in an executable of 114 kB which ran about
3 times as slow as the C version. Now with some tweaking the source has 
changed a little (about 20 lines were modified) and now the code is
just 15-20% slower than the C version which is not bad considering the
extra robustness and safety. 

And now the GOOD news!
~~~~~~~~~~~~~~~~~~~~~~
The complete application which also produces debug information about
the regular expression and which dumps the complete statusmachine in
human-readable format is only 11616 bytes in size!!! I really didn't
know GNAT executables could be this small and I even used string
slices, exception handlers, discriminated records containing
variable-sized arrays and text-io on integers, booleans and enumeration
types. There was no 'dead' code in the source and all generated code 
and message strings are in the 11616 byte executable.

Of course I'll explain the tricks later but it's already late now.
I just had to let you know how great GNAT really is. ;-) ;-)

Regards,
   Geert Bosch
-- 
E-Mail: geert@sun3.iaf.nl     *** As far as we know, there have not been ***
 Phone: +31-53-4303054        ** any undetected failures in our software. **

Re: GNAT Executables: How low can you go?

[Robert Dewar]

Geert said

"The complete application which also produces debug information about
the regular expression and which dumps the complete statusmachine in
human-readable format is only 11616 bytes in size!!! I really didn't
know GNAT executables could be this small and I even used string
slices, exception handlers, discriminated records containing
variable-sized arrays and text-io on integers, booleans and enumeration
types. There was no 'dead' code in the source and all generated code
and message strings are in the 11616 byte executable."

I of course like to see positive posts about GNAT like this, but surely
that figure of 11,616 is wrong, I could believe 116K, but 12K must
be wrong, especially if you are using statically linked libraries.
Text_IO alone is larger than this.

Can you double check your numbers ....

Re: GNAT Executables: How low can you go?

[Geert Bosch]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: I of course like to see positive posts about GNAT like this, but surely
: that figure of 11,616 is wrong, I could believe 116K, but 12K must
: be wrong, especially if you are using statically linked libraries.
: Text_IO alone is larger than this.

But I didn't say I linked the runtime libraries static ;-) All the
application code, the regexp library  and the necessary headers/stub
fits in 12K. The smallest I could get with statical linking was 52 kB.

But since most C apps use emx.dll and emxlibc.dll, why couldn't Ada
apps not use a dll? I put *all* of the GNARL code (700 kB of .o files)
in one 250 kB dll and link all apps against that. This is a really good
way of avoiding those bloated executables we see otherwise. 

: Can you double check your numbers?

Yes, I did so before posting my previous article. You should also note
that the dynamically linked GNAT Runtime Libraries (GNATLIB.DLL) and
my own apps have been compressed using LXLite. The compressed GNAT1.EXE
(about half the size of the original GNAT1.EXE) seems to load even faster
when not using EMXLoad. When EMXLoad is used the times don't differ.

Of course I also used LINK386 instead of ld, since it seams to produce
much smaller executables. 

Still, even considered all tricks, 12 kB for the application code 
including all regexp code and the necessary .EXE headers is very
little, I think. 

Regards,
   Geert


PS. My newsfeed seems to be broken, so please send a copy of any
    follow-ups to geert@sun3.iaf.nl. 

Re: GNAT Executables: How low can you go?

[Theodore E. Dennison]

Geert Bosch wrote:
> 
> But I didn't say I linked the runtime libraries static ;-) All the
> application code, the regexp library  and the necessary headers/stub
> fits in 12K. The smallest I could get with statical linking was 52 kB.
> 
> But since most C apps use emx.dll and emxlibc.dll, why couldn't Ada
> apps not use a dll? I put *all* of the GNARL code (700 kB of .o files)
> in one 250 kB dll and link all apps against that. This is a really good
> way of avoiding those bloated executables we see otherwise.

Of course you realize that unless you have other applications running
simultaniously on the system using those DLL's, you havent gained
anything. You've just split your executable into several files. All 
the bytes are still there.

I suppose it might save a few K of disk space, but with 1 gigabyte
harddrives coming with most PC's these days, I certainly don't care
about a couple hundred K of disk space. I could clean out several
hundred times that just by deleting the files in my web browser's
temp directory.

> PS. My newsfeed seems to be broken, so please send a copy of any
>     follow-ups to geert@sun3.iaf.nl.
(done)
-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT Executables: How low can you go?

[Robert Dewar]

T.E.D says

"Of course you realize that unless you have other applications running
simultaniously on the system using those DLL's, you havent gained
anything. You've just split your executable into several files. All
the bytes are still there."

That completely misses the biggest value of DLL's, which is that they
stay loaded as you load subsequent applications. Suppose you have a
2 meg DLL and 30 successive small executables that are loaded. This
will be MUCH more efficient than loading 30 successive 2 meg executables.
DLL's are useful in improving performance even if there is never a case
of simultaneous use.

Re: GNAT Executables: How low can you go?

[Geert Bosch]

On Tue, 16 Apr 1996, Theodore E. Dennison wrote:
> Of course you realize that unless you have other applications running
> simultaniously on the system using those DLL's, you havent gained
> anything. You've just split your executable into several files. All 
> the bytes are still there.

I didn't expect to have to defend why small executables are an advantage,
but I'll try to list some reasons:

 *  Disk space: typical combined savings of using dynamic linking with
    the GNAT RTL, using LINK386 instead of ld and using compression are
    are in the 100-350 kB per executable.  I've got 95 GNAT
    executables, which is good for a saving of 10 - 30 MB. (The 250 kB
    of the DLL doesn't really matter.) So, you don't save a few kB, but
    you'll save MB's. (Even with just 10 executables you might save a
    few MB. 

 *  I don't want my utility to be 10x as big as one written in C
    (Most C programmers use the emx DLL's) 
    If I wrote a bunch of Unix-like commands for OS/2 using Ada and
    they would be 100-200kB each, nobody would use my Unix utilities.
    On the other hand, if they would be 10-20kB each, but you'd need
    the 250 kB GNAT RTL everybody would think that would be reasonable,
    esp. when you explain that DLL is the emxlibc equivalent for Ada.

    So, not being able to create tiny executables hinders the acceptance
    of Ada as a language for small programs. 
     
    Most people who don't know Ada, associate Ada with an old, large
    bloated programming language which can only be used to write large
    and boring applications which manifest themselves as bloated
    executables.  When my little utilities are 100-200 kB each, I don't
    have the slighest chance of getting the language (or the
    applications produced by it) accepted: I'd only reconfirm the
    perception of Ada as large and bloated.

    I know these are not purely technical reasons, but people don't
    just at technical issues. When an Ada program is 10 times as 
    large as a C program, people will expect the Ada program to be
    10 times as slow. 
    
 *  In practise, on multitasking systems there will be many applications
    using the same DLL's. If only the GNAT system with all utilities
    would have been dynamically linked, this would save a lot of disk
    space and memory space when you're using emxload.

 *  It is much easier to upgrade/improve the RTL without having to
    rebuild the world. Of course measures need to be taken to ensure
    that the interface doesn't change. For the RTL this shouldn't be
    much of a problem.
    
Actually this last point was the reason for me to try to dynamically
linke the RTL. That way I could easily switch between the standard
implementation and my (still experimental) RTL using garbage collection.

Regards,
   Geert

E-Mail: geert@sun3.iaf.nl     *** As far as we know, there have not been ***
 Phone: +31-53-4303054        ** any undetected failures in our software. **

Re: GNAT Executables: How low can you go?

[Michael F Brenner]

There is no need to justify tiny executables, 140K is a Bloated hello-world.
Would it be possible to post the commands you used to build the DLL so we
could all have tiny executables?

Re: GNAT Executables: How low can you go?

[Cordes MJ]

: This is better...
: ~~~~~~~~~~~~~~~~~
: Using GNAT v3.01 for OS/2 and default compilation, but with optimizations
: on and checks suppressed resulted in an executable of 114 kB which ran about
: 3 times as slow as the C version. Now with some tweaking the source has 
: changed a little (about 20 lines were modified) and now the code is
: just 15-20% slower than the C version which is not bad considering the
: extra robustness and safety. 

Be carefull - "with optimizations on and checks suppressed" does not
lend itself to considerations of extra robustness and safety. Unless,
of course, you were refering to extra robustness and safety in C ;)   
: slices, exception handlers, discriminated records containing

: Regards,
:    Geert Bosch
: -- 
: E-Mail: geert@sun3.iaf.nl     *** As far as we know, there have not been ***
:  Phone: +31-53-4303054        ** any undetected failures in our software. **

Re: GNAT Executables: How low can you go?

[Theodore E. Dennison]

Robert Dewar wrote:
> 
> T.E.D says
> 
> "Of course you realize that unless you have other applications running
> simultaniously on the system using those DLL's, you havent gained
> anything. You've just split your executable into several files. All
> the bytes are still there."
> 
> That completely misses the biggest value of DLL's, which is that they
> stay loaded as you load subsequent applications. Suppose you have a
> 2 meg DLL and 30 successive small executables that are loaded. This
> will be MUCH more efficient than loading 30 successive 2 meg executables.
> DLL's are useful in improving performance even if there is never a case
> of simultaneous use.

Well....actually no, that doesn't miss that value. If you read the
text you quoted, it says, "...unless you have other applications running
simultaniously on the system using those DLL's..."




-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT Executables: How low can you go?

[Theodore E. Dennison]

Geert Bosch wrote:
> 
> On Tue, 16 Apr 1996, Theodore E. Dennison wrote:
> > Of course you realize that unless you have other applications running
> > simultaniously on the system using those DLL's, you havent gained
> > anything. You've just split your executable into several files. All
> > the bytes are still there.

>I didn't expect to have to defend why small executables are an 
>advantage, but I'll try to list some reasons:

I think you misunderstand me. I'm not saying small /= good. I'm 
just saying:
  o  if your DLL isn't reused, you have gained nothing
  o  there are WAY better things to worry about (on a PC) than 
     executable size.

>  *  Disk space: typical combined savings of using dynamic linking with
>     the GNAT RTL, using LINK386 instead of ld and using compression are
>     are in the 100-350 kB per executable.  I've got 95 GNAT
>     executables, which is good for a saving of 10 - 30 MB. (The 250 kB

OK. So your "extreme case" leaves me with a situation where the sum 
total of the size of my exectuables takes up about 3% of my typical
1 Gig hard disk. I'm not impressed. Again, I'll bet my "temp" 
directory for Webexplorer has more than 30 MB of files in it.

>  *  I don't want my utility to be 10x as big as one written in C
>     (Most C programmers use the emx DLL's)

If we  were talking embedded system, fine. But we're talking OS/2 
systems here. OS/2 platforms are PCs, which these days come with 
oodles of hard disk space. In such an environment, executable size
just isn't a real concern. I want programs to be robust, not squeezed.

>     If I wrote a bunch of Unix-like commands for OS/2 using Ada and
>     they would be 100-200kB each, nobody would use my Unix utilities.
>     On the other hand, if they would be 10-20kB each, but you'd need
>     the 250 kB GNAT RTL everybody would think that would be reasonable,

Actually, I'd bet you are wrong here. I personally HATE getting 
utilities, only to discover that they won't work because they are
missing some RTL. I'd much rather get a stand-alone application, 
especially when we are talking unix-like utilities which are typically
NOT run simultaniously. It really annoys me when I have to fuss with 
some stupid DLL that is only used by this ONE program I have.

>     executables.  When my little utilities are 100-200 kB each, I don't
>     have the slighest chance of getting the language (or the
>     applications produced by it) accepted: I'd only reconfirm the
>     perception of Ada as large and bloated.

So what you are saying is this is a marketing issue?

Again, I don't believe you here. I don't bat an eylash at any
executable less than one MEG. If someone raises nonsense such as
executable size as argument against Ada, you're just wasting your 
time trying to placate them. They will just keep shifting their 
argument, becuase the real problem isn't executable size, its that
its not C. Don't even bother.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT Executables: How low can you go?

[Theodore E. Dennison]

Michael F Brenner wrote:
> 
> There is no need to justify tiny executables, 140K is a Bloated hello-world.

Its still 140K, just in two different files.

(sigh) 

I guess I'm alone in thinking this is just "re-arranging the deck 
chairs"?

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT Executables: How low can you go?

[Geert Bosch]

Michael F Brenner (mfb@mbunix.mitre.org) wrote:
`` There is no need to justify tiny executables, 140K is a Bloated hello-world.
   Would it be possible to post the commands you used to build the DLL so we
   could all have tiny executables? ''

I would have posted them already, but my PC is in repair at the moment.
Hopefully I'll be able to post a complete description, including some make
scripts, in the weekend.

   Greetings,
      Geert
-- 
E-Mail: geert@sun3.iaf.nl     *** As far as we know, there have not been ***
 Phone: +31-53-4303054        ** any undetected failures in our software. **

Re: GNAT Executables: How low can you go?

[John Howard]

On Thu, 18 Apr 1996, Theodore E. Dennison wrote:
> Robert Dewar wrote:
> >
> > T.E.D says
> >
> > "Of course you realize that unless you have other applications running
> > simultaniously on the system using those DLL's, you havent gained
> > anything. You've just split your executable into several files. All
> > the bytes are still there."
> >
> > That completely misses the biggest value of DLL's, which is that they
> > stay loaded as you load subsequent applications. Suppose you have a
> > 2 meg DLL and 30 successive small executables that are loaded. This
> > will be MUCH more efficient than loading 30 successive 2 meg executables.
> > DLL's are useful in improving performance even if there is never a case
> > of simultaneous use.
>
> Well....actually no, that doesn't miss that value. If you read the
> text you quoted, it says, "...unless you have other applications running
> simultaniously on the system using those DLL's..."
> --
> T.E.D.

You can gain by saving on time to load the program and DLL's.  The 
decoding and expansion of a compressed file in memory might beat the time 
it takes to access a slow I/O device for the uncompressed original file.

Executables typically are loaded once per session.  Comparing the single 
load time of the uncompressed form against the single load time of the 
compressed form will accurately indicate if an executable should be 
distributed in compressed form.  DLL's can be either reloaded or shared 
by multiple processes.  Complications come from not being able to predict 
or control the cost of reloading a DLL.

Generally, large DLL's will be compressed to save storage space at the 
expense of adding a decoding time component to the load time.  A smaller 
uncompressed file is quicker to load during load time.  A compressed file 
may or may not be quicker to load during load time -- you have to add in 
the decode time to know.  Do not repeatedly decode the same DLL unless it 
is unavoidable.

For example, a main program can repeatedly yet rarely demand a resource 
DLL which was loaded earlier and given a high priority by the operating 
system but later unloaded due to becoming a low priority.  Sometimes a 
programmer is allowed enough control to have the operating system lock 
their DLL in a memory space so that only a single decode is necessary.

------------------------------------------------------------------------
-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --
--                                             -- Keramos             --
------------------------------------------------------------------------
Psalm 22:30-31

Re: GNAT Executables: How low can you go?

[Robert Dewar]

T.E.D. says (replying to me)

"> That completely misses the biggest value of DLL's, which is that they
> stay loaded as you load subsequent applications. Suppose you have a
> 2 meg DLL and 30 successive small executables that are loaded. This
> will be MUCH more efficient than loading 30 successive 2 meg executables.
> DLL's are useful in improving performance even if there is never a case
> of simultaneous use.

Well....actually no, that doesn't miss that value. If you read the
text you quoted, it says, "...unless you have other applications running
simultaniously on the system using those DLL's...""

Ted, you missed it again!!!!

The point is that DLL's are valuable even if the applications do NOT
run simultaneously. Read my paragraph again, the key word is successive,
i.e. non-simultaneous!

Re: GNAT Executables: How low can you go?

[Robert Dewar]

T.E.D. says

"Actually, I'd bet you are wrong here. I personally HATE getting
utilities, only to discover that they won't work because they are
missing some RTL. I'd much rather get a stand-alone application,
especially when we are talking unix-like utilities which are typically
NOT run simultaniously. It really annoys me when I have to fuss with
some stupid DLL that is only used by this ONE program I have."

I strongly disagree. It is perfectly reasonable to distribute a program
as an executable and set of DLL's. Of course the installation procedure
in such a case should arrange to handle the installation of the DLL's
conveniently.

Ted, I really think you underestimtae the performance value of DLL's.
For example, it is VERY valuable that EPM uses an underlying DLL.

Re: GNAT Executables: How low can you go?

[Robert Dewar]

T.E.D. said

"That wasn't my impression. My impression (I think supported by the
thread title of "How low can you go?") was that we were talking about
space for space's sake."

Exactly wrong, space for PERFORMANCE's sake, not space for SPACES's sake.
disk is cheap and getting cheaper all the time, people's time is more
expensive!

Re: GNAT Executables: How low can you go?

[Geert Bosch]

Theodore E. Dennison (dennison@escmail.orl.mmc.com) wrote:
`` I guess I'm alone in thinking this is just "re-arranging the deck 
   chairs"? ''

Maybe. Please note that memory requirements drop dramatically for the second
and later apps that run concurrently. Or do you say, typical modern systems
have so much RAM and such low paging rates that it doesn't matter if an
application needs 200 kB RAM instead of 20? 

My impression (I've not found a way of precisely measuring this yet) is
that the stripped down executables have a much reduces start time.
Because loaded DLL's are only discarded when there is no free RAM left
and apps that terminate result in free memory, there's a good chance
that a subsequently loaded executable can reuse the already loaded
DLL. In my test application it would be the difference between loading
116 kB or 12 kB. 

Maybe you're thinking in terms of large applications and if that's the case
I agree with you. For a 3 MB executable it won't matter much if
it could be 2.5 MB when linked dynamically. My point, which I think is valid,
is that for small programs the factor 10 increase of program size has
a negative impact on performance and disk storage. 

For small applications that use relatively much library code, like GUI
based programs, the situation is totally different.  If the Sun-3
system I use right now wouldn't use dynamically linked libraries almost
everywhere, it would be impossible to have 3 users on the system
running a total of 30 X-Windows applications. I've used a couple of X
applications that had a statically linked GUI library for some time
(chimera and xmh for example) but after recompiling them using
dynamically linked libraries they cause much less paging. I do not know
any modern Unix systems that use a statically linked libc for
applications other than those needed for single user mode (mount, sh
etc).

Also notice that GNAT requires dynamically linked libraries by
default:  the EMX run-time system uses DLL's and all OS/2 API's are
implemented as DLL's. On the platform I was talking about (OS/2) DLL's
are used all over the place and I can find no good reason for regular
GNAT applications to be partially statically linked, resulting in a
slower and larger program than possible.

When you still think that dynamic linking is just re-aranging the desk
chairs, I'll try to find some pointers to relevant literature for you.
I don't think it's very useful to continue this discussing such a
well-established technology as dynamic linking in comp.lang.ada, when
your objections against dynamic linking are general, not just related
to implementations of Ada.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl     *** As far as we know, there have not been ***
 Phone: +31-53-4303054        ** any undetected failures in our software. **

Re: GNAT Executables: How low can you go?

[Robert Dewar]

T.E.D. says

"I guess I'm alone in thinking this is just "re-arranging the deck
chairs"?"

Well you may not be alone, there may be others who share this incorrect
view. Putting the Ada runtime into a DLL will generally improve
system performance if you are running Ada programs, whether or not
they are run simultaneously. It is an excellent idea to put the Ada
library into a DLL. The SGI version has been distributed this way for
a while, and we definitely plan to make this kind of distribution
standard, since it will result in smaller executables, faster execution
(since the RTL object code does not have to be linked and copied),
and faster execution (since the RTL object code is more likely to be
preloaded in memory).

It's a win all round.

Re: GNAT Executables: How low can you go?

[Robert Dewar]

John Howard replied to T.E.D.'s comments on DLL's:

"You can gain by saving on time to load the program and DLL's.  The
decoding and expansion of a compressed file in memory might beat the time
it takes to access a slow I/O device for the uncompressed original file."

OOPS! This is mixing up two threads. Let's separate them clearly:

1. The issue of compressing exe's and dll's

2. The issue of creating the dll's in the first place (that is what T.E.D's
	message was addressing.

What you said is right, but is not relevant to Ted's point.

Re: GNAT Executables: How low can you go?

[Norman H. Cohen]

In article <317688E9.2781E494@escmail.orl.mmc.com>,
"Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes: 

|> If we  were talking embedded system, fine. But we're talking OS/2
|> systems here. OS/2 platforms are PCs, which these days come with
|> oodles of hard disk space. In such an environment, executable size
|> just isn't a real concern. I want programs to be robust, not squeezed.

1. That's a very narrow view of the world.  Don't forget about small,
   portable PDA-like or tablet-based devices, with much more constrained
   hard disk space.

2. What does robustness have to do with it?  We're not talking about
   programmers cutting corners to save space, but about a compiler doing
   its job well.

3. You describe a typical end-user environment, in which executables
   consume 3% of your disk space.  However, in a development environment,
   there are projects that fill up disks with executables, requiring the
   expenditure of more money to buy more disks.  (Indeed, as I write
   this, my OS/2 machine is busy doing a low-level format of the new
   2.25GB disk I installed yesterday, for just this reason.) If you are
   planning a large project with thousands of files, a compiler producing
   executables ten times as large as necessary costs real money.

There are other considerations in favor of compact code as well.  To the
extent that the size of the executable reflects the size of the object
code itself, more compact code means faster loading and fewer I-cache
misses, resulting in faster execution.  For an Ada-to-Java-bytecode
compiler, more compact code means faster transmission of an applet over
the web.

|> So what you are saying is this is a marketing issue?
|>
|> Again, I don't believe you here. I don't bat an eylash at any
|> executable less than one MEG. If someone raises nonsense such as
|> executable size as argument against Ada, you're just wasting your
|> time trying to placate them. They will just keep shifting their
|> argument, becuase the real problem isn't executable size, its that
|> its not C. Don't even bother.

This is nonsense.  Someone who comes to the table without any prejudices
about Ada is sure to walk away with a negative impression if he sees
executables an order of magnitude larger than those produced using C.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: GNAT Executables: How low can you go?

[Fergus Henderson]

Geert Bosch <geert@fozzie.sun3.iaf.nl> writes:

>I didn't expect to have to defend why small executables are an advantage,
>but I'll try to list some reasons:

You missed one: using shared libraries can significantly reduce
turn-around time during development.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: GNAT Executables: How low can you go?

[Theodore E. Dennison]

Robert Dewar wrote:
> 
> Ted, you missed it again!!!!
> 
> The point is that DLL's are valuable even if the applications do NOT
> run simultaneously. Read my paragraph again, the key word is successive,
> i.e. non-simultaneous!

Ahhh.

So you are saying that when all its applications terminate, the DLL 
isn't nessecarily unloaded? That's clever. Although in practice, I'd
bet it gets unloaded or swapped out pretty quickly. You can't just
keep every DLL that ever got opened since the machine was booted in
memory forever; you'd run out of memory space pretty quickly.

However, this would make DLLs a very good approach for running a 
series of executables that all use a lot of the same routines (eg:
the "unix-like" commands that were mentioned previously in this thread,
with the GNAT runtime in a DLL).

I sense an "Emily Latella" comming on.
(What's all this I hear about "Firing the Handicapped"?)
-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT Executables: How low can you go?

[Theodore E. Dennison]

Norman H. Cohen wrote:
> 
> In article <317688E9.2781E494@escmail.orl.mmc.com>,
> "Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes:
> 
> 1. That's a very narrow view of the world.  Don't forget about small,
>    portable PDA-like or tablet-based devices, with much more constrained
>    hard disk space.

Fair enough. I don't know how many OS/2 "PDA-like or tablet-based 
devices" there are out there, but they would have this concern.


> 2. What does robustness have to do with it?  We're not talking about
>    programmers cutting corners to save space, but about a compiler 
>    doing its job well.

That wasn't my impression. My impression (I think supported by the
thread title of "How low can you go?") was that we were talking about
space for space's sake.

> 3. You describe a typical end-user environment, in which executables
>    consume 3% of your disk space.  However, in a development environment,
>    there are projects that fill up disks with executables, requiring the

For a development system, you will obviously have to have a 
signifigantly larger amout of hard-drive space than your target 
platform. You'll need that just to support the compilers, gui builders,
bitmap editors, etc. I think the argument scales.

> This is nonsense.  Someone who comes to the table without any prejudices
> about Ada is sure to walk away with a negative impression if he sees
> executables an order of magnitude larger than those produced using C.

Typically, when I go looking for a utility for my OS/2 system on the
net, and I find two that preport to do the job (based on a comparison
of their README's, or whatever), I compare their sizes and download
the LARGER one. The reasoning here is that the larger one is very 
likely the more fully-featured and/or the more mature of the two. 

As to the "Hello World" issue: Anyone who TRULY had no prejudices
wouldn't give a s**t how small the compiler makes an program that
does nothing. This is the argumentative equivalent of a division by
zero. (Anyone with a good math background knows that I can prove 5=7
if you'll let me divide by 0). Their real concern will be how fast,
useful, and reliable the application is.

This is an issue created by anti-Ada folks because it is one of the
few points where they can point out an disadvantage to Ada (using most
compilers). You are never going to convince them Ada is ok by making
"Hello World" small. They will just change their argument (or more
likely, pretend its still large).

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT Executables: How low can you go?

[Al Christians]

In <317688E9.2781E494@escmail.orl.mmc.com> "Theodore E. Dennison"      

>Again, I don't believe you here. I don't bat an eylash at any
>executable less than one MEG. If someone raises nonsense such as
>executable size as argument against Ada, you're just wasting your 
>time trying to placate them. They will just keep shifting their 
>argument, becuase the real problem isn't executable size, its that
>its not C. Don't even bother.

I have worked in situations with networked DOS PC's in which the
executable sizes are very important.  Some systems are too big to be a
single executable, so client PC's must load executables repeatedly as
the users switch from task to task.  Even compact executables represent
a large portion of the load on the network, which is often close to
capacity.  The difference between compact and bloated executables is
critical in these cases.


Al

Re: GNAT Executables: How low can you go?

[Theodore E. Dennison]

Al Christians wrote:
> 
> I have worked in situations with networked DOS PC's in which the
> executable sizes are very important.  Some systems are too big to be a

We're not talking DOS, we're talking OS/2.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT Executables: How low can you go?

[Richard A. O'Keefe]

"Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes:

>Michael F Brenner wrote:
>> 
>> There is no need to justify tiny executables, 140K is a Bloated hello-world.

>Its still 140K, just in two different files.


Wrong.  Suppose the library is 120 k and the application, minus library,
is 20k.

- static linking:
    you get 140k in your program AND YOU STILL HAVE THE LIBRARY
    so you have one 120k file and one 140k file

- dynamic linking
    you have one one 120k file and one 20k file.

The model I have here is someone developing on a UNIX box; I can't throw
away the original copy of the (statically linked) library just because I
have compiled one program!  Come to think of it, the same is true with
DOS compilers:  just because I've compiled one program doesn't mean I can
throw the library away.

1.  Development time.
    Dynamic linking saves space _even with only one program_.
    (In this example, 140k -vs- 260k.)

2.  Shipping.
    Any dynamic library that doesn't come standard with the operating
    system has to be shipped with the program that uses it.
    Shipping the DLL with the EXE may take _more_ space than shipping
    the statically linked version, because the DLL includes things
    that this particular EXE may not need.

    However, if the shipping package includes several applications using
    the same DLL, only one copy is needed, and it's really quite common
    to have several applications in one package.  (DOS example:  command
    line compiler, IDE compiler, linker.)

3.  Installation.
    The user only has to install *one* copy of the DLL; the installation
    process has to recognise whether the DLL has already been installed.

4.  Run time.
    The DLL will be loaded only once no matter how many applications are
    using it (UNIX "shared" libraries), and may, depending on the operating
    system, be kept around for a little while after the last application
    using it has quit so that it doesn't need reloading (like the old UNIX
    "save text" bit).


-- 
Abigail Ruth, born 8 April 1996, 7lbs, wonderful!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: GNAT Executables: How low can you go?

[Geert Bosch]

Michael F Brenner (mfb@mbunix.mitre.org) wrote:
`` There is no need to justify tiny executables, 140K is a Bloated
   hello-world.  Would it be possible to post the commands you used to
   build the DLL so we could all have tiny executables? ''

OK, it has been delayed a little because I couldn't work on it last
week, but I've tried to reproduce all commands I had used to generate
the DLL and the applications. That part turned out to be harder than
I thought, and at first there were also problems because of bugs in the
emximp and emxexp utilities.  For the GNAT examples generated by
/emx/gnat/examples/examples.cmd the old size is 800 kB, the new
soze is 28 kB for the examples, plus 240 kB for the DLL.

I put the command to generate the DLL in a makefile. Because of the
many e-mails I got, I thought it would be appropriate to post the files
to comp.lang.ada. To prevent problems with the tabs etc. in the makefiles,
I zipped and uuencoded them. The total data is just 150 lines, I hope
nobody has problems with this small binary.

Let me here of any success or problems you have with the
software. Note that only very little testing has been done:
I've not done any multitasking tests and I don't have by any means a
standard emx installation, so there might be installation problems.

Regards,
   Geert

begin 640 gnatdll.zip
<uuencoded_portion_removed>
;<"YC;6102P4&      D "0#U 0  C1<     
 
end
-- 
E-Mail: geert@sun3.iaf.nl     *** As far as we know, there have not been ***
 Phone: +31-53-4303054        ** any undetected failures in our software. **

Re: GNAT Executables: How low can you go?

[Theodore E. Dennison]

Richard A. O'Keefe wrote:
> - static linking:
>     you get 140k in your program AND YOU STILL HAVE THE LIBRARY
>     so you have one 120k file and one 140k file
> 
> - dynamic linking
>     you have one one 120k file and one 20k file.
> 


OK. You definitely have a point there...

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT Executables: How low can you go?

[mjp]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>4.  Run time.
>    The DLL will be loaded only once no matter how many applications are
>    using it (UNIX "shared" libraries), and may, depending on the operating
>    system, be kept around for a little while after the last application
>    using it has quit so that it doesn't need reloading (like the old UNIX
>    "save text" bit).

Also remember that although the DLL may be 120K, a decent
operating system will only load those pages actually needed by your
program (and other programs sharing the library) into paged
real memory.

My complaint about DLLs, is the poor way they are installed by
most off the shelf products. E.g. Microsoft office. It asks
where you want to put Microsoft office and I say my extra
drive D:, I niavely assume thats where it put it. But it put
the DLL on my boot E: drive, so when I come along to install a
new rev of the os, Easiest by reformating the e: drive it will
break M$ office. I discovered this "feature" when I had a disc
corruption on my boot drive and had to reinstall the OS.

--
On Australia is prohibited from redistributing this document in any way
Dr Michael Pilling                         Phone: +61 8 259 7017
DSTO ITD/SE 171 Labs                       Fax: +61 8 259 5589
PO Box 1500, Salisbury SA 5108, Australia  Michael.Pilling@dsto.defence.gov.au