From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Looking for a smart linker for GNAT/DOS
Date: 1997/04/18
Date: 1997-04-18T00:00:00+00:00 [thread overview]
Message-ID: <dewar.861372455@merv> (raw)
In-Reply-To: 1997Apr16.162852.5886@news
Gautier said
<<The skip from 47k to 97k with the usage of Text_IO is insignificant
for a real project because you will use the greatest part of Text_IO.
But, in a real project, you will (maybe) also use much bigger
and specialized packages whom you use only 10% - e.g., a graphics package
with tons of gadgets, curves, bars (I'm making an improved clone
of Turbo Pascal's Graph, there the problem appears well...).
So, the difference between the full packages sizes and the used part of them
will *increase* with greater projects - this is why the <<explosion>> term
is appropriated.>>
That's certainly right, we just found your examples in your original
message to be unconvincing, and not terribly relevant, because in
fact a smart linker would not reduce much in either of the two cases
you mentioned if anything.
One thing that can help is the systematic use of DLL's or whatever
shared libraries are called on your machine. Since only what you
actually use is loaded into physical memory, and since your image
then does not contain the code, the problem is largely alleviated.
Note for example that the DLL that comes with Cygwin is pretty big,
several megabytes, since it contains huge amounts of functionality.
But a program using this DLL pays neither in disk space for the EXE
nor in working set size in physical memory.
By the way, we are now designing and implementing a new tool that
will automate the building of such DLL's and that will help.
P.S. GNAT already does something about Text_IO. In GNAT, packages
like Integer_IO, Float_IO etc are implemented as child units (which
is how they should have been defined in the first place if we were
not constrained by Ada 83 compatibility), so they are only loaded
if needed. This implementation is transparent to a user (interested
people may enjoy looking at the routine Text_IO_Kludge in rtsfind
in the GNAT sources to see how this is done :-)
I'm thinking about the LAPACK library in FORTRAN, too: in many real projects,
only a few from the thousends LAPACK routines are used.
A GNAT/DOS implementation of it would produce executables of >20 megas
(and certainly just wouldn't run on most machines),
although they should be of a few hundreds of K if linked by a good linker!
You are confusing virtual and physical memory here. Just because an
EXE is large does not mean that you needs lots of physical memory in
your working set to run the program, so you are probably quite wrong
about it not running on most machines.
Nevertheless, even in these days of 6 cents/megabyte disk, we really
do not want 20 meg executables around (for one thing there are still
old fashioned systems that do initially load the whole exe file instead
of mapping it), and for another, even at that price, 20 megs/program
adds up!
There are two solutions (besides a smart linker). The first is to
structure the interface as a set of separate Ada 95 child units,
rather than one monolithic spec. After all the original Fortran
routines are separate units, and a Fortran program using LAPACK
works fine even without a smart linker.
The second is to put the interface in a DLL, as described above.
These days, that is getting to be a more and more attractive
solution, and it may well be that this is the way to go, since
it is more convenient for the Ada programmer than splitting the
interface into separate units.
This is not to say that a smart linker would not be useful, just that
with modern systems, the need for smart linkers is less than it used
to be, which makes it even less likely that you will find such beasts
around.
Certainly we have decided that we cannot count on smart linkers for
elimination of unused subprograms, which is why we have decided on
a source based approach to solve this problem. Basically our approach
works as follows:
There is a configuration pragma which declares that a certain
subprogram is unused. In the presence of the pragma, the compiler
(a) stubs out the subprogram, and (b) makes sure it is not called.
These configuration pragmas can be gathered together in gnat.adc
as usual, so no actual source changes are required.
There is an ASIS based tool that scans a set of units to determine
the set of unused subprograms and builds the necessary file of
configuration pragmas.
Robert Dewar
Ada Core Technologies
next prev parent reply other threads:[~1997-04-18 0:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1997Apr15.202909.5879@news>
1997-04-16 0:00 ` Looking for a smart linker for GNAT/DOS Samuel Tardieu
1997-04-16 0:00 ` Gautier
1997-04-18 0:00 ` Robert Dewar [this message]
1997-04-19 0:00 ` Geert Bosch
1997-04-22 0:00 ` Robert Dewar
1997-04-28 0:00 ` Larry Kilgallen
1997-04-19 0:00 ` Fergus Henderson
1997-04-21 0:00 ` Robert Dewar
1997-04-21 0:00 ` Gautier
1997-04-23 0:00 ` Robert Dewar
1997-04-24 0:00 ` Gautier
1997-04-26 0:00 ` Robert Dewar
1997-04-27 0:00 ` Geert Bosch
1997-04-29 0:00 ` Gautier
1997-04-21 0:00 ` Mats Weber
1997-04-23 0:00 ` Robert Dewar
1997-04-21 0:00 ` Gautier
[not found] ` <dewar.861173085@merv>
1997-04-17 0:00 ` Gautier
1997-04-17 0:00 ` Robert Dewar
1997-04-18 0:00 ` Gautier
1997-04-19 0:00 ` Robert Dewar
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox