Reducing the size of executables produced by GNAT

Reducing the size of executables produced by GNAT

[Hibou57]

Hallo,

My first question here.

For a long time ago I'm looking for a way to reduce th esize of Ada
programs compiled with GNAT.

With a simple Hello-World I cannot go below 45KB, which is very much
for a so simple program.

I'm afraid of what it means : take long to initialize at startup ? (I
need fast application, for CGI on a Linux server), many unusefull
dependencies on external library ? etc, etc

Further more, as usualy, dynamic linking on Linux fall into many
troubles, and to make it work properly, I need to compile it
statically linked. And there, I got a simple Hello-World which weight
120KB!

Why is it so big ?

What can I do ? Are there some hidden magic compiler switch to reduce
this size ?

What are the conscenquences of this size ? Does it execute all of this
120KB of code before starting the application main work ?

I have a look at the GNAT manual, then used gnatelim as suggested, but
this is not better (same size). I have a look at all gnatmake,
gnatbind and gnatlink options, but something good. I have a look at an
exemple at wikibook wihicj pretend to reduce the size of an hello work
downto 10K (which is still big, but really better), but while they
pretend to be able to do this.... they do not indicates a sole advice
to do it (strange...). I've tryed to compile with "pragma
No_Run_Time", but then compilation fails as soon as there is a sole
exception statement in the code (I need exceptions). I've tryed
"pragma Restricted_Run_Time" and "pragma Profile (Restricted)", but
this not better (always the same size).

So GNAT = big-big binaries : is it a rule ?

Many thanks for any concret advice, for any indications of any useful
compiler switch.

N.B. I do not need multitasking, I just need exception support, file I/
O, while in the mean time, if really necessary, I could create my own
package for IO.

Re: Reducing the size of executables produced by GNAT

[Martin Krischik]

Hibou57 schrieb:

> For a long time ago I'm looking for a way to reduce th esize of Ada
> programs compiled with GNAT.

See 
http://en.wikibooks.org/wiki/Ada_Programming/Basic#FAQ:_Why_is_.22Hello.2C_world.21.22_so_big.3F

> With a simple Hello-World I cannot go below 45KB, which is very much
> for a so simple program.

Well, the record is 8kb for Linux-i686-Release.

> I'm afraid of what it means : take long to initialize at startup ? (I
> need fast application, for CGI on a Linux server), many unusefull
> dependencies on external library ? etc, etc

No nessesarily, static linked files are large but might load faster. All 
depends of course. If startup is important then guesswork won't help - 
you have to time it.

BTW: I hope you use the most powerfully CGI binding available:

http://adacl.sourceforge.net/pmwiki.php/Main/CommonGatewayInterface

Note that AdaCL.CGI is the only CGI implementation which supports file 
upload.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Reducing the size of executables produced by GNAT

[Hibou57]

First of all, many thanks for you anwers to all of you :)

On 13 fév, 15:38, Martin Krischik <krisc...@users.sourceforge.net>
wrote:

> Seehttp://en.wikibooks.org/wiki/Ada_Programming/Basic#FAQ:_Why_is_.22Hel...
I saw this one, but when I try to compile the exemple with "gnatmake -
Phello_world", I just get compilation errors. I've removed the options
which turned into error, but then finally the size is the same.

Note: I'm using gcc-ada which comes with MinGW (for Windows XP), and
the last version of gcc-ada from Debian (for an old Linux machine).

> Well, the record is 8kb for Linux-i686-Release.
I would like to get the same :(

> No nessesarily, static linked files are large but might load faster. All
> depends of course. If startup is important then guesswork won't help -
> you have to time it.
Oops, I've sid something wrong : when I was talking about a statically
linked application, I was talking about a staticaly linked GNAT
runtime. Apart of that, there are still dynamics dependencies. So this
is not trully staticaly linked.

> BTW: I hope you use the most powerfully CGI binding available:
My own, which works fine. It is actually written in Pascal
(FreePascal), but I do not want to use it anymore (no more FreePascal,
and no more Pascal).


gautier_niou...@hotmail.com wrote
> Short answer: the fixed cost is big, but if your source grows beyond
> "Hello world", the binary growth is very decent, of course with the
> appropriate options.
Yes, you are right in some way, and I had my self written the same in
a french forum. But the world in not only made of big applications,
and some are small, while beeing still needed.

> Long answer: see newsgroups archives!
Already done, and I did not find anything useful to me.

Pascal Obry wrote :
> Yes and this is called: runtime.
I know what a runtime is, but I do not understand why the one coming
with GAT is so much big even where they are so little needs.

By the way : is there a place where one can find a lightweight
runtime ?

This was what I was looking for first, bu I did not find any at the
time.

> Indeed, debated many many times...
Perhaps, but if every will stop to talk about thing which has already
been talked about, then no body will not talk about anything :p

I was expecting to come into some interesting news.

Ludovic Brenta wrote:
> * compile with -Os (optimize for size)
> * strip the executable maximally
Already done (even tryed witg gnatelim, which by the way seems to be
missing with MinGW).

> Do not worry though that the machine executes 45 KB of instructions.
> Part of the executable contains data, which you cannot reduce but
> which is obviously not executable.
If it is not executed, so can I remove it in some way ?

> want performance, forget GCI. GCI is probably the worst way to do
> dynamic web sites and has been deprecated for the past 10 years or so.
> 120K or 45K or 10K CGI executables won't make a difference because the
> executable files will be in the buffer cache anyway. What does make
> CGI slow is creating a new process with environment variables, file
> descriptors, etc. and then the necessary inter-process communications
> between the web server and the scripts. And CGI does that for each
> incoming HTTP request: this is bad.

> The proper way is to write one executable that embeds the web server
> itself. The Ada Web Server library from AdaCore was designed
> specifically for this purpose.  With AWS, your one executable will be
> larger but much, much faster than CGI. And, since you will not launch
> your application with each HTTP request but only once and leave it
> running all the time, dynamic linking will be an option.

Nice advice indeed, I like this one, beceause I often think about it
(I'd better say, I often dream about it). I will love to be able to do
that, but I'm hosted on a mutualist server (not dedicated), so I have
no other choice excet to rely on the CGI interface.

At the time I'm just able to earn omething like 100$ a moth with this
site, so I cannot paid for a dedicated server, but I would like to
work on some more intereting online applications.

Anon wrote:
> If you rewrite the GNAT RT Libraries system so that it only uses the
> routines that you need with direct OS Interface packages you can get
> a program like "Hello" down to the bare minimum of 256 bytes (1
> sector on a floppy) or less. It is easy to do but for most people that
> too much work.
I do not mind about writing a runtime sweeted to what I need (I will
use syscalls, thus requiring no dynamic linking, fast and small), but
I do not know how to do with the exceptions runtime. I had a look at
this :
http://www.iuma.ulpgc.es/users/jmiranda/gnat-rts/index.htm
but this not goes into enought deep detail about the way GNAT handle
exceptions.

As an exemple, if I attempt to compile with "No_Run_Time", I get an
error about a duplicate symbol which is not documented in this
document.



Pascal Obry wrote:

> You must be very good to be able to develop a full Ada runtime in 256
> bytes! No the problem is more about unused code elimination, this is
> possible on some plate-forms with recent binutils and GCC/GNAT.
Not a full runtime of course, but a runtime with just what is needed
(mainly file I/O, memory allocation and exception support, ... the
latter beeing the one I do not know how to implement)

Tero Koskinen wrote :
> Like others suggested, look at AWS. It is a fast web server, much
> faster than normal http-server + CGI app combination.
As I said before, I would love to do that, but I cannot, due to the
fact that it is not a dedicated server.

> Here is simple example which uses C runtime instead of Ada runtime
> for output:
At the time the trouble is with exceptions

Is there a runtime with just no more than exception support ?


Well, I will have deeper look just at least to compare loading time of
a Pascal vs an Ada (GNAT) application.

If you have any other idea, do not hesitate to tell here

Read you soon friends :)

Yannick Duchêne

Re: Reducing the size of executables produced by GNAT

[Pascal Obry]

Hibou57 a �crit :
> As I said before, I would love to do that, but I cannot, due to the
> fact that it is not a dedicated server.

Don't understand! If you can deploy a CGI on this server you can deploy 
any binary. So an AWS server will do. You just have to either use 
another port than the 80 already used by the Web server or just set a 
redirection from the current Web server to your own AWS based Web server 
(An Apache rewrite rule should do the trick).

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Reducing the size of executables produced by GNAT

[Maciej Sobczak]

On 13 Lut, 21:25, Pascal Obry <pas...@obry.net> wrote:

> > As I said before, I would love to do that, but I cannot, due to the
> > fact that it is not a dedicated server.
>
> Don't understand! If you can deploy a CGI on this server you can deploy
> any binary.

No. Deploying a CGI means putting some files into some directory and
the server will do the rest. Deploying "any binary" might mean hooking
it to system startup, so that it gets started automatically after
reboot. Have you ever tried to have your own daemon on a shared host
in any decent hosting company? Forget about it - or just imagine you
are an admin of such a server and you have hundreds of clients with
such brave ideas.

> So an AWS server will do.

Unfortunately, no.

> You just have to either use
> another port than the 80

Firewalls will make it less funny. Hosting companies tend to have
firewalls.

> already used by the Web server or just set a
> redirection from the current Web server to your own AWS based Web server
> (An Apache rewrite rule should do the trick).

We are talking about shared hosting. I'm not sure if redirecting can
be set up easily in this case. With the companies I've been working
with so far, this was not possible.

AWS is an excellent solution, but in practice requires full control on
the given host. That does not work with the majority of hosting
companies out there.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Reducing the size of executables produced by GNAT

[Ludovic Brenta]

Maciej Sobczak writes:
> AWS is an excellent solution, but in practice requires full control
> on the given host. That does not work with the majority of hosting
> companies out there.

I was thinking along the same lines.  Maybe FastCGI might be an
option, but I doubt even that.

Reducing the size of the executables by a few kilobytes is not going
to make any difference, IMHO.  If the OP wants maximal performance in
forking processes on a shared host, maybe he should go all the way and
write his CGI scripts in assembly language :) does anyone else
perceive the irony in this?

To the OP: my advice is to get your own server (perhaps a virtual one)
and use AWS.

-- 
Ludovic Brenta.

Re: Reducing the size of executables produced by GNAT

[tmoran]

>At the time I'm just able to earn omething like 100$ a moth with this
>site, so I cannot paid for a dedicated server, but I would like to
  My own desktop machine has been running for a year and a half a web
serving program in Ada.  (http://scout.dyndns.info:63080/xscout.htm) It
makes very little demand on the machine, which I've been using for all the
computer work I do, including some intensive compute-bound things, while
Scout runs.  You can get a static or dynamic DNS address for something
like $10/yr, or for free if you don't mind monthly messages reminding you
to extend the service.  See www.dyndns.org
  The Scout program itself is based on smplsrvr, which is included in the
free ($=0) introductory edition of Claw (www.rrsoftware.com).  It works as
has been described - a set of worker tasks serve incoming http requests.

Re: Reducing the size of executables produced by GNAT

[Georg Bauhaus]

tmoran@acm.org wrote:
> You can get a static or dynamic DNS address for something
> like $10/yr, or for free if you don't mind monthly messages reminding you
> to extend the service.  See www.dyndns.org

A setup that links a computer via the _typical_ DSL might,
unfortunately, not permit dynamic DNS in Europe; some
providers' contracts specifically require that you do not
run the subscribed computer as a server.

OTOH, you can rent a virtual server at less than (100.0 / 1.45) * €
a month. This includes some disk space and 128MB or more of guaranteed
memory. I guess this makes virtual servers a viable solution for Ada
programs with any of the Ada web servers built in.

Re: Reducing the size of executables produced by GNAT

[Ludovic Brenta]

Georg Bauhaus wrote:
> you can rent a virtual server at less than (100.0 / 1.45) * EURO
> a month. This includes some disk space and 128MB or more of guaranteed
> memory. I guess this makes virtual servers a viable solution for Ada
> programs with any of the Ada web servers built in.

I think this is the best solution.  A quick glance at
http://wiki.debian.org/DebianHosting reveals prices currently starting
at 6 or 7 euros per month (plus VAT). Most offerings rely on Xen, but
I would not recommend that for a small web site because one kernel per
virtual machine is overkill in that case. Instead, OpenVZ and
VirtualLinux are better alternatives because they share the kernel
between all virtual machines (i.e. less memory, disk and CPU
overhead).

--
Ludovic Brenta.

Re: Reducing the size of executables produced by GNAT

[Hibou57]

I'm trying to set up a personalized RTS, but when I always get this
message :

> test.adb:2:04: construct not allowed in configurable run-time mode

where test.adb is

> procedure test is
> e: exception;
> begin
> raise e;
> exception
>     when others =>
>         null;
> end;

I'm not sure to understand, beceause this seems paradoxal : a custom
runtime is not allowed to implements every things ? There are things
that are not allowed with a custom runtime ?

I get this with "gnatmake --RTS=... test"

This is strange.

Re: Reducing the size of executables produced by GNAT

[Robert A Duff]

Hibou57 <yannick_duchene@yahoo.fr> writes:

> I'm trying to set up a personalized RTS,...

I don't like to dampen your enthusiasm, but I really think
you're headed in the wrong direction, here.  Writing your
own runtime is a big deal, even for a cut-down version.

And you don't even know that large executable files cause
long startup times -- you should at least measure that,
if that's your concern.

But anyway, if you go this way, first learn to build and modify both the
compiler and the runtime (the existing one).

>... but when I always get this
> message :
>
>> test.adb:2:04: construct not allowed in configurable run-time mode

To debug this, search the compiler sources to find where it prints
this message, and figure out what it's doing.

Do you know about the -gnatD and other related options?
They could come in handy to figure out what's missing.

> where test.adb is
>
>> procedure test is
>> e: exception;
>> begin
>> raise e;
>> exception
>>     when others =>
>>         null;
>> end;
>
> I'm not sure to understand, beceause this seems paradoxal : a custom
> runtime is not allowed to implements every things ? There are things
> that are not allowed with a custom runtime ?

That's not what it means.  It means something is missing.

> I get this with "gnatmake --RTS=... test"
>
> This is strange.

- Bob

Re: Reducing the size of executables produced by GNAT

[Gautier]

Hibou57:

> If you have any other idea, do not hesitate to tell here

* For instance make a preprocessor for Ada (to begin with, a small subset of 
Ada) that spits FreePascal code. Then you would have your small "fixed cost" for 
free with FreeAda (= preprocessor + FreePascal).
* Alternatively, build an Ada front-end to the FreePascal compiler.
* Consider using another Ada compiler than GNAT to that purpose.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Reducing the size of executables produced by GNAT

[Hibou57]

On 13 fév, 22:27, Gautier <gaut...@fakeaddress.nil> wrote:
> * For instance make a preprocessor for Ada (to begin with, a small subset of
> Ada) that spits FreePascal code. Then you would have your small "fixed cost" for
> free with FreeAda (= preprocessor + FreePascal).
> * Alternatively, build an Ada front-end to the FreePascal compiler.
Better create a compiler from the ground up than playing such
dangerous game (hihi).

> * Consider using another Ada compiler than GNAT to that purpose.
The fact is that GNAT is a monopol in this area. There use to be
SmallAda, and µAda, which were rahter Ada interpreters. Just look for
"Ada compiler", on any search engine, and you will always be bringed
to "GNAT", in one way in an other.

> Have you ever tried to have your own daemon on a shared host
> in any decent hosting company?
LOL

Yes, if it would have been possible, I would have done it from a long.

Just to come back to GNAT and its runtime, I will have a look at the
RTS source code. Pffff.... that's too much, and I feel as in an idle
state :p

It seems that they is an option --RTS=sjlj to use a kind of "long
jump" à la C, but I do not know if it is smaller, and I can't test it
beceause the compiler said it can't find the runtime (there is just
one RTS, both in my Windows and Linux GNAT installation).

Have a nice day

Re: Reducing the size of executables produced by GNAT

[Georg Bauhaus]

Hibou57 wrote:
> On 13 f�v, 22:27, Gautier <gaut...@fakeaddress.nil> wrote:
>> * For instance make a preprocessor for Ada (to begin with, a small subset of
>> Ada) that spits FreePascal code. Then you would have your small "fixed cost" for
>> free with FreeAda (= preprocessor + FreePascal).
>> * Alternatively, build an Ada front-end to the FreePascal compiler.
> Better create a compiler from the ground up than playing such
> dangerous game (hihi).
> 
>> * Consider using another Ada compiler than GNAT to that purpose.
> The fact is that GNAT is a monopol in this area. There use to be
> SmallAda, and �Ada, which were rahter Ada interpreters. Just look for
> "Ada compiler", on any search engine, and you will always be bringed
> to "GNAT", in one way in an other.

Then look for ["Ada compiler" -GNAT] :-)

In fact, maybe the recent market dominance, if any, has been
bridled by the removal of the "proprietary code permission"
from the license of AdaCore's public editions (the ones that
are available to those writing Free Software).

FWIW, there are a number of commercially supported compilers to
choose from (Aonix, RR Software, SofCheck, ..., for MS Windows or
GNU/Linux); depending on your needs they can start in the same
price range as any compiler.

Re: Reducing the size of executables produced by GNAT

[anon]

To use the "--RTS=" or "-fRTS=" feature all you do is create the 
following structure:

        /myrts
                /adainclude
                        ada.ads ----- must be here
                        system.ads -- must be here 

                        a-textio.adb -- user created version
                        a-textio.ads
                        ...
                /adalib
                        ada.ali ----- must be here
                        ada.o 
                        system.ali -- must be here
                        system.o 

                        a-textio.ali -- user created version
                        a-textio.o 
                        ...

        The "Ada.ads" and "System.ads" should be copied from the 
        Standard installed ada system.
        All RTS source files should be inserted into the "adainclude"
        All RTS "*.ali" and RTS "*.o" files should be inserted in 
        "adalib"

        Edit a copy of Ada.Text_IO (a-textio.ad?) so that it only 
        includes the IO routines that you need. And that means 
        deleting the exceptions and file structures. Use Import 
        statement to link to OS,

        To compile the RTS you must use "-gnatg" in command line 
        for all language packages or sub-packages.


To use:

        gnat compile <program/user package>.ad[b|s] -fRTS=myrts
        gnat bind <program/user package>.ali -fRTS=myrts
        gnat link <program>.ali -fRTS=myrts

        You could also add "-nostdinc" to insure that the standard Ada 
is not included or search. The "-nostdlib" added also on the link 
command.

        As you perform each of the three commands you might see error 
that you need to fix. Such as adding other packages that your RTS 
needs and you may have to copy or rewrite.




In <3ff060f5-673b-4011-a0d1-1692d6e6f105@e10g2000prf.googlegroups.com>, Hibou57 <yannick_duchene@yahoo.fr> writes:
>On 13 f=E9v, 22:27, Gautier <gaut...@fakeaddress.nil> wrote:
>> * For instance make a preprocessor for Ada (to begin with, a small subset =
>of
>> Ada) that spits FreePascal code. Then you would have your small "fixed cos=
>t" for
>> free with FreeAda (=3D preprocessor + FreePascal).
>> * Alternatively, build an Ada front-end to the FreePascal compiler.
>Better create a compiler from the ground up than playing such
>dangerous game (hihi).
>
>> * Consider using another Ada compiler than GNAT to that purpose.
>The fact is that GNAT is a monopol in this area. There use to be
>SmallAda, and =B5Ada, which were rahter Ada interpreters. Just look for
>"Ada compiler", on any search engine, and you will always be bringed
>to "GNAT", in one way in an other.
>
>> Have you ever tried to have your own daemon on a shared host
>> in any decent hosting company?
>LOL
>
>Yes, if it would have been possible, I would have done it from a long.
>
>Just to come back to GNAT and its runtime, I will have a look at the
>RTS source code. Pffff.... that's too much, and I feel as in an idle
>state :p
>
>It seems that they is an option --RTS=3Dsjlj to use a kind of "long
>jump" =E0 la C, but I do not know if it is smaller, and I can't test it
>beceause the compiler said it can't find the runtime (there is just
>one RTS, both in my Windows and Linux GNAT installation).
>
>Have a nice day

Re: Reducing the size of executables produced by GNAT

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

"Hibou57" <yannick_duchene@yahoo.fr> wrote in message
news:3ff060f5-673b-4011-a0d1-1692d6e6f105@e10g2000prf.googlegroups.com...
On 13 f�v, 22:27, Gautier <gaut...@fakeaddress.nil> wrote:
...
> * Consider using another Ada compiler than GNAT to that purpose.
The fact is that GNAT is a monopol in this area. There use to be
SmallAda, and �Ada, which were rahter Ada interpreters. Just look for
"Ada compiler", on any search engine, and you will always be bringed
to "GNAT", in one way in an other.

Surely there are other Ada compilers. In this space, Aonix's compilers might
work (but I think would be pricey).

Janus/Ada would be ideal for what you are trying to do (it was designed from
the ground up to minimize code size, since it was originally intended to run
on 640K MS-DOS machines - Hello World executable sizes are around 60K - and
programs that don't use Text_IO can be a lot smaller), but we have not yet
done a Linux version.

[It should be noted that a lot of the executable size of a (tiny) Windows
program is made up of linkage tables that don't actually contribute to the
(real) memory footprint of the program. A rough guess is that there is
around 12K of such stuff.]

[I'm always surprised at the size of Windows programs compared to their
MS-DOS counterparts. Hello World had a 12K executable size on 32-bit MS-DOS
using an extender - that's the same instructions, just different OS calls.
Of course, the extender added some size. The 16-bit MS-DOS executables could
be as small as 4K and no extender was needed.]

---

OTOH, I tend to argee that the best solution is to run a custom web server,
not CGI. The server that runs AdaIC.com is written in Ada, runs behind a
business DSL line on an ordinary 900 MHZ Windows desktop, and rarely bogs
down (occasionally for complex searches or when we're blasted with spam).
That server not only serves normal pages, but it also runs a search engine,
serves dynamic spotlights, and handles on-line surveys -- all with compiled
Ada code (nothing is written in another language and all is linked
together). [It's a relative of Tom's Smplsrvr, although it is quite a bit
more complex.]

                                     Randy.

Re: Reducing the size of executables produced by GNAT

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

"Hibou57" <yannick_duchene@yahoo.fr> wrote in message
news:3ff060f5-673b-4011-a0d1-1692d6e6f105@e10g2000prf.googlegroups.com...
On 13 f�v, 22:27, Gautier <gaut...@fakeaddress.nil> wrote:
...
> * Consider using another Ada compiler than GNAT to that purpose.
The fact is that GNAT is a monopol in this area. There use to be
SmallAda, and �Ada, which were rahter Ada interpreters. Just look for
"Ada compiler", on any search engine, and you will always be bringed
to "GNAT", in one way in an other.

Surely there are other Ada compilers. In this space, Aonix's compilers might
work (but I think would be pricey).

Janus/Ada would be ideal for what you are trying to do (it was designed from
the ground up to minimize code size, since it was originally intended to run
on 640K MS-DOS machines - Hello World executable sizes are around 60K - and
programs that don't use Text_IO can be a lot smaller), but we have not yet
done a Linux version.

[It should be noted that a lot of the executable size of a (tiny) Windows
program is made up of linkage tables that don't actually contribute to the
(real) memory footprint of the program. A rough guess is that there is
around 12K of such stuff.]

[I'm always surprised at the size of Windows programs compared to their
MS-DOS counterparts. Hello World had a 12K executable size on 32-bit MS-DOS
using an extender - that's the same instructions, just different OS calls.
Of course, the extender added some size. The 16-bit MS-DOS executables could
be as small as 4K and no extender was needed.]

---

OTOH, I tend to argee that the best solution is to run a custom web server,
not CGI. The server that runs AdaIC.com is written in Ada, runs behind a
business DSL line on an ordinary 900 MHZ Windows desktop, and rarely bogs
down (occasionally for complex searches or when we're blasted with spam).
That server not only serves normal pages, but it also runs a search engine,
serves dynamic spotlights, and handles on-line surveys -- all with compiled
Ada code (nothing is written in another language and all is linked
together). [It's a relative of Tom's Smplsrvr, although it is quite a bit
more complex.]

                                     Randy.

Re: Reducing the size of executables produced by GNAT

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

"Hibou57" <yannick_duchene@yahoo.fr> wrote in message
news:3ff060f5-673b-4011-a0d1-1692d6e6f105@e10g2000prf.googlegroups.com...
On 13 f�v, 22:27, Gautier <gaut...@fakeaddress.nil> wrote:
...
> * Consider using another Ada compiler than GNAT to that purpose.
The fact is that GNAT is a monopol in this area. There use to be
SmallAda, and �Ada, which were rahter Ada interpreters. Just look for
"Ada compiler", on any search engine, and you will always be bringed
to "GNAT", in one way in an other.

Surely there are other Ada compilers. In this space, Aonix's compilers might
work (but I think would be pricey).

Janus/Ada would be ideal for what you are trying to do (it was designed from
the ground up to minimize code size, since it was originally intended to run
on 640K MS-DOS machines - Hello World executable sizes are around 60K - and
programs that don't use Text_IO can be a lot smaller), but we have not yet
done a Linux version.

[It should be noted that a lot of the executable size of a (tiny) Windows
program is made up of linkage tables that don't actually contribute to the
(real) memory footprint of the program. A rough guess is that there is
around 12K of such stuff.]

[I'm always surprised at the size of Windows programs compared to their
MS-DOS counterparts. Hello World had a 12K executable size on 32-bit MS-DOS
using an extender - that's the same instructions, just different OS calls.
Of course, the extender added some size. The 16-bit MS-DOS executables could
be as small as 4K and no extender was needed.]

---

OTOH, I tend to argee that the best solution is to run a custom web server,
not CGI. The server that runs AdaIC.com is written in Ada, runs behind a
business DSL line on an ordinary 900 MHZ Windows desktop, and rarely bogs
down (occasionally for complex searches or when we're blasted with spam).
That server not only serves normal pages, but it also runs a search engine,
serves dynamic spotlights, and handles on-line surveys -- all with compiled
Ada code (nothing is written in another language and all is linked
together). [It's a relative of Tom's Smplsrvr, although it is quite a bit
more complex.]

                                     Randy.

Re: Reducing the size of executables produced by GNAT

[Hibou57]

Well, well,

I've finally managed to custom a runtime with GNAT for Windows.

The big stuff was with the exception runtime.

It appears that I could go from 43KB down to 25KB, when removing
traceback and exception information functionalities.

So those two sole functionalities weight near to 20KB. I was a bit
surprised, but in the mean time, I was seeing that the elaboration of
the involved package does not cost a lot of execution at start up.

I was to go further, but stop there, beceause the conclusion I went to
at this point was suffiscient to tell me that this is unusefull to go
further.

The conclusion is : there is a weight for some functionalities which
may indeed be unused, but the elaboration cost at application start up
is low. So the size of 45KB for a very simple application does not
means there is an expensive overhead.

More from this conclusion : the risk coming with numerous
modifications of the runtime code is too hight compare to the
advantage one may get with these modifications.

Thus, I prefer to let the runtime as-is, as stable as it is, beceause
there is not enough benefits to modify it.

I still recognize that the code could be lighter, but GNAT is GNAT,
and it is dedicated to serve in the area of big applications, and
requirements in this area make some design choice of GNAT rather
obvious. GNAT is definitely not well suited for small applications,
but GNAT is still a good Ada compiler and is well suited for
application with which ones size is not a matter. GNAT is good enough
for little application as soon the incompressible size of the runtime
is not a matter, in the sense that the elaboration of the runtime is
does not cost so much.

I still recognize then that an Ada compiler producing smaller code
will be welcome, but this will require services apart of GNAT.

That's all of my conclusions after managed to setup a lighter
runtime : this is unusefull to persist in this way, and there are more
profits to not to touch it than to reduce it.

Have a nice day,

Yannick

Re: Reducing the size of executables produced by GNAT

[gautier_niouzes]

Hibou57:

> So GNAT = big-big binaries : is it a rule ?

Short answer: the fixed cost is big, but if your source grows beyond
"Hello world", the binary growth is very decent, of course with the
appropriate options.
Long answer: see newsgroups archives!

HTH, G.

Re: Reducing the size of executables produced by GNAT

[Pascal Obry]

gautier_niouzes@hotmail.com a �crit :
> Short answer: the fixed cost is big, but if your source grows beyond
> "Hello world", the binary growth is very decent, of course with the
> appropriate options.

Yes and this is called: runtime.

> Long answer: see newsgroups archives!

Indeed, debated many many times...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Reducing the size of executables produced by GNAT

[Ludovic Brenta]

First here are a couple hints:

* compile with -Os (optimize for size)
* strip the executable maximally

Do not worry though that the machine executes 45 KB of instructions.
Part of the executable contains data, which you cannot reduce but
which is obviously not executable.

But this is all besides the point. Your real problem is CGI. If you
want performance, forget GCI. GCI is probably the worst way to do
dynamic web sites and has been deprecated for the past 10 years or so.
120K or 45K or 10K CGI executables won't make a difference because the
executable files will be in the buffer cache anyway. What does make
CGI slow is creating a new process with environment variables, file
descriptors, etc. and then the necessary inter-process communications
between the web server and the scripts. And CGI does that for each
incoming HTTP request: this is bad.

The proper way is to write one executable that embeds the web server
itself. The Ada Web Server library from AdaCore was designed
specifically for this purpose.  With AWS, your one executable will be
larger but much, much faster than CGI. And, since you will not launch
your application with each HTTP request but only once and leave it
running all the time, dynamic linking will be an option.

Your web application can be very simple. Start listening on port 80.
For each incoming request, call an Ada procedure that responds to the
request. Done.

Now, if your web application has many clients, you may want to be able
to service more than one request at a time. For this, use Ada tasking.
Your program first creates a queue of incoming requests, then a fixed
number of worker tasks. After the worker tasks are created, it starts
listening on port 80. For each incoming request, instead of processing
the request, it places it in the queue.  Each worker task is an
infinite loop that waits for a request to become available in the
queue, takes it, processes it, sends the response to the client, and
comes back.

In either case (single-task or multi-task) you have a fixed number of
tasks that are infinite loops waiting for user input. Thus you never
have to fork() a new process. This is good.

And, all of this is one single executable program.  If this program is
statically linked and contains, in its data segment, all images and
web page templates necessary, then it never has to read from the disk
at all, running entirely from memory. That's how you achieve
performance and small footprint.

Read the details in the AWS User's Guide.

--
Ludovic Brenta.

Re: Reducing the size of executables produced by GNAT

[anon]

The answer is a multi part answer.

        1. The GNAT Ada Run-Time Libraries and compiler system.

        2. The GNU GCC Linker and C Libraries that GNAT uses.

        Note: This is because GNU GCC and GNAT was and is written 
              for use in a multi-platform world. That is you write and
              compile your code on one platform and simple recompile 
              it on another with no modifications. Other than maybe 
              the filenames (because characters like '$' are illegal on
              some OSs) and the directory separators used ('/' unix
              style or '\' windows style).

If you rewrite the GNAT RT Libraries system so that it only uses the 
routines that you need with direct OS Interface packages you can get 
a program like "Hello" down to the bare minimum of 256 bytes (1 
sector on a floppy) or less. It is easy to do but for most people that 
too much work.


In <40e9c01a-8d31-4554-9d9b-18cce7834d56@s12g2000prg.googlegroups.com>, Hibou57 <yannick_duchene@yahoo.fr> writes:
>Hallo,
>
>My first question here.
>
>For a long time ago I'm looking for a way to reduce th esize of Ada
>programs compiled with GNAT.
>
>With a simple Hello-World I cannot go below 45KB, which is very much
>for a so simple program.
>
>I'm afraid of what it means : take long to initialize at startup ? (I
>need fast application, for CGI on a Linux server), many unusefull
>dependencies on external library ? etc, etc
>
>Further more, as usualy, dynamic linking on Linux fall into many
>troubles, and to make it work properly, I need to compile it
>statically linked. And there, I got a simple Hello-World which weight
>120KB!
>
>Why is it so big ?
>
>What can I do ? Are there some hidden magic compiler switch to reduce
>this size ?
>
>What are the conscenquences of this size ? Does it execute all of this
>120KB of code before starting the application main work ?
>
>I have a look at the GNAT manual, then used gnatelim as suggested, but
>this is not better (same size). I have a look at all gnatmake,
>gnatbind and gnatlink options, but something good. I have a look at an
>exemple at wikibook wihicj pretend to reduce the size of an hello work
>downto 10K (which is still big, but really better), but while they
>pretend to be able to do this.... they do not indicates a sole advice
>to do it (strange...). I've tryed to compile with "pragma
>No_Run_Time", but then compilation fails as soon as there is a sole
>exception statement in the code (I need exceptions). I've tryed
>"pragma Restricted_Run_Time" and "pragma Profile (Restricted)", but
>this not better (always the same size).
>
>So GNAT = big-big binaries : is it a rule ?
>
>Many thanks for any concret advice, for any indications of any useful
>compiler switch.
>
>N.B. I do not need multitasking, I just need exception support, file I/
>O, while in the mean time, if really necessary, I could create my own
>package for IO.

Re: Reducing the size of executables produced by GNAT

[Pascal Obry]

anon a �crit :
> If you rewrite the GNAT RT Libraries system so that it only uses the 
> routines that you need with direct OS Interface packages you can get 
> a program like "Hello" down to the bare minimum of 256 bytes (1 
> sector on a floppy) or less. It is easy to do but for most people that 
> too much work.

ROTFL :)

You must be very good to be able to develop a full Ada runtime in 256 
bytes! No the problem is more about unused code elimination, this is 
possible on some plate-forms with recent binutils and GCC/GNAT.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Reducing the size of executables produced by GNAT

[Tero Koskinen]

On Wed, 13 Feb 2008 03:52:49 -0800 (PST) Hibou57 wrote:
> I'm afraid of what it means : take long to initialize at startup ? (I
> need fast application, for CGI on a Linux server), many unusefull
> dependencies on external library ? etc, etc

Like others suggested, look at AWS. It is a fast web server, much
faster than normal http-server + CGI app combination.

> to do it (strange...). I've tryed to compile with "pragma
> No_Run_Time", 

Here is simple example which uses C runtime instead of Ada runtime
for output:
==snip==
pragma No_Run_Time;
with Interfaces.C; use Interfaces.C;

procedure Hello is
   procedure Puts (Str : Char_Array);
   pragma Import (C, Puts, "puts");
begin
   Puts ("Hello, World!");
end Hello;
==snip==
Compile it using command:
$ gnatmake -Os hello
or:
$ gnatmake -Os hello -largs -static
(add -lc if needed)

On OpenBSD/i386 with GCC 4.3 I get following sizes (after strip):
-rwxr-xr-x  1 tkoskine  tkoskine   5752 Feb 13 19:21 hello.dynamic
-rwxr-xr-x  1 tkoskine  tkoskine  75908 Feb 13 19:17 hello.static

Normal hello using Ada.Text_IO and full Ada runtime:
-rwxr-xr-x  1 tkoskine  tkoskine  91140 Feb 13 19:32 hello.normal.dynamic
-rwxr-xr-x  1 tkoskine  tkoskine  210088 Feb 13 19:32 hello.normal.static

On Linux system you probably get smaller binaries, because OpenBSD
includes all kinds of magical buffer overflow protection stuff into
binaries.

But like you noticed without runtime your life gets harder.
It is easier to just use full Ada runtime. My AWS binaries
have been from 1.5M to 3M and you should be able to fit that
on any modern system with a network connection.

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: Reducing the size of executables produced by GNAT

[Jeffrey R. Carter]

Hibou57 wrote:
> 
> For a long time ago I'm looking for a way to reduce th esize of Ada
> programs compiled with GNAT.
> 
> With a simple Hello-World I cannot go below 45KB, which is very much
> for a so simple program.

I presume you're using Ada.Text_IO, which is a very large, complex package that 
does lots of things few people ever use, such as counting columns, lines, and 
pages. This is the main reason naive Ada hello-world programs are bigger than 
those from languages with simpler I/O libraries.

Since you're using GNAT, one simple option is to use GNAT.IO rather than 
Ada.Text_IO. That should cause a noticeable reduction in executable size.

You can also import the C fputs function and reduce the size even further.

-- 
Jeff Carter
"People called Romanes, they go the house?"
Monty Python's Life of Brian
79

Re: Reducing the size of executables produced by GNAT

[Jacob Sparre Andersen]

Hibou57 <yannick_duchene@yahoo.fr> writes:

> For a long time ago I'm looking for a way to reduce th esize of Ada
> programs compiled with GNAT.

Are you sure it is an important goal for your task?

> With a simple Hello-World I cannot go below 45KB, which is very much
> for a so simple program.

I just created a 7_796 byte "Hello World" program.  Without any
special tricks.

I suspect that you are not really aware of what the Ada.Text_IO
library is supposed to do behind the scenes.  There is a fair bit of
accounting going on.

> I'm afraid of what it means : take long to initialize at startup ?

Have you tested if that is really the case?

> (I need fast application, for CGI on a Linux server),

If you really need a fast solution, why don't you create a stand-alone
HTTP server instead?

> Further more, as usualy, dynamic linking on Linux fall into many
> troubles,

The only one I've ever had, is that I have to recompile when I switch
to the next stable version of Debian.

> I need to compile it statically linked. And there, I got a simple
> Hello-World which weight 120KB!

I only get 110_236 bytes.

> Why is it so big ?

Because you link in the run-time.

> What can I do ? Are there some hidden magic compiler switch to
> reduce this size ?

None that I know of.

> What are the conscenquences of this size ? Does it execute all of
> this 120KB of code before starting the application main work ?

Most likely not.

Greetings,

Jacob
-- 
�A corollary of Murphy's law is that duplicate information
 eventually becomes different information.  Putting both in
 the same file may slow down the process, but it will not
 prevent it.�                                 -- Wes Groleau