* Size of linked program increasing with new version of GNAT. @ 2014-12-25 17:44 Tony 2014-12-25 17:57 ` Björn Lundin 2014-12-26 14:32 ` Pascal Obry 0 siblings, 2 replies; 27+ messages in thread From: Tony @ 2014-12-25 17:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 17:44 Size of linked program increasing with new version of GNAT Tony @ 2014-12-25 17:57 ` Björn Lundin 2014-12-25 18:36 ` tony7 2014-12-26 14:32 ` Pascal Obry 1 sibling, 1 reply; 27+ messages in thread From: Björn Lundin @ 2014-12-25 17:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 17:57 ` Björn Lundin @ 2014-12-25 18:36 ` tony7 2014-12-25 19:41 ` Björn Lundin 0 siblings, 1 reply; 27+ messages in thread From: tony7 @ 2014-12-25 18:36 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 18:36 ` tony7 @ 2014-12-25 19:41 ` Björn Lundin 2014-12-25 20:04 ` Shark8 2014-12-25 20:15 ` tony7 0 siblings, 2 replies; 27+ messages in thread From: Björn Lundin @ 2014-12-25 19:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 19:41 ` Björn Lundin @ 2014-12-25 20:04 ` Shark8 2014-12-25 20:15 ` tony7 1 sibling, 0 replies; 27+ messages in thread From: Shark8 @ 2014-12-25 20:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 19:41 ` Björn Lundin 2014-12-25 20:04 ` Shark8 @ 2014-12-25 20:15 ` tony7 2014-12-25 21:23 ` Shark8 1 sibling, 1 reply; 27+ messages in thread From: tony7 @ 2014-12-25 20:15 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 20:15 ` tony7 @ 2014-12-25 21:23 ` Shark8 2014-12-25 22:48 ` Peter Chapin 0 siblings, 1 reply; 27+ messages in thread From: Shark8 @ 2014-12-25 21:23 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 21:23 ` Shark8 @ 2014-12-25 22:48 ` Peter Chapin 2014-12-27 1:39 ` Randy Brukardt 0 siblings, 1 reply; 27+ messages in thread From: Peter Chapin @ 2014-12-25 22:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 22:48 ` Peter Chapin @ 2014-12-27 1:39 ` Randy Brukardt 2014-12-27 6:43 ` Simon Wright 0 siblings, 1 reply; 27+ messages in thread From: Randy Brukardt @ 2014-12-27 1:39 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-27 1:39 ` Randy Brukardt @ 2014-12-27 6:43 ` Simon Wright 2014-12-27 18:25 ` Tony 0 siblings, 1 reply; 27+ messages in thread From: Simon Wright @ 2014-12-27 6:43 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-27 6:43 ` Simon Wright @ 2014-12-27 18:25 ` Tony 2014-12-27 23:18 ` Simon Wright 2014-12-29 23:56 ` Randy Brukardt 0 siblings, 2 replies; 27+ messages in thread From: Tony @ 2014-12-27 18:25 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-27 18:25 ` Tony @ 2014-12-27 23:18 ` Simon Wright 2014-12-29 23:56 ` Randy Brukardt 1 sibling, 0 replies; 27+ messages in thread From: Simon Wright @ 2014-12-27 23:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-27 18:25 ` Tony 2014-12-27 23:18 ` Simon Wright @ 2014-12-29 23:56 ` Randy Brukardt 2014-12-30 15:21 ` Björn Lundin ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Randy Brukardt @ 2014-12-29 23:56 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-29 23:56 ` Randy Brukardt @ 2014-12-30 15:21 ` Björn Lundin 2014-12-30 17:45 ` Tony 2014-12-31 12:08 ` Jean François Martinez 2 siblings, 0 replies; 27+ messages in thread From: Björn Lundin @ 2014-12-30 15:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-29 23:56 ` Randy Brukardt 2014-12-30 15:21 ` Björn Lundin @ 2014-12-30 17:45 ` Tony 2014-12-30 21:58 ` Randy Brukardt 2014-12-31 12:08 ` Jean François Martinez 2 siblings, 1 reply; 27+ messages in thread From: Tony @ 2014-12-30 17:45 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-30 17:45 ` Tony @ 2014-12-30 21:58 ` Randy Brukardt 2014-12-30 23:51 ` Shark8 0 siblings, 1 reply; 27+ messages in thread From: Randy Brukardt @ 2014-12-30 21:58 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-30 21:58 ` Randy Brukardt @ 2014-12-30 23:51 ` Shark8 0 siblings, 0 replies; 27+ messages in thread From: Shark8 @ 2014-12-30 23:51 UTC (permalink / raw) On 30-Dec-14 14:58, Randy Brukardt wrote: > Sigh. Why I am I feeding the troll here? Gosh knows. To fatten him up? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-29 23:56 ` Randy Brukardt 2014-12-30 15:21 ` Björn Lundin 2014-12-30 17:45 ` Tony @ 2014-12-31 12:08 ` Jean François Martinez 2014-12-31 12:45 ` Dmitry A. Kazakov 2 siblings, 1 reply; 27+ messages in thread From: Jean François Martinez @ 2014-12-31 12:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-31 12:08 ` Jean François Martinez @ 2014-12-31 12:45 ` Dmitry A. Kazakov 2015-01-01 12:28 ` Georg Bauhaus 0 siblings, 1 reply; 27+ messages in thread From: Dmitry A. Kazakov @ 2014-12-31 12:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-31 12:45 ` Dmitry A. Kazakov @ 2015-01-01 12:28 ` Georg Bauhaus 0 siblings, 0 replies; 27+ messages in thread From: Georg Bauhaus @ 2015-01-01 12:28 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-25 17:44 Size of linked program increasing with new version of GNAT Tony 2014-12-25 17:57 ` Björn Lundin @ 2014-12-26 14:32 ` Pascal Obry 2014-12-26 15:48 ` J-P. Rosen 2014-12-26 15:55 ` Simon Clubley 1 sibling, 2 replies; 27+ messages in thread From: Pascal Obry @ 2014-12-26 14:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-26 14:32 ` Pascal Obry @ 2014-12-26 15:48 ` J-P. Rosen 2014-12-26 15:55 ` Simon Clubley 1 sibling, 0 replies; 27+ messages in thread From: J-P. Rosen @ 2014-12-26 15:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-26 14:32 ` Pascal Obry 2014-12-26 15:48 ` J-P. Rosen @ 2014-12-26 15:55 ` Simon Clubley 2014-12-26 20:14 ` Tony ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Simon Clubley @ 2014-12-26 15:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-26 15:55 ` Simon Clubley @ 2014-12-26 20:14 ` Tony 2014-12-27 1:48 ` Randy Brukardt 2014-12-27 9:35 ` Pascal Obry 2014-12-27 21:17 ` Jean François Martinez 2 siblings, 1 reply; 27+ messages in thread From: Tony @ 2014-12-26 20:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-26 20:14 ` Tony @ 2014-12-27 1:48 ` Randy Brukardt 0 siblings, 0 replies; 27+ messages in thread From: Randy Brukardt @ 2014-12-27 1:48 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-26 15:55 ` Simon Clubley 2014-12-26 20:14 ` Tony @ 2014-12-27 9:35 ` Pascal Obry 2014-12-27 21:17 ` Jean François Martinez 2 siblings, 0 replies; 27+ messages in thread From: Pascal Obry @ 2014-12-27 9:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Size of linked program increasing with new version of GNAT. 2014-12-26 15:55 ` Simon Clubley 2014-12-26 20:14 ` Tony 2014-12-27 9:35 ` Pascal Obry @ 2014-12-27 21:17 ` Jean François Martinez 2 siblings, 0 replies; 27+ messages in thread From: Jean François Martinez @ 2014-12-27 21:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2015-01-01 12:28 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-25 17:44 Size of linked program increasing with new version of GNAT Tony 2014-12-25 17:57 ` Björn Lundin 2014-12-25 18:36 ` tony7 2014-12-25 19:41 ` Björn Lundin 2014-12-25 20:04 ` Shark8 2014-12-25 20:15 ` tony7 2014-12-25 21:23 ` Shark8 2014-12-25 22:48 ` Peter Chapin 2014-12-27 1:39 ` Randy Brukardt 2014-12-27 6:43 ` Simon Wright 2014-12-27 18:25 ` Tony 2014-12-27 23:18 ` Simon Wright 2014-12-29 23:56 ` Randy Brukardt 2014-12-30 15:21 ` Björn Lundin 2014-12-30 17:45 ` Tony 2014-12-30 21:58 ` Randy Brukardt 2014-12-30 23:51 ` Shark8 2014-12-31 12:08 ` Jean François Martinez 2014-12-31 12:45 ` Dmitry A. Kazakov 2015-01-01 12:28 ` Georg Bauhaus 2014-12-26 14:32 ` Pascal Obry 2014-12-26 15:48 ` J-P. Rosen 2014-12-26 15:55 ` Simon Clubley 2014-12-26 20:14 ` Tony 2014-12-27 1:48 ` Randy Brukardt 2014-12-27 9:35 ` Pascal Obry 2014-12-27 21:17 ` Jean François Martinez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox