huge executable??

huge executable??

[David Dousette]

I'm using the OS/2 version of GNAT 3.12p, and as I'm still new to Ada, I
thought I'd take a stab at a "Hello World!" program, without my handy
book... got it on the second try, stupid semicolon... anyway, my
question was why is the executable so large?  Here's the code:

--------------------------------------------------------------------
with Ada.Text_IO;

procedure Hello is

begin
    Ada.Text_IO.Put("Hello World!");
    Ada.Text_IO.Flush;
end Hello;
--------------------------------------------------------------------

I compiled it with the command line "gnatmake hello.adb" and the
executable generated was a little over 250,000 bytes!  I ran it through
"emxbind -s" (as suggested by R. Dewar) to strip out all the debugging
stuff, but it's still 126,000 bytes.... why?  I wrote a similar program
in C, and it was less than 5,000 bytes... why is the .EXE produced by
Ada so much bigger?  The executable runs fine, and I have plenty of hard
drive space... I was just curious.

Thanks,
David

Re: huge executable??

[Gautier]

David Dousette:

> I compiled it with the command line "gnatmake hello.adb" and the
> executable generated was a little over 250,000 bytes!  I ran it through
> "emxbind -s" (as suggested by R. Dewar) to strip out all the debugging
> stuff, but it's still 126,000 bytes.... why?  I wrote a similar program
> in C, and it was less than 5,000 bytes... why is the .EXE produced by
> Ada so much bigger?  The executable runs fine, and I have plenty of hard
> drive space... I was just curious.

With wich compiler did you compile your C program ? The 5,000 bytes seem
rather from some 16-bit Turbo C. With GCC it would be (logarithmically)
nearer to 126,000 bytes...

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: huge executable??

[David Dousette]

I used Pacific C for DOS... seems like I did one a while back in Watcom 11,
too, and it wasn't much bigger or smaller.  I didn't think to try it with
GCC... but what is it about GCC and GNAT that causes that much of an
increase?  Just the static linking?  I'm not sure what Pacific C or Watcom
used, and GNAT is the only Ada compiler I've messed with... I guess I could
download the Aonix compiler for Win98 and see if I get similar results out of
it on my other machine.

Gautier wrote:

> With wich compiler did you compile your C program ? The 5,000 bytes seem
> rather from some 16-bit Turbo C. With GCC it would be (logarithmically)
> nearer to 126,000 bytes...
>
> _____________________________________________
> Gautier  --  http://members.xoom.com/gdemont/

Re: huge executable??

[Gautier]

David Dousette wrote:
> 
> I used Pacific C for DOS... seems like I did one a while back in Watcom 11,
> too, and it wasn't much bigger or smaller.  I didn't think to try it with
> GCC... but what is it about GCC and GNAT that causes that much of an
> increase?  Just the static linking? 

32-bit, Unix-like environment, a rich run-time library; all that combined
with a linker that doesn't trim unused code. It means that even if you are using
1-2 procedures in some package, it will put the whole package, and of course
if one of the unused procedures refers to another package unused by others,
it will link also that one and so on...

But be reassured: the .exe won't grow so much as your program.
The size you see is the "b" in the "size(x)=ax+b" function where
x is you source code - I'm simplifying of course...

If you absolutely want a small exe, pass it through UPX:
  http://wildsau.idv.uni-linz.ac.at/mfx/upx.html

The Janus compiler seems to reduce code size at best; they have
a smart linker too: http://www.rrsoftware.com/

And GNAT can compensate the lack of smart linker with the "gnatelim"
tool that does removal at compilation stage (doesn't it ?). But it can mean
recompiling everything for different projects since the .o files
would be incomplete.

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: huge executable??

[tmoran]

> why is the .EXE produced by Ada so much bigger?
  It's not Ada, it's the particular compiler's run-time for the
particular OS.  Your Hello program compiled to 67K with a different
compiler.  Dropping the "with ada.text_io" and raising an unhandled
"hello_world:exception" instead, that went down to 37K.  Looking at
some old DOS .com programs in Ada, I find a 100 line one that
HTML-izes a text file and compiles to 19K.  The same program,
compiled to run under 32 bit Windows, is now 73K.
  The more important question is, is size a problem with real
programs that do something substantial.

Re: huge executable??

[Roger Barnett]

In article: <9EET4.760$pN4.423580@news.pacbell.net>  tmoran@bix.com writes:
> 
>[snip]
>   The more important question is, is size a problem with real
> programs that do something substantial.


I've just loaded down one of the "new generation" Java IDE tools
(anyone else notice that the generations are getting shorter, or is
it just me getting older ?) for Win32. The installation notes state
that the minimum memory requirement to run the thing is 128Mb, 
with 256Mb recommended.


Hmm.


-- 
Roger Barnett

Re: huge executable??

[DELCOURT J�r�me]

tmoran@bix.com wrote:
> 
> > why is the .EXE produced by Ada so much bigger?
>   It's not Ada, it's the particular compiler's run-time for the
> particular OS.  Your Hello program compiled to 67K with a different
> compiler.  Dropping the "with ada.text_io" and raising an unhandled
> "hello_world:exception" instead, that went down to 37K.  Looking at
> some old DOS .com programs in Ada, I find a 100 line one that
> HTML-izes a text file and compiles to 19K.  The same program,
> compiled to run under 32 bit Windows, is now 73K.
>   The more important question is, is size a problem with real
> programs that do something substantial.

I think that a reduced executable size is important, since that
allows a better use of the CPU cache memory, so that could improve
the speed of the program.

Concerning that problem, I suspect that, with GNAT, there is not
a good elimination of the unused code.

Sincerely, Jerome Delcourt

Re: huge executable??

[Gisle S�lensminde]

In article <3920DA5B.2F56@club-internet.fr>, DELCOURT J�r�me wrote:
>tmoran@bix.com wrote:
>> 
>> > why is the .EXE produced by Ada so much bigger?
>>   It's not Ada, it's the particular compiler's run-time for the
>> particular OS.  Your Hello program compiled to 67K with a different
>> compiler.  Dropping the "with ada.text_io" and raising an unhandled
>> "hello_world:exception" instead, that went down to 37K.  Looking at
>> some old DOS .com programs in Ada, I find a 100 line one that
>> HTML-izes a text file and compiles to 19K.  The same program,
>> compiled to run under 32 bit Windows, is now 73K.
>>   The more important question is, is size a problem with real
>> programs that do something substantial.

>
>I think that a reduced executable size is important, since that
>allows a better use of the CPU cache memory, so that could improve
>the speed of the program.

Not quite correct. If some part of the program is unused it will
quickly be flushed out of instruction cache and remain outside,
if ever comes there. It will affect load lime and harddisk space,
but not instruction cache.

Instruction cache is important when you try to unroll code. 
If the codesize no longer fit instruction cache, you will probably 
see a significant performance hit. If you have code doing computational 
work, that part of the code should fit the instruction cache, 
but that have nothing to do with size of the executables on
your hard drive. 

>
>Concerning that problem, I suspect that, with GNAT, there is not
>a good elimination of the unused code.
>
>Sincerely, Jerome Delcourt


-- 
--
Gisle S�lensminde ( gisle@ii.uib.no )   

ln -s /dev/null ~/.netscape/cookies

Re: huge executable??

[Robert Dewar]

In article <3920DA5B.2F56@club-internet.fr>,
  sikander@club-internet.fr wrote:

> I think that a reduced executable size is important, since
> that allows a better use of the CPU cache memory, so that
> could improve the speed of the program.

You are assuming that size of executable is directly related
to the working set in cache. There is no reason to make this
connection. Indeed it is obvious for example that static vs
dynamic linking, which has no effect on cache usage to speak
of, has a big effect on executable size.
>
> Concerning that problem, I suspect that, with GNAT, there is
> not a good elimination of the unused code.

Elimination of unused code will most certainly reduce executable
size but it won't help one bit in reducing cache pressure, since
obviously unused code never gets into the cache during
execution.

Similarly the presence or absence of debugging information has
a huge effect on executable size, but the debugging info is not
even loaded into memory, let alone the cache, if you are not
using the debugger.

I think to a first approximation, executable size of the null
program, measuring the base size of the run-time, has nothing
at all to do with execution efficiency. It may well have
something to do with functionality (e.g. a fancy exception
handler that prints out tracebacks will clearly take more space,
but there is no reason to worry about this additional space).

Basically the issue here boils down to disk costs alone. Seeing
as 128K bytes is approximately $0.004 worth of disk space, I
don't see this as a big worry these days :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: huge executable??

[Lutz Donnerhacke]

* Robert Dewar wrote:
>I think to a first approximation, executable size of the null
>program, measuring the base size of the run-time, has nothing
>at all to do with execution efficiency. It may well have
>something to do with functionality (e.g. a fancy exception
>handler that prints out tracebacks will clearly take more space,
>but there is no reason to worry about this additional space).
>
>Basically the issue here boils down to disk costs alone. Seeing
>as 128K bytes is approximately $0.004 worth of disk space, I
>don't see this as a big worry these days :-)

I'm developing for Systems with 8 MB RAM and 64 kb RAM.

Re: huge executable??

[Robert Dewar]

In article <slrn8i10hn.4ua.lutz@taranis.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> I'm developing for Systems with 8 MB RAM and 64 kb RAM.

8MB RAM is a perfectly reasonable design point, and the overhead
of 128K or so of standard runtime stuff is reasonable.

If you are developing for 64K byte machines, you have a VERY
different situation on your hands. Clearly here you are talking
about embedded systems, and in such systems, you very rarely
want any significant runtime code. The best alternative using
GNAT here is to use GNORT, which completely eliminates the
runtime completely. If on the other hand, you are saying that
you have 64K of data, but more code space, then again there
may be no problem.

Did you perhaps mean to say 8MB ROM and 64K RAM (that would
make a whole lot more sense ...)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: huge executable??

[Lutz Donnerhacke]

* Robert Dewar wrote:
>Did you perhaps mean to say 8MB ROM and 64K RAM (that would
>make a whole lot more sense ...)

C64 and NeXT Station. Just for fun at home. Currently there is a C64-BasicV2
based compiler for a subset of Ada (a single procedure with nested
procedures, restricted types) in development.

Re: huge executable??

[tmoran]

>C64 and NeXT Station. Just for fun at home. Currently there is a C64-BasicV2
>based compiler for a subset of Ada (a single procedure with nested
>procedures, restricted types) in development.

Then information about a program using Text_IO, compiled targetting:
> I'm using the OS/2 version of GNAT 3.12p, ...
is not likely to be a terribly good predictor.

Re: huge executable??

[Robert Dewar]

In article <slrn8i14hu.51n.lutz@taranis.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> * Robert Dewar wrote:
> >Did you perhaps mean to say 8MB ROM and 64K RAM (that would
> >make a whole lot more sense ...)
>
> C64 and NeXT Station. Just for fun at home. Currently there is
a C64-BasicV2
> based compiler for a subset of Ada (a single procedure with
nested
> procedures, restricted types) in development.
>

You did not answer my question: you said 8MB RAM and 64K RAM.
Did you mean 8MB ROM and 64k RAM?

???


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: huge executable??

[Lutz Donnerhacke]

* Robert Dewar wrote:
>> C64 and NeXT Station. Just for fun at home. Currently there is
>
>You did not answer my question: you said 8MB RAM and 64K RAM.
>Did you mean 8MB ROM and 64k RAM?

No. Two seperate systems to develop for.

Re: huge executable??

[tmoran]

>I'm developing for Systems with 8 MB RAM and 64 kb RAM.
  And running Windows?

Re: huge executable??

[Lutz Donnerhacke]

* tmoran@bix.com wrote:
>>I'm developing for Systems with 8 MB RAM and 64 kb RAM.
>And running Windows?

No. The C64 runs a home brew OS to learn basic technics of compiler design,
OS design, multitasking and high level abstractions using Ada95 types and
exceptions. The NeXT Station should be used for normal work but is scheduled
for running the same OS.

I do not buy a new system every six month only to run some piece of brain
dead software. My production systems usually have a 386DX/40 with 16 MB RAM
and 200 MB HDD running SQL-Server over large DB and multiple processing
instances. Works find until I tried to update to a new feature.

Re: huge executable??

[Geoff Bull]

Lutz Donnerhacke wrote:
> 
> * Robert Dewar wrote:

> >Basically the issue here boils down to disk costs alone. Seeing
> >as 128K bytes is approximately $0.004 worth of disk space, I
> >don't see this as a big worry these days :-)
> 
> I'm developing for Systems with 8 MB RAM and 64 kb RAM.

So?

Re: huge executable?? - worry no more

[Tom Hargraves]

I used to worry about the 'unreadability' of machine code, but then those
systems were superceded by 'superior' high-level language implemented
systems, so I wasn't worried anymore.

I used to think that the 'enormous' size of compiled Ada images was
important, but then disk space and processor speed continued to double every
6 months, so I was not worried anymore.

I used to worry about the fallacy of 'industry standard' C, and then
certified 'standard' Ada came along, so I was not worried anymore.

Now Ada 95 incompatibilities with Ada 93 has us discussing whether the
latter is obsolete.
I could be worried, but  Ada 200X will come along, and I won't be worried
anymore.

In my rambling experience, currently Ada is as good as it gets for helping
the engineer produce a quality product. Executable size is a 'lesser issue'
for most Ada projects. If it is an issue, you can compile and link disabling
all that nice Ada checking etc. and end up with a readable 'C/C++' program
(with the same unpredictable behaviour of course!).

I used to worry that in 10 years time, everything I was currently learning
would be obsolete.

My advice is not to worry any more.

Regards,
Unworried Tom.


"Geoff Bull" <geoff@research.canon.com.au> wrote in message
news:392091E9.20999FBE@research.canon.com.au...
> Lutz Donnerhacke wrote:
> >
> > * Robert Dewar wrote:
>
> > >Basically the issue here boils down to disk costs alone. Seeing
> > >as 128K bytes is approximately $0.004 worth of disk space, I
> > >don't see this as a big worry these days :-)
> >
> > I'm developing for Systems with 8 MB RAM and 64 kb RAM.
>
> So?

Re: huge executable?? - worry no more

[Gautier]

Tom Hargraves:

> My advice is not to worry any more.

But one can try to be even happier, can't one ?...

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: huge executable?? - worry no more

[Marin D. Condic]

Tom Hargraves wrote:
> In my rambling experience, currently Ada is as good as it gets for helping
> the engineer produce a quality product. Executable size is a 'lesser issue'
> for most Ada projects. If it is an issue, you can compile and link disabling
> all that nice Ada checking etc. and end up with a readable 'C/C++' program
> (with the same unpredictable behaviour of course!).
> 
Very good points! Other than for embedded computers where there are
limited resouces, people shouldn't get so worried over the size of the
"Hello World" executable. Ultimately, for any significant sized system,
you're going to pay the price anyway. A minimalist C-like runtime means
you are going to have to develop what isn't in the runtime as you begin
to need the features. A larger runtime means more facilities you won't
have to duplicate because someone else already built it for you, but you
sometimes drag along stuff you don't need. If the runtime is sharable,
it minimizes used space, but only for multiple images and you get other
problems along the way by sharing. It all comes down to engineering
tradeoffs. And these days, speed, memory and disk space is so plentiful
relative to the size of the runtime, why not spend time looking for
problems that aren't burried so far in the weeds?

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: huge executable?? - worry no more

[Robert Dewar]

In article <3920fbbd@rsl2.rslnet.net>,
  "Tom Hargraves" <tharg@vtcinet.com> wrote:

> Now Ada 95 incompatibilities with Ada 93 has us discussing
> whether the latter is obsolete.

Well most certainly "the latter" [Ada 93, I think you meant
Ada 83] in your sentence *is* obsolete, but I am not sure
what "incompatibilities" you are talking about. Most certainly
Ada 95 obsoletes Ada 83 in the sense that the Ada 95 replaces
the Ada 83 standard, and Ada technically means Ada 95.

Of course, this does not mean that no one is using Ada 83. Just
as the introduction of the Alpha obsoletes the VAX, but does
not mean there is no one using VAX'es, people are still using
Ada 83, and quite reasonably so. For a large existing project,
you don't go changing compilers and language versions just for
the fun of it and because there are some neat new features.
You do it carefully after an analysis shows that the benefits
make the switch worth while. More and more Ada projects are
in fact making this judgment, but there are still many Ada 83
projects around and will be for a long time.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: huge executable?? - worry no more

[Richard D Riehle]

In article <8frant$q9h$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>make the switch worth while. More and more Ada projects are
>in fact making this judgment, 

    [to upgrade to the Ada 95 standard]

but there are still many Ada 83
>projects around and will be for a long time.

True.  We still received requests for Ada 83 training.  In some cases
this is because there is no Ada 95 compiler for the targeted platform.
Is anyone planning to deploy a production-level compiler for the 1750A?

Richard Riehle
 

Re: huge executable?? - worry no more

[Ken Garlington]

"Richard D Riehle" <laoXhai@ix.netcom.com> wrote in message
news:8g280g$6ij$1@nntp9.atl.mindspring.net...
> Is anyone planning to deploy a production-level compiler for the 1750A?

Tartan actually released a version of their 1750 toolset with a subset of
the Ada 95-unique features implemented, just before they folded. I don't
know if DDC-I has any plans to build on that work -- I suspect not, but you
never know.

Re: huge executable?? - worry no more

[Martin Dowie]

> Now Ada 95 incompatibilities with Ada 93 has us discussing whether the
> latter is obsolete.

i should think Ada93 is one of the most obsolete languages i have ever heard of
;-)

Re: huge executable??

[(null)]

In article <slrn8i10hn.4ua.lutz@taranis.iks-jena.de>,
Lutz Donnerhacke <lutz@iks-jena.de> wrote:
>
>I'm developing for Systems with 8 MB RAM and 64 kb RAM.

Shouldn't be a problem.  In a previous life I developed programs
with gnat 3.10 (the plain old public release) targeted to the i386
that fit into 8KB executable.  You just have to be _very_ picky
about what you let the linker bring in.

-- 
=======================================================================
 Life is short.                  | Craig Spannring 
      Bike hard, ski fast.       | cts@internetcds.com
 --------------------------------+------------------------------------

Re: huge executable??

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Elimination of unused code will most certainly reduce executable
> size but it won't help one bit in reducing cache pressure, since
> obviously unused code never gets into the cache during
> execution.

What about paging?

- Bob

Re: huge executable??

[Larry Kilgallen]

In article <wccem72tz4n.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes:
> Robert Dewar <robert_dewar@my-deja.com> writes:
> 
>> Elimination of unused code will most certainly reduce executable
>> size but it won't help one bit in reducing cache pressure, since
>> obviously unused code never gets into the cache during
>> execution.
> 
> What about paging?

"Code" that never gets paged in (for execution) has no need to be
paged out.

Mine is a general comment, not based on the original OS/2 problem,
but there seems to be a lot of that going on in this thread.

Re: huge executable??

[Gautier]

Robert A Duff <bobduff@world.std.com>:

> > What about paging?

Larry Kilgallen:

> "Code" that never gets paged in (for execution) has no need to be
> paged out.

But you can have code that is paged in without being ever executed -
it could suffice it is at a small distance from executed code, in the
same memory block. Couldn't it ?...

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: huge executable??

[Larry Kilgallen]

In article <392184A8.C9256A53@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> writes:
> Robert A Duff <bobduff@world.std.com>:
> 
>> > What about paging?
> 
> Larry Kilgallen:
> 
>> "Code" that never gets paged in (for execution) has no need to be
>> paged out.
> 
> But you can have code that is paged in without being ever executed -
> it could suffice it is at a small distance from executed code, in the
> same memory block. Couldn't it ?...

Absolutely.  But in addition to the code under discussion that can
never be called, the code that is never used also includes those
codepaths never traversed that happen to be close to codepaths
that are used with this particular set of input data.  That
seems to me much more likely to be in the same memory block.

Re: huge executable??

[Robert A Duff]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> In article <wccem72tz4n.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes:
> > What about paging?
> 
> "Code" that never gets paged in (for execution) has no need to be
> paged out.

My point was that pages are typically bigger than cache lines.  A given
procedure can be paged in, not because someone called it, but because it
happens to be on the same page as something that someone called.  I
haven't measured this, but I wouldn't be surprised if eliminating
uncalled procedures helped for this reason.

> Mine is a general comment, not based on the original OS/2 problem,
> but there seems to be a lot of that going on in this thread.

I've seen threads wander a lot farther.  ;-)

- Bob

Re: huge executable??

[Gautier]

> > I think that a reduced executable size is important, since
> > that allows a better use of the CPU cache memory, so that
> > could improve the speed of the program.

Robert Dewar:

> You are assuming that size of executable is directly related
> to the working set in cache.

If it is not directly related, it does not mean that is not related
at all! It depends on the granularity of the cache...

> > Concerning that problem, I suspect that, with GNAT, there is
> > not a good elimination of the unused code.

> Elimination of unused code will most certainly reduce executable
> size but it won't help one bit in reducing cache pressure, since
> obviously unused code never gets into the cache during
> execution.

Again you suppose that the cache granularity is so small that
the cache will only contain bytes of executed code and not parts
of the adjacent code. Is it really the case ? I have serious doubts!

> Basically the issue here boils down to disk costs alone. Seeing
> as 128K bytes is approximately $0.004 worth of disk space, I
> don't see this as a big worry these days :-)

You forget the Internet transmission times, that are now as much
if not more important. And whatever the cost of storage people
are sometimes curious about "the loads of bloatware" that end in
an .exe, especially if it comes from an Ada compiler! 

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: huge executable??

[Robert Dewar]

In article <3920F612.6790FBBC@maths.unine.ch>,
  Gautier <gautier.demontmollin@maths.unine.ch> wrote:

> > You are assuming that size of executable is directly related
> > to the working set in cache.
>
> If it is not directly related, it does not mean that is not
> at all! It depends on the granularity of the cache...

Well sure, if you had a cache with 4K lines ... but in practice
with real life hardware, the size of the working set in cache
is completely unrelated to the size of the executable.

> > Elimination of unused code will most certainly reduce
> > executable size but it won't help one bit in reducing cache
> > pressure, since
> > obviously unused code never gets into the cache during
> > execution.
>
> Again you suppose that the cache granularity is so small that
> the cache will only contain bytes of executed code and not
> parts of the adjacent code. Is it really the case ? I have
> serious doubts!

This effect, though theoretically there, is in fact far too
small to be measurable. If you don't believe this, try some
measurements. It's easy to do. By your theory, using gnatelim
should speed up execution significantly. It won't!

> > Basically the issue here boils down to disk costs alone.
> > Seeing
> > as 128K bytes is approximately $0.004 worth of disk space, I
> > don't see this as a big worry these days :-)

> And whatever the cost of storage people
> are sometimes curious about "the loads of bloatware" that end
> in an .exe, especially if it comes from an Ada compiler!

I do not think bloatware is about the minimal size of trivial
programs of no real interest from the point of view of actual
software use.

The reason people worry is they do not realize the

x + y*c
phenomenon

and think instead, gosh if my one line program generates 128K,
then what will 1000 lines generate? This of course is bogus
worrying, and the point of a discussion like this is to explain
that fact.

Once again, if you are simply worried about the size of the EXE,
just put the GNAT runtime library into a shared library. And
magically the executables will get dramaticaly smaller (at least
trivial executables will). Of course you have the inefficiencies
and inconveniences of shared libraries when you do this, so you
have to balance needs :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: huge executable??

[Florian Weimer]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Indeed it is obvious for example that static vs
> dynamic linking, which has no effect on cache usage to speak
> of, has a big effect on executable size.

If you run multiple Ada programs (or multiple instances of the same
program) in parallel, shared libraries can decrease cache pressure if
shared libraries are implemented properly (i.e. a shared library is
loaded once and mapped to different address spaces).

Re: huge executable??

[Robert Dewar]

In article <87wvkvj71c.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:

> If you run multiple Ada programs (or multiple instances of the
> same program) in parallel, shared libraries can decrease cache
> pressure

Again, this is a theoretical point that probably does not
register in practice. Why? Three reasons:

1. It is only relevant at task switch times, which happen with
very course granularity compared to cache usage and access.

2. In modern operating systems (those with 20,000,000 lines of
code doing something or other :-) the task switching code itself
will often swamp the cache anyway.

3. Task switching is so slow in these same large operating
systems that it gets long with respect to the time to completely
reload the cache.

The only time you might notice this effect is if you have a
really HUGE secondary cache, and lots of little Ada programs
switching furiously, all using the runtime library furiously.

I would be *VERY* surprised if you can even rig up a test that
would show this effect in practice.

Yes, in a light real time system, inter-task cache effects can
be significant, but I just don't think you will find this is
the case in most big operating systems.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: huge executable??

[David Starner]

On Sun, 14 May 2000 21:11:33 GMT, tmoran@bix.com <tmoran@bix.com> wrote:
>  The more important question is, is size a problem with real
>programs that do something substantial.

Sometimes. Think about writing Tom's Root/Boot Disk (one floppy Linux
rescue disk) in Ada. It couldn't be compiled with gnat, because between
libc (which libgnat depends on) and libgnat, you'd fill the 1.7M floppy
well before you got any working code.

-- 
David Starner - dstarner98@aasaa.ofe.org

The hell that is supposedly out there could be no worse than
the hell that is sometimes seen in here.

Re: huge executable??

[Lutz Donnerhacke]

* David Starner wrote:
>On Sun, 14 May 2000 21:11:33 GMT, tmoran@bix.com <tmoran@bix.com> wrote:
>>  The more important question is, is size a problem with real
>>programs that do something substantial.
>
>Sometimes. Think about writing Tom's Root/Boot Disk (one floppy Linux
>rescue disk) in Ada. It couldn't be compiled with gnat, because between
>libc (which libgnat depends on) and libgnat, you'd fill the 1.7M floppy
>well before you got any working code.

Or even think about init.

Re: huge executable??

[Robert Dewar]

In article <391E09C3.FA04871E@mailandnews.com>,
  David Dousette <david.dousette@mailandnews.com> wrote:
> but it's still 126,000 bytes.... why?  I wrote a similar
> program in C, and it was less than 5,000 bytes... why is the
> .EXE produced by Ada so much bigger?  The executable runs
> fine, and I have plenty of hard
> drive space... I was just curious.


Most likely the C run time is in a shared library, and the
Ada runtime is statically linked. In any case you expect the
runtime overhead to be greater than in C (consider for example
just the exception handling mechanism, which is there by
default in Ada, and unavailable in C).

Comparing trivial programs is really not a significant
excercise, the important thing is what large programs look
like and there the size without debug info should be comparable.

Note that there is no advantage in running emxbind -s EXCEPT to
save disk space, the debug information is not loaded into
memory, and the disadvantage of stripping is that then you will
not be able to debug if you want to!


Sent via Deja.com http://www.deja.com/
Before you buy.