Size of linked program increasing with new version of GNAT.

Size of linked program increasing with new version of GNAT.

[Tony]

I just downloaded the latest version of GNAT GPL. My previous version was 3.15p. I notice that the size of linked executables increase substantially. The minimal Hello-World program goes up in size from 67 to 195 KB. 

Why? I would expect things to improve with newer versions instead of becoming worse.

Re: Size of linked program increasing with new version of GNAT.

[Björn Lundin]

On 2014-12-25 18:44, Tony wrote:
> I just downloaded the latest version of GNAT GPL. My previous version was 3.15p. I notice that the size of linked executables increase substantially. The minimal Hello-World program goes up in size from 67 to 195 KB. 
> 
> Why? I would expect things to improve with newer versions instead of becoming worse.

You just defined better to equal smaller executables.
Perhaps there are other wins?

Like supporting Ada05 and Ada12
Like producing better/more accurate crashdumps


It would help to state OS. And compiler/link flags
And architechture (32/64)
eventhough I guess 32 bit Win xp - or windows 2000.
That is OS on par age-wise wiht 3.15p - Or Win 98 ?

--
Björn

Re: Size of linked program increasing with new version of GNAT.

[tony7]

> Perhaps there are other wins?

Yes, some programs run a bit faster (up to 25%).

> It would help to state OS. And compiler/link flags
> And architecture (32/64)
> eventhough I guess 32 bit Win xp - or windows 2000.

Thats right: 32 bit Win XP. 
Compiled it with: gnatmake -O2 -largs -s

Re: Size of linked program increasing with new version of GNAT.

[Björn Lundin]

On 2014-12-25 19:36, tony7@tele2.se wrote:
>> Perhaps there are other wins?
> 
> Yes, some programs run a bit faster (up to 25%).
> 
>> It would help to state OS. And compiler/link flags
>> And architecture (32/64)
>> eventhough I guess 32 bit Win xp - or windows 2000.
> 
> Thats right: 32 bit Win XP. 
> Compiled it with: gnatmake -O2 -largs -s
> 

I think you want -O1

-O1 for small size
-O2 for speed

I _think_

read more in the gnat users manual.

-- 
--
Björn

Re: Size of linked program increasing with new version of GNAT.

[Shark8]

On 25-Dec-14 12:41, Björn Lundin wrote:
> On 2014-12-25 19:36, tony7@tele2.se wrote:
>
> I think you want -O1
>
> -O1 for small size
> -O2 for speed
>
> I _think_
>
> read more in the gnat users manual.
>

-OS for small size.

See: 
https://gcc.gnu.org/onlinedocs/gnat_ugn/Optimization-Levels.html#Optimization-Levels

Re: Size of linked program increasing with new version of GNAT.

[tony7]

> I think you want -O1
> 
> -O1 for small size
> -O2 for speed

I tried both combinations with both GNAT versions. The -O1/O2 switches makes no difference on the size. The object code of the main program is less than one KB, so most of the linked program must come from some precompiled library, which is not affected by the compiler switches.

> -Os for small size.

Tried this one also now. The 3.15p GNAT don't have it. The 2014 GNAT still produces a 195 KB executable.

Re: Size of linked program increasing with new version of GNAT.

[Shark8]

On 25-Dec-14 13:15, tony7@tele2.se wrote:
>> I think you want -O1
>>
>> -O1 for small size
>> -O2 for speed
>
> I tried both combinations with both GNAT versions.
> The -O1/O2 switches makes no difference on the size.
> The object code of the main program is less than one KB, so most of the
> linked program must come from some precompiled library, which is not
> affected by the compiler switches.

Right.
Which means you'd have to compile all the other stuff, presumably w/ the 
-Os switch. -- Probably with the "list possible restrictions" active, 
and applying those restrictions as much as possible.

>
>> -Os for small size.
>
> Tried this one also now. The 3.15p GNAT don't have it. The 2014 GNAT
> still produces a 195 KB executable.
>

Did you use the "strip unused sections" [or something similar] option 
for the linker?

Re: Size of linked program increasing with new version of GNAT.

[Peter Chapin]

On Thu, 25 Dec 2014, Shark8 wrote:

>> 
>>> -Os for small size.
>> 
>> Tried this one also now. The 3.15p GNAT don't have it. The 2014 GNAT
>> still produces a 195 KB executable.
>> 
>
> Did you use the "strip unused sections" [or something similar] option 
> for the linker?

The OP might also want to look into gnatelim to see if using it could help 
eliminate unusued code.

One could argue that the size of the "Hello, World" program isn't all that 
important. The overhead might be large but if most of that overheard is 
actually used in a realistically sized program, well, it's not really 
overhead in that case.

Peter

Re: Size of linked program increasing with new version of GNAT.

[Pascal Obry]

Le jeudi 25 décembre 2014 à 09:44 -0800, Tony a écrit : 
> Why? I would expect things to improve with newer versions instead of becoming worse.

Nothing is becoming worse you are just looking at different things.

What about the debug info?

Which compiler options have you used?

Have your used inlining?

Since when "bigger size" means worse?

Have you looked at the actual code size (.text section)?

Have you benchmarked the actual code speed?

What is the price of the disk today compared to 10 years ago?

...

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Size of linked program increasing with new version of GNAT.

[J-P. Rosen]

Le 26/12/2014 15:32, Pascal Obry a écrit :
> Le jeudi 25 décembre 2014 à 09:44 -0800, Tony a écrit : 
>> > Why? I would expect things to improve with newer versions instead of becoming worse.
> Nothing is becoming worse you are just looking at different things.

Maybe the OP is thinking that bigger size => more code => worse code.

Of course, this is a very naive view. Things are MUCH more
complicated... (for one thing: more code may mean faster code, think of
loop unrolling for example).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Size of linked program increasing with new version of GNAT.

[Simon Clubley]

On 2014-12-26, Pascal Obry <pascal@obry.net> wrote:
>
> Since when "bigger size" means worse?
>

When you need the resulting executable to fit in fixed size flash memory. :-)

(I'm answering the general question here and not discussing the OP's
current environment.)

> Have you looked at the actual code size (.text section)?
>

This is exactly what I was going to ask.

It would be interesting for the OP to run the binutils size command on
both executables and post the results.

>
> What is the price of the disk today compared to 10 years ago?
>

Not all executables run on a desktop PC. If current versions of GNAT
have increased the actual minimum executable size this may be of
interest for embedded environments.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Size of linked program increasing with new version of GNAT.

[Tony]

On Friday, December 26, 2014 4:56:16 PM UTC+1, Simon Clubley wrote:
> It would be interesting for the OP to run the binutils size command on
> both executables and post the results.

OK, GNAT 3.15p:
C:\Tony\Ada_program\Tests>size hello.exe -A
hello.exe  :
section    size      addr
.text    62428   4198400
.data     2244   4263936
.bss     21124   4268032
.idata    2416   4292608
Total    88212

GNAT 2014:
C:\Tony\Ada_program\Tests>size hello.exe -A
hello.exe  :
section      size      addr
.text      133348   4198400
.data        1092   4333568
.rdata      15500   4337664
.eh_fram    41432   4354048
.bss        13892   4399104
.idata       5112   4415488
.CRT           52   4423680
.tls           32   4427776
Total      210460

Re: Size of linked program increasing with new version of GNAT.

[Randy Brukardt]

"Peter Chapin" <PChapin@vtc.vsc.edu> wrote in message 
news:alpine.CYG.2.11.1412251746260.2396@WIL414CHAPIN.vtc.vsc.edu...
> On Thu, 25 Dec 2014, Shark8 wrote:
>
>>>
>>>> -Os for small size.
>>>
>>> Tried this one also now. The 3.15p GNAT don't have it. The 2014 GNAT
>>> still produces a 195 KB executable.
>>>
>>
>> Did you use the "strip unused sections" [or something similar] option for 
>> the linker?
>
> The OP might also want to look into gnatelim to see if using it could help 
> eliminate unusued code.

I would guess this is the "problem". Janus/Ada does this automatically 
(indeed, the Windows version doesn't even work without using it). Janus/Ada 
also avoids any tasking overhead in programs that don't declare a task. But 
Janus/Ada was designed for small program sizes; that's rarely a concern 
today.

> One could argue that the size of the "Hello, World" program isn't all that 
> important. The overhead might be large but if most of that overheard is 
> actually used in a realistically sized program, well, it's not really 
> overhead in that case.

Right. We used to use that argument when people complained about the 8K 
"Hello World" for Ada compared to some much smaller size for some other 
language that was less safe.

But these days, I don't try to argue about it much. Trivia that isn't 
related to one's uses of Ada is irrelevant, and the sorts of engineers that 
gravitate to power tools like Ada (and thus are the real customers for Ada) 
know not to care too much about irrelevant things. The people that worry too 
much about such things tend not to stick with Ada anyway, so spending too 
much effort discussing that isn't worth it.

                                           Randy.

Re: Size of linked program increasing with new version of GNAT.

[Randy Brukardt]

"Tony" <tony7@tele2.se> wrote in message 
news:4a5a3301-958b-41fd-9d1a-7ab35021daa0@googlegroups.com...
> On Friday, December 26, 2014 4:56:16 PM UTC+1, Simon Clubley wrote:
>> It would be interesting for the OP to run the binutils size command on
>> both executables and post the results.
>
> OK, GNAT 3.15p:
> C:\Tony\Ada_program\Tests>size hello.exe -A
> hello.exe  :
> section    size      addr
> .text    62428   4198400
> .data     2244   4263936
> .bss     21124   4268032
> .idata    2416   4292608
> Total    88212
>
> GNAT 2014:
> C:\Tony\Ada_program\Tests>size hello.exe -A
> hello.exe  :
> section      size      addr
> .text      133348   4198400
> .data        1092   4333568
> .rdata      15500   4337664
> .eh_fram    41432   4354048
> .bss        13892   4399104
> .idata       5112   4415488
> .CRT           52   4423680
> .tls           32   4427776
> Total      210460

As should be obvious, the tasking runtime for Ada 2005 and Ada 2012 is 
substantially more complex than that for Ada 95 alone. Since GNAT doesn't 
eliminate the tasking runtime (like Janus/Ada does), the program size is 
going to go up for every new Ada version (and probably every new compiler 
version, too). Even with Janus/Ada, the runtime tends to go up a bit with 
every version (more detailed messages for handling, additional capabilities 
for the heap, etc.)

But that's all irrelevant unless you are targetting a very small embedded 
system. In which case, you'd be better off with a compiler that was designed 
to target very small systems (hint, hint :-). Otherwise, there is so much 
memory available, and so much of the newer capabilities that are probably 
used in a real system, that there really isn't any point in worrying about 
it.

Now, if you have a reference set of programs that double in size, that might 
be relevant. (Lots of memory doesn't mean that it is completely free.) 
Otherwise, it matters about as much as the runtime performance on the old 
Byte Primes benchmark.

                                     Randy.

Re: Size of linked program increasing with new version of GNAT.

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Janus/Ada also avoids any tasking overhead in programs that don't
> declare a task.

GNAT does this too.

A main program with a null body, compiled with -O2 and stripped,
resulted in executable size 83540; replacing the 'null;' by 'delay 0.0'
raised that to 107116.

Re: Size of linked program increasing with new version of GNAT.

[Pascal Obry]

Le vendredi 26 décembre 2014 à 15:55 +0000, Simon Clubley a écrit : 
> Not all executables run on a desktop PC. If current versions of GNAT
> have increased the actual minimum executable size this may be of
> interest for embedded environments.

Well in that case looking at a Hello World program which is dragging a
good part of the Ada runtime is even worse :)

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Size of linked program increasing with new version of GNAT.

[Tony]

On Saturday, December 27, 2014 7:43:14 AM UTC+1, Simon Wright wrote:
> A main program with a null body, compiled with -O2 and stripped,
> resulted in executable size 83540;

I'd expect that program to be compiled into a single machine code return instruction.

I managed to create a 12 KB version of Hello-World, by excluding runtime and Ada.Text_Io and calling Win32 functions directly:

pragma No_Run_Time;
with System;
procedure Hello is

   function Writeconsole
      (Hconsoleoutput        : Integer;
      Lpbuffer               : System.Address;
      Nnumberofcharstowrite  : Integer;
      Lpnumberofcharswritten : Integer;
      Lpreserved             : Integer) return Integer;

   pragma Import (Stdcall, Writeconsole, "WriteConsoleA");

   function Getstdhandle (Nstdhandle : Integer) return Integer;

   pragma Import (Stdcall, Getstdhandle, "GetStdHandle");

   Std_Output_Handle : constant := -11;

   S : constant String := "Hello, World!" & Ascii.Lf;
   Dummy : Integer;

begin
   Dummy := Writeconsole(Getstdhandle(Std_Output_Handle), S'Address, S'Length, 0, 0);
end;

Re: Size of linked program increasing with new version of GNAT.

[Jean François Martinez]

On Friday, December 26, 2014 4:56:16 PM UTC+1, Simon Clubley wrote:
> On 2014-12-26, Pascal Obry  wrote:
> >
> > Since when "bigger size" means worse?
> >
> 
> When you need the resulting executable to fit in fixed size flash memory. :-)
> 

We are on x86.  Being bigger on does not necessarily mean it will be biger on another architecture particularly because we are speaking of executable size ie with inclusion of newer libraries and runtime.  For embedded you would use tailored ones.

Jean-François Martinez

Re: Size of linked program increasing with new version of GNAT.

[Simon Wright]

Tony <tony7@tele2.se> writes:

> I'd expect that program to be compiled into a single machine code
> return instruction.

And I expect it was.

A program's startup/shutdown code is likely to be pretty independent of
waht the program actually does, and will have a certain minimum size
appropriate to the platform. GNAT's minimum size depends on whether
tasking is involved or not.

Re: Size of linked program increasing with new version of GNAT.

[Randy Brukardt]

"Tony" <tony7@tele2.se> wrote in message 
news:db4a0ed9-d5e8-40ea-8def-0683c98584fb@googlegroups.com...
> On Saturday, December 27, 2014 7:43:14 AM UTC+1, Simon Wright wrote:
>> A main program with a null body, compiled with -O2 and stripped,
>> resulted in executable size 83540;
>
> I'd expect that program to be compiled into a single machine code return 
> instruction.
>
> I managed to create a 12 KB version of Hello-World, by excluding runtime 
> and
>Ada.Text_Io and calling Win32 functions directly:

So what?

(1) I created a 56KB executable by using Janus/Ada on a simple Hello world 
program using Text_IO. (Options: /zt/f).

(2) I could shrink that further to 38K by using RRText_IO instead of 
Text_IO. (Text_IO has lots of overhead from maintaining line and column 
counts that are almost never used; RRText_IO originated in our early CP/M 
compilers [the ones that had to run in 48K RAM - code and data] and is 
simpler but still has most of the useful capabilities.)

(3) But still, who cares? Im my experience with a variety of Ada compilers, 
there's no correlation between the minimum size of a program and the size of 
real programs. And programs that don't use at least some of exceptions, 
controlled types, tasks, floating point, images, and other expensive 
operations are hardly using Ada at all. The size of Hello world tells one 
very little about the size and efficiency of a real program.

                                   Randy.

Re: Size of linked program increasing with new version of GNAT.

[Björn Lundin]

On 2014-12-30 00:56, Randy Brukardt wrote:
> But still, who cares? Im my experience with a variety of Ada compilers,
> there's no correlation between the minimum size of a program and the size of 
> real programs. 


Indeed. For databases, the equivalent test is

'select count('a') from some_table;'

It is not very useful as a measurement either,
some dbs actually traverse the table,
and some has a cached counter.

But what you really want is good performance
(whatever that is) for real applications,
not a constructed example that has little or no relevance.


--
Björn

Re: Size of linked program increasing with new version of GNAT.

[Tony]

On Tuesday, December 30, 2014 12:56:43 AM UTC+1, Randy Brukardt wrote:
> The size of Hello world tells one 
> very little about the size and efficiency of a real program.

I have written about 600 Ada programs at home. The average size of the programs are 75 lines of code. I never use tasks. These are my real programs.

Re: Size of linked program increasing with new version of GNAT.

[Randy Brukardt]

"Tony" <tony7@tele2.se> wrote in message 
news:c702cb35-a051-4a0b-b7e7-41384fb487e3@googlegroups.com...
> On Tuesday, December 30, 2014 12:56:43 AM UTC+1, Randy Brukardt wrote:
>> The size of Hello world tells one
>> very little about the size and efficiency of a real program.
>
> I have written about 600 Ada programs at home. The average size of the 
> programs are 75 lines of code.
> I never use tasks. These are my real programs.

Really? I'm skeptical that you can do anything useful in 75 lines of code. 
After all, you can't even open a file properly in 75 lines of code. (That 
is, getting the name from the user or the command line, and with appropriate 
error handling.) About all you can do in that size is write a throw-away 
program, and by definition, one doesn't care too much about the "goodness" 
of the result of a throw-away program. (Plus, you're depending on the 
implementation-defined error handling in that case -- and that's hardly 
going to be free.)

If you are "with"ing a bunch of library packages to and using them in the 75 
lines, your real program size has to count the size of the libraries that 
you "with". Which is going to be a lot more than 75 lines.

> "I never use tasks."

Which eliminates ONE form of overhead. But one cannot (sensibly) write an 
Ada program that doesn't use exceptions (from implicit checks if nothing 
else - and you need the unhandled exception mechanisms); finalization is 
used by many of the language-defined packages; virtually every program needs 
the default storage pool; and so on.

Sigh. Why I am I feeding the troll here? Gosh knows.

                                 Randy.


                                                        Randy.

Re: Size of linked program increasing with new version of GNAT.

[Shark8]

On 30-Dec-14 14:58, Randy Brukardt wrote:
> Sigh. Why I am I feeding the troll here? Gosh knows.

To fatten him up?

Re: Size of linked program increasing with new version of GNAT.

[Jean François Martinez]

On Tuesday, December 30, 2014 12:56:43 AM UTC+1, Randy Brukardt wrote:
 The size of Hello world tells one 
> very little about the size and efficiency of a real program.
> 

Trying to bring some common sense in the discussion (not fr(om you Mr Brukardt)

If we intend is to measure the actual quality of the compiler at generating small code then the significtaive variable is the size of the .o file not the size of the executable.  The executable is parasited by things like runtime, libraries, dynamic linker (or first stage of dynamic linker) and so on.  So the more capable your environment and the biggest the program.  

So if the program is small and will run it on a half decent box you don't care. Remember the EEPC, that five years old laptop good for web surfing and little more?  It had 1G of memory. A million Ks.  So who cares about the size of hello world?

If your program has megs and megs of code then the overhead due to a more capable runtime will be completely irrelevant respective to the "pure" (that is .o) size of your program and third party (ie not related to Gnat) libraries.

If you have to squeeze your program on an Arduino then size matters but the maintainer of Gnat for Arduino has tuned the compiler default restrictions (gnat.adc), runtime and Gnat related libraries for small size so you can't draw conclusions basing on what you see on x86.   Still more irrelevant because it is different machine code thus a different code generator so a bigger .o on X86 does not necessarily translate on a bigger .o on Arduino.

Just my 2c

Jean-François Martinez

Re: Size of linked program increasing with new version of GNAT.

[Dmitry A. Kazakov]

On Wed, 31 Dec 2014 04:08:13 -0800 (PST), Jean François Martinez wrote:

> If we intend is to measure the actual quality of the compiler at
> generating small code then the significtaive variable is the size of the
> .o file not the size of the executable.

I remember a FORTRAN-IV compiler that generated direct and indirect code.
The latter was kind of interpreted, each code "instruction" was a jump to a
short subprogram implementing the semantics. The direct code was twice as
large than the indirect one and 50% faster. So, no, the size of object
files tells nothing.

> The executable is parasited by
> things like runtime, libraries, dynamic linker (or first stage of dynamic
> linker) and so on.

The code size can be approximated by a linear function A + B*x, where x is
the program "complexity". Arguments that A might be irrelevant is true only
if B is correspondingly small compared to the alternatives so that with
growing x you could compensate your losses on A.

Regarding GNAT, I doubt that B is really small, especially if generics are
actively used, and A is substantially big has we all know.

> So the more capable your environment and the biggest the program.

Which should be the opposite, actually, since you could get some
functionality from for the environment. 

The problem is that the ratio capability/useless-garbage is quite low in
modern environments and the trend is that it rapidly nears zero.

> So if the program is small and will run it on a half decent box you don't
> care. Remember the EEPC, that five years old laptop good for web surfing
> and little more?  It had 1G of memory. A million Ks.  So who cares about
> the size of hello world?

The empiric law of SW teaches us that any resource available will be
consumed. A more specialized law, which is a consequence of the former, is:
Windows is here to make i486 out of any i7.

> If your program has megs and megs of code then the overhead due to a more
> capable runtime will be completely irrelevant respective to the "pure"
> (that is .o) size of your program and third party (ie not related to Gnat)
> libraries.

Which code must be linked dynamically or else, on the systems without
virtual memory, loaded into to RAM. Thus large A usually directly
translates into longer starting times. The effect we all know, each new
system, each new version takes 20% more time to start.

The time a program needed to start is a good estimation of the product line
age. E.g. compare start times of:

Borland C++
MS Visual Studio
AdaCore GPS

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Size of linked program increasing with new version of GNAT.

[Georg Bauhaus]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 31 Dec 2014 04:08:13 -0800 (PST), Jean François Martinez wrote:

>> The executable is parasited by
>> things like runtime, libraries, dynamic linker (or first stage of dynamic
>> linker) and so on.
> 
> The code size can be approximated by a linear function A + B*x, where x is
> the program "complexity". Arguments that A might be irrelevant is true only
> if B is correspondingly small compared to the alternatives so that with
> growing x you could compensate your losses on A.

Executables' size also reflects technical needs: compressing an
executable program such as gnatmake shows ratios of
over one half on Intel. Chances are, then, that there is redundant
executable code in gnatmake. But there are reasons that there is,
I guess, because the optimizers make the processor perform better,
reflecting its sets of instructions and its architecture (parallel
pipelines etc.). When TIME is more important than SPACE
in order to meet timing requirements, greater code size might
seem paradoxical, but might be necessary.

Has anyone tried deduplication with executables?