* GNAT Executables: How low can you go? @ 1996-04-13 0:00 Geert Bosch 1996-04-13 0:00 ` Robert Dewar 1996-04-17 0:00 ` Cordes MJ 0 siblings, 2 replies; 29+ messages in thread From: Geert Bosch @ 1996-04-13 0:00 UTC (permalink / raw) Boring stuff ~~~~~~~~~~~~ Last week I've done a rewrite of a full featured regular expression matcher (the one that comes with EMX) for Ada. The C-version was awkward to use because of the need of a terminating NUL character, bad error handling and use of global variables which makes tasking nearly impossible. The final RE matcher is 55 kB of source (I guess just 15% comments) and 1600 lines and doesn't need dynamic memory allocation. This is better... ~~~~~~~~~~~~~~~~~ Using GNAT v3.01 for OS/2 and default compilation, but with optimizations on and checks suppressed resulted in an executable of 114 kB which ran about 3 times as slow as the C version. Now with some tweaking the source has changed a little (about 20 lines were modified) and now the code is just 15-20% slower than the C version which is not bad considering the extra robustness and safety. And now the GOOD news! ~~~~~~~~~~~~~~~~~~~~~~ The complete application which also produces debug information about the regular expression and which dumps the complete statusmachine in human-readable format is only 11616 bytes in size!!! I really didn't know GNAT executables could be this small and I even used string slices, exception handlers, discriminated records containing variable-sized arrays and text-io on integers, booleans and enumeration types. There was no 'dead' code in the source and all generated code and message strings are in the 11616 byte executable. Of course I'll explain the tricks later but it's already late now. I just had to let you know how great GNAT really is. ;-) ;-) Regards, Geert Bosch -- E-Mail: geert@sun3.iaf.nl *** As far as we know, there have not been *** Phone: +31-53-4303054 ** any undetected failures in our software. ** ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-13 0:00 GNAT Executables: How low can you go? Geert Bosch @ 1996-04-13 0:00 ` Robert Dewar 1996-04-16 0:00 ` Geert Bosch 1996-04-17 0:00 ` Cordes MJ 1 sibling, 1 reply; 29+ messages in thread From: Robert Dewar @ 1996-04-13 0:00 UTC (permalink / raw) Geert said "The complete application which also produces debug information about the regular expression and which dumps the complete statusmachine in human-readable format is only 11616 bytes in size!!! I really didn't know GNAT executables could be this small and I even used string slices, exception handlers, discriminated records containing variable-sized arrays and text-io on integers, booleans and enumeration types. There was no 'dead' code in the source and all generated code and message strings are in the 11616 byte executable." I of course like to see positive posts about GNAT like this, but surely that figure of 11,616 is wrong, I could believe 116K, but 12K must be wrong, especially if you are using statically linked libraries. Text_IO alone is larger than this. Can you double check your numbers .... ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-13 0:00 ` Robert Dewar @ 1996-04-16 0:00 ` Geert Bosch 1996-04-16 0:00 ` Theodore E. Dennison 0 siblings, 1 reply; 29+ messages in thread From: Geert Bosch @ 1996-04-16 0:00 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote: : I of course like to see positive posts about GNAT like this, but surely : that figure of 11,616 is wrong, I could believe 116K, but 12K must : be wrong, especially if you are using statically linked libraries. : Text_IO alone is larger than this. But I didn't say I linked the runtime libraries static ;-) All the application code, the regexp library and the necessary headers/stub fits in 12K. The smallest I could get with statical linking was 52 kB. But since most C apps use emx.dll and emxlibc.dll, why couldn't Ada apps not use a dll? I put *all* of the GNARL code (700 kB of .o files) in one 250 kB dll and link all apps against that. This is a really good way of avoiding those bloated executables we see otherwise. : Can you double check your numbers? Yes, I did so before posting my previous article. You should also note that the dynamically linked GNAT Runtime Libraries (GNATLIB.DLL) and my own apps have been compressed using LXLite. The compressed GNAT1.EXE (about half the size of the original GNAT1.EXE) seems to load even faster when not using EMXLoad. When EMXLoad is used the times don't differ. Of course I also used LINK386 instead of ld, since it seams to produce much smaller executables. Still, even considered all tricks, 12 kB for the application code including all regexp code and the necessary .EXE headers is very little, I think. Regards, Geert PS. My newsfeed seems to be broken, so please send a copy of any follow-ups to geert@sun3.iaf.nl. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-16 0:00 ` Geert Bosch @ 1996-04-16 0:00 ` Theodore E. Dennison 1996-04-16 0:00 ` Robert Dewar 1996-04-17 0:00 ` Geert Bosch 0 siblings, 2 replies; 29+ messages in thread From: Theodore E. Dennison @ 1996-04-16 0:00 UTC (permalink / raw) Cc: geert Geert Bosch wrote: > > But I didn't say I linked the runtime libraries static ;-) All the > application code, the regexp library and the necessary headers/stub > fits in 12K. The smallest I could get with statical linking was 52 kB. > > But since most C apps use emx.dll and emxlibc.dll, why couldn't Ada > apps not use a dll? I put *all* of the GNARL code (700 kB of .o files) > in one 250 kB dll and link all apps against that. This is a really good > way of avoiding those bloated executables we see otherwise. Of course you realize that unless you have other applications running simultaniously on the system using those DLL's, you havent gained anything. You've just split your executable into several files. All the bytes are still there. I suppose it might save a few K of disk space, but with 1 gigabyte harddrives coming with most PC's these days, I certainly don't care about a couple hundred K of disk space. I could clean out several hundred times that just by deleting the files in my web browser's temp directory. > PS. My newsfeed seems to be broken, so please send a copy of any > follow-ups to geert@sun3.iaf.nl. (done) -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-16 0:00 ` Theodore E. Dennison @ 1996-04-16 0:00 ` Robert Dewar 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-17 0:00 ` Geert Bosch 1 sibling, 1 reply; 29+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) T.E.D says "Of course you realize that unless you have other applications running simultaniously on the system using those DLL's, you havent gained anything. You've just split your executable into several files. All the bytes are still there." That completely misses the biggest value of DLL's, which is that they stay loaded as you load subsequent applications. Suppose you have a 2 meg DLL and 30 successive small executables that are loaded. This will be MUCH more efficient than loading 30 successive 2 meg executables. DLL's are useful in improving performance even if there is never a case of simultaneous use. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-16 0:00 ` Robert Dewar @ 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` Robert Dewar 1996-04-18 0:00 ` John Howard 0 siblings, 2 replies; 29+ messages in thread From: Theodore E. Dennison @ 1996-04-18 0:00 UTC (permalink / raw) Robert Dewar wrote: > > T.E.D says > > "Of course you realize that unless you have other applications running > simultaniously on the system using those DLL's, you havent gained > anything. You've just split your executable into several files. All > the bytes are still there." > > That completely misses the biggest value of DLL's, which is that they > stay loaded as you load subsequent applications. Suppose you have a > 2 meg DLL and 30 successive small executables that are loaded. This > will be MUCH more efficient than loading 30 successive 2 meg executables. > DLL's are useful in improving performance even if there is never a case > of simultaneous use. Well....actually no, that doesn't miss that value. If you read the text you quoted, it says, "...unless you have other applications running simultaniously on the system using those DLL's..." -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Theodore E. Dennison @ 1996-04-18 0:00 ` Robert Dewar 1996-04-19 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` John Howard 1 sibling, 1 reply; 29+ messages in thread From: Robert Dewar @ 1996-04-18 0:00 UTC (permalink / raw) T.E.D. says (replying to me) "> That completely misses the biggest value of DLL's, which is that they > stay loaded as you load subsequent applications. Suppose you have a > 2 meg DLL and 30 successive small executables that are loaded. This > will be MUCH more efficient than loading 30 successive 2 meg executables. > DLL's are useful in improving performance even if there is never a case > of simultaneous use. Well....actually no, that doesn't miss that value. If you read the text you quoted, it says, "...unless you have other applications running simultaniously on the system using those DLL's..."" Ted, you missed it again!!!! The point is that DLL's are valuable even if the applications do NOT run simultaneously. Read my paragraph again, the key word is successive, i.e. non-simultaneous! ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Theodore E. Dennison 0 siblings, 0 replies; 29+ messages in thread From: Theodore E. Dennison @ 1996-04-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Ted, you missed it again!!!! > > The point is that DLL's are valuable even if the applications do NOT > run simultaneously. Read my paragraph again, the key word is successive, > i.e. non-simultaneous! Ahhh. So you are saying that when all its applications terminate, the DLL isn't nessecarily unloaded? That's clever. Although in practice, I'd bet it gets unloaded or swapped out pretty quickly. You can't just keep every DLL that ever got opened since the machine was booted in memory forever; you'd run out of memory space pretty quickly. However, this would make DLLs a very good approach for running a series of executables that all use a lot of the same routines (eg: the "unix-like" commands that were mentioned previously in this thread, with the GNAT runtime in a DLL). I sense an "Emily Latella" comming on. (What's all this I hear about "Firing the Handicapped"?) -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` Robert Dewar @ 1996-04-18 0:00 ` John Howard 1996-04-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 29+ messages in thread From: John Howard @ 1996-04-18 0:00 UTC (permalink / raw) On Thu, 18 Apr 1996, Theodore E. Dennison wrote: > Robert Dewar wrote: > > > > T.E.D says > > > > "Of course you realize that unless you have other applications running > > simultaniously on the system using those DLL's, you havent gained > > anything. You've just split your executable into several files. All > > the bytes are still there." > > > > That completely misses the biggest value of DLL's, which is that they > > stay loaded as you load subsequent applications. Suppose you have a > > 2 meg DLL and 30 successive small executables that are loaded. This > > will be MUCH more efficient than loading 30 successive 2 meg executables. > > DLL's are useful in improving performance even if there is never a case > > of simultaneous use. > > Well....actually no, that doesn't miss that value. If you read the > text you quoted, it says, "...unless you have other applications running > simultaniously on the system using those DLL's..." > -- > T.E.D. You can gain by saving on time to load the program and DLL's. The decoding and expansion of a compressed file in memory might beat the time it takes to access a slow I/O device for the uncompressed original file. Executables typically are loaded once per session. Comparing the single load time of the uncompressed form against the single load time of the compressed form will accurately indicate if an executable should be distributed in compressed form. DLL's can be either reloaded or shared by multiple processes. Complications come from not being able to predict or control the cost of reloading a DLL. Generally, large DLL's will be compressed to save storage space at the expense of adding a decoding time component to the load time. A smaller uncompressed file is quicker to load during load time. A compressed file may or may not be quicker to load during load time -- you have to add in the decode time to know. Do not repeatedly decode the same DLL unless it is unavoidable. For example, a main program can repeatedly yet rarely demand a resource DLL which was loaded earlier and given a high priority by the operating system but later unloaded due to becoming a low priority. Sometimes a programmer is allowed enough control to have the operating system lock their DLL in a memory space so that only a single decode is necessary. ------------------------------------------------------------------------ -- John Howard <jhoward@sky.net> -- Team Ada Team OS/2 -- -- -- Keramos -- ------------------------------------------------------------------------ Psalm 22:30-31 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` John Howard @ 1996-04-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 29+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) John Howard replied to T.E.D.'s comments on DLL's: "You can gain by saving on time to load the program and DLL's. The decoding and expansion of a compressed file in memory might beat the time it takes to access a slow I/O device for the uncompressed original file." OOPS! This is mixing up two threads. Let's separate them clearly: 1. The issue of compressing exe's and dll's 2. The issue of creating the dll's in the first place (that is what T.E.D's message was addressing. What you said is right, but is not relevant to Ted's point. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-16 0:00 ` Theodore E. Dennison 1996-04-16 0:00 ` Robert Dewar @ 1996-04-17 0:00 ` Geert Bosch 1996-04-17 0:00 ` Michael F Brenner ` (2 more replies) 1 sibling, 3 replies; 29+ messages in thread From: Geert Bosch @ 1996-04-17 0:00 UTC (permalink / raw) On Tue, 16 Apr 1996, Theodore E. Dennison wrote: > Of course you realize that unless you have other applications running > simultaniously on the system using those DLL's, you havent gained > anything. You've just split your executable into several files. All > the bytes are still there. I didn't expect to have to defend why small executables are an advantage, but I'll try to list some reasons: * Disk space: typical combined savings of using dynamic linking with the GNAT RTL, using LINK386 instead of ld and using compression are are in the 100-350 kB per executable. I've got 95 GNAT executables, which is good for a saving of 10 - 30 MB. (The 250 kB of the DLL doesn't really matter.) So, you don't save a few kB, but you'll save MB's. (Even with just 10 executables you might save a few MB. * I don't want my utility to be 10x as big as one written in C (Most C programmers use the emx DLL's) If I wrote a bunch of Unix-like commands for OS/2 using Ada and they would be 100-200kB each, nobody would use my Unix utilities. On the other hand, if they would be 10-20kB each, but you'd need the 250 kB GNAT RTL everybody would think that would be reasonable, esp. when you explain that DLL is the emxlibc equivalent for Ada. So, not being able to create tiny executables hinders the acceptance of Ada as a language for small programs. Most people who don't know Ada, associate Ada with an old, large bloated programming language which can only be used to write large and boring applications which manifest themselves as bloated executables. When my little utilities are 100-200 kB each, I don't have the slighest chance of getting the language (or the applications produced by it) accepted: I'd only reconfirm the perception of Ada as large and bloated. I know these are not purely technical reasons, but people don't just at technical issues. When an Ada program is 10 times as large as a C program, people will expect the Ada program to be 10 times as slow. * In practise, on multitasking systems there will be many applications using the same DLL's. If only the GNAT system with all utilities would have been dynamically linked, this would save a lot of disk space and memory space when you're using emxload. * It is much easier to upgrade/improve the RTL without having to rebuild the world. Of course measures need to be taken to ensure that the interface doesn't change. For the RTL this shouldn't be much of a problem. Actually this last point was the reason for me to try to dynamically linke the RTL. That way I could easily switch between the standard implementation and my (still experimental) RTL using garbage collection. Regards, Geert E-Mail: geert@sun3.iaf.nl *** As far as we know, there have not been *** Phone: +31-53-4303054 ** any undetected failures in our software. ** ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-17 0:00 ` Geert Bosch @ 1996-04-17 0:00 ` Michael F Brenner 1996-04-18 0:00 ` Geert Bosch ` (2 more replies) 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Fergus Henderson 2 siblings, 3 replies; 29+ messages in thread From: Michael F Brenner @ 1996-04-17 0:00 UTC (permalink / raw) There is no need to justify tiny executables, 140K is a Bloated hello-world. Would it be possible to post the commands you used to build the DLL so we could all have tiny executables? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-17 0:00 ` Michael F Brenner @ 1996-04-18 0:00 ` Geert Bosch 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-26 0:00 ` Geert Bosch 2 siblings, 0 replies; 29+ messages in thread From: Geert Bosch @ 1996-04-18 0:00 UTC (permalink / raw) Michael F Brenner (mfb@mbunix.mitre.org) wrote: `` There is no need to justify tiny executables, 140K is a Bloated hello-world. Would it be possible to post the commands you used to build the DLL so we could all have tiny executables? '' I would have posted them already, but my PC is in repair at the moment. Hopefully I'll be able to post a complete description, including some make scripts, in the weekend. Greetings, Geert -- E-Mail: geert@sun3.iaf.nl *** As far as we know, there have not been *** Phone: +31-53-4303054 ** any undetected failures in our software. ** ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-17 0:00 ` Michael F Brenner 1996-04-18 0:00 ` Geert Bosch @ 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Geert Bosch ` (2 more replies) 1996-04-26 0:00 ` Geert Bosch 2 siblings, 3 replies; 29+ messages in thread From: Theodore E. Dennison @ 1996-04-18 0:00 UTC (permalink / raw) Michael F Brenner wrote: > > There is no need to justify tiny executables, 140K is a Bloated hello-world. Its still 140K, just in two different files. (sigh) I guess I'm alone in thinking this is just "re-arranging the deck chairs"? -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Theodore E. Dennison @ 1996-04-19 0:00 ` Geert Bosch 1996-04-19 0:00 ` Robert Dewar 1996-04-26 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 29+ messages in thread From: Geert Bosch @ 1996-04-19 0:00 UTC (permalink / raw) Theodore E. Dennison (dennison@escmail.orl.mmc.com) wrote: `` I guess I'm alone in thinking this is just "re-arranging the deck chairs"? '' Maybe. Please note that memory requirements drop dramatically for the second and later apps that run concurrently. Or do you say, typical modern systems have so much RAM and such low paging rates that it doesn't matter if an application needs 200 kB RAM instead of 20? My impression (I've not found a way of precisely measuring this yet) is that the stripped down executables have a much reduces start time. Because loaded DLL's are only discarded when there is no free RAM left and apps that terminate result in free memory, there's a good chance that a subsequently loaded executable can reuse the already loaded DLL. In my test application it would be the difference between loading 116 kB or 12 kB. Maybe you're thinking in terms of large applications and if that's the case I agree with you. For a 3 MB executable it won't matter much if it could be 2.5 MB when linked dynamically. My point, which I think is valid, is that for small programs the factor 10 increase of program size has a negative impact on performance and disk storage. For small applications that use relatively much library code, like GUI based programs, the situation is totally different. If the Sun-3 system I use right now wouldn't use dynamically linked libraries almost everywhere, it would be impossible to have 3 users on the system running a total of 30 X-Windows applications. I've used a couple of X applications that had a statically linked GUI library for some time (chimera and xmh for example) but after recompiling them using dynamically linked libraries they cause much less paging. I do not know any modern Unix systems that use a statically linked libc for applications other than those needed for single user mode (mount, sh etc). Also notice that GNAT requires dynamically linked libraries by default: the EMX run-time system uses DLL's and all OS/2 API's are implemented as DLL's. On the platform I was talking about (OS/2) DLL's are used all over the place and I can find no good reason for regular GNAT applications to be partially statically linked, resulting in a slower and larger program than possible. When you still think that dynamic linking is just re-aranging the desk chairs, I'll try to find some pointers to relevant literature for you. I don't think it's very useful to continue this discussing such a well-established technology as dynamic linking in comp.lang.ada, when your objections against dynamic linking are general, not just related to implementations of Ada. Regards, Geert -- E-Mail: geert@sun3.iaf.nl *** As far as we know, there have not been *** Phone: +31-53-4303054 ** any undetected failures in our software. ** ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Geert Bosch @ 1996-04-19 0:00 ` Robert Dewar 1996-04-26 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 29+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) T.E.D. says "I guess I'm alone in thinking this is just "re-arranging the deck chairs"?" Well you may not be alone, there may be others who share this incorrect view. Putting the Ada runtime into a DLL will generally improve system performance if you are running Ada programs, whether or not they are run simultaneously. It is an excellent idea to put the Ada library into a DLL. The SGI version has been distributed this way for a while, and we definitely plan to make this kind of distribution standard, since it will result in smaller executables, faster execution (since the RTL object code does not have to be linked and copied), and faster execution (since the RTL object code is more likely to be preloaded in memory). It's a win all round. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Geert Bosch 1996-04-19 0:00 ` Robert Dewar @ 1996-04-26 0:00 ` Richard A. O'Keefe 1996-04-29 0:00 ` Theodore E. Dennison 1996-04-30 0:00 ` mjp 2 siblings, 2 replies; 29+ messages in thread From: Richard A. O'Keefe @ 1996-04-26 0:00 UTC (permalink / raw) "Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes: >Michael F Brenner wrote: >> >> There is no need to justify tiny executables, 140K is a Bloated hello-world. >Its still 140K, just in two different files. Wrong. Suppose the library is 120 k and the application, minus library, is 20k. - static linking: you get 140k in your program AND YOU STILL HAVE THE LIBRARY so you have one 120k file and one 140k file - dynamic linking you have one one 120k file and one 20k file. The model I have here is someone developing on a UNIX box; I can't throw away the original copy of the (statically linked) library just because I have compiled one program! Come to think of it, the same is true with DOS compilers: just because I've compiled one program doesn't mean I can throw the library away. 1. Development time. Dynamic linking saves space _even with only one program_. (In this example, 140k -vs- 260k.) 2. Shipping. Any dynamic library that doesn't come standard with the operating system has to be shipped with the program that uses it. Shipping the DLL with the EXE may take _more_ space than shipping the statically linked version, because the DLL includes things that this particular EXE may not need. However, if the shipping package includes several applications using the same DLL, only one copy is needed, and it's really quite common to have several applications in one package. (DOS example: command line compiler, IDE compiler, linker.) 3. Installation. The user only has to install *one* copy of the DLL; the installation process has to recognise whether the DLL has already been installed. 4. Run time. The DLL will be loaded only once no matter how many applications are using it (UNIX "shared" libraries), and may, depending on the operating system, be kept around for a little while after the last application using it has quit so that it doesn't need reloading (like the old UNIX "save text" bit). -- Abigail Ruth, born 8 April 1996, 7lbs, wonderful! Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-26 0:00 ` Richard A. O'Keefe @ 1996-04-29 0:00 ` Theodore E. Dennison 1996-04-30 0:00 ` mjp 1 sibling, 0 replies; 29+ messages in thread From: Theodore E. Dennison @ 1996-04-29 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > - static linking: > you get 140k in your program AND YOU STILL HAVE THE LIBRARY > so you have one 120k file and one 140k file > > - dynamic linking > you have one one 120k file and one 20k file. > OK. You definitely have a point there... -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-26 0:00 ` Richard A. O'Keefe 1996-04-29 0:00 ` Theodore E. Dennison @ 1996-04-30 0:00 ` mjp 1 sibling, 0 replies; 29+ messages in thread From: mjp @ 1996-04-30 0:00 UTC (permalink / raw) ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: >4. Run time. > The DLL will be loaded only once no matter how many applications are > using it (UNIX "shared" libraries), and may, depending on the operating > system, be kept around for a little while after the last application > using it has quit so that it doesn't need reloading (like the old UNIX > "save text" bit). Also remember that although the DLL may be 120K, a decent operating system will only load those pages actually needed by your program (and other programs sharing the library) into paged real memory. My complaint about DLLs, is the poor way they are installed by most off the shelf products. E.g. Microsoft office. It asks where you want to put Microsoft office and I say my extra drive D:, I niavely assume thats where it put it. But it put the DLL on my boot E: drive, so when I come along to install a new rev of the os, Easiest by reformating the e: drive it will break M$ office. I discovered this "feature" when I had a disc corruption on my boot drive and had to reinstall the OS. -- On Australia is prohibited from redistributing this document in any way Dr Michael Pilling Phone: +61 8 259 7017 DSTO ITD/SE 171 Labs Fax: +61 8 259 5589 PO Box 1500, Salisbury SA 5108, Australia Michael.Pilling@dsto.defence.gov.au ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-17 0:00 ` Michael F Brenner 1996-04-18 0:00 ` Geert Bosch 1996-04-18 0:00 ` Theodore E. Dennison @ 1996-04-26 0:00 ` Geert Bosch 2 siblings, 0 replies; 29+ messages in thread From: Geert Bosch @ 1996-04-26 0:00 UTC (permalink / raw) Michael F Brenner (mfb@mbunix.mitre.org) wrote: `` There is no need to justify tiny executables, 140K is a Bloated hello-world. Would it be possible to post the commands you used to build the DLL so we could all have tiny executables? '' OK, it has been delayed a little because I couldn't work on it last week, but I've tried to reproduce all commands I had used to generate the DLL and the applications. That part turned out to be harder than I thought, and at first there were also problems because of bugs in the emximp and emxexp utilities. For the GNAT examples generated by /emx/gnat/examples/examples.cmd the old size is 800 kB, the new soze is 28 kB for the examples, plus 240 kB for the DLL. I put the command to generate the DLL in a makefile. Because of the many e-mails I got, I thought it would be appropriate to post the files to comp.lang.ada. To prevent problems with the tabs etc. in the makefiles, I zipped and uuencoded them. The total data is just 150 lines, I hope nobody has problems with this small binary. Let me here of any success or problems you have with the software. Note that only very little testing has been done: I've not done any multitasking tests and I don't have by any means a standard emx installation, so there might be installation problems. Regards, Geert begin 640 gnatdll.zip <uuencoded_portion_removed> ;<"YC;6102P4& D "0#U 0 C1< end -- E-Mail: geert@sun3.iaf.nl *** As far as we know, there have not been *** Phone: +31-53-4303054 ** any undetected failures in our software. ** ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-17 0:00 ` Geert Bosch 1996-04-17 0:00 ` Michael F Brenner @ 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` Robert Dewar ` (2 more replies) 1996-04-19 0:00 ` Fergus Henderson 2 siblings, 3 replies; 29+ messages in thread From: Theodore E. Dennison @ 1996-04-18 0:00 UTC (permalink / raw) Geert Bosch wrote: > > On Tue, 16 Apr 1996, Theodore E. Dennison wrote: > > Of course you realize that unless you have other applications running > > simultaniously on the system using those DLL's, you havent gained > > anything. You've just split your executable into several files. All > > the bytes are still there. >I didn't expect to have to defend why small executables are an >advantage, but I'll try to list some reasons: I think you misunderstand me. I'm not saying small /= good. I'm just saying: o if your DLL isn't reused, you have gained nothing o there are WAY better things to worry about (on a PC) than executable size. > * Disk space: typical combined savings of using dynamic linking with > the GNAT RTL, using LINK386 instead of ld and using compression are > are in the 100-350 kB per executable. I've got 95 GNAT > executables, which is good for a saving of 10 - 30 MB. (The 250 kB OK. So your "extreme case" leaves me with a situation where the sum total of the size of my exectuables takes up about 3% of my typical 1 Gig hard disk. I'm not impressed. Again, I'll bet my "temp" directory for Webexplorer has more than 30 MB of files in it. > * I don't want my utility to be 10x as big as one written in C > (Most C programmers use the emx DLL's) If we were talking embedded system, fine. But we're talking OS/2 systems here. OS/2 platforms are PCs, which these days come with oodles of hard disk space. In such an environment, executable size just isn't a real concern. I want programs to be robust, not squeezed. > If I wrote a bunch of Unix-like commands for OS/2 using Ada and > they would be 100-200kB each, nobody would use my Unix utilities. > On the other hand, if they would be 10-20kB each, but you'd need > the 250 kB GNAT RTL everybody would think that would be reasonable, Actually, I'd bet you are wrong here. I personally HATE getting utilities, only to discover that they won't work because they are missing some RTL. I'd much rather get a stand-alone application, especially when we are talking unix-like utilities which are typically NOT run simultaniously. It really annoys me when I have to fuss with some stupid DLL that is only used by this ONE program I have. > executables. When my little utilities are 100-200 kB each, I don't > have the slighest chance of getting the language (or the > applications produced by it) accepted: I'd only reconfirm the > perception of Ada as large and bloated. So what you are saying is this is a marketing issue? Again, I don't believe you here. I don't bat an eylash at any executable less than one MEG. If someone raises nonsense such as executable size as argument against Ada, you're just wasting your time trying to placate them. They will just keep shifting their argument, becuase the real problem isn't executable size, its that its not C. Don't even bother. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Theodore E. Dennison @ 1996-04-18 0:00 ` Robert Dewar 1996-04-19 0:00 ` Norman H. Cohen 1996-04-20 0:00 ` Al Christians 2 siblings, 0 replies; 29+ messages in thread From: Robert Dewar @ 1996-04-18 0:00 UTC (permalink / raw) T.E.D. says "Actually, I'd bet you are wrong here. I personally HATE getting utilities, only to discover that they won't work because they are missing some RTL. I'd much rather get a stand-alone application, especially when we are talking unix-like utilities which are typically NOT run simultaniously. It really annoys me when I have to fuss with some stupid DLL that is only used by this ONE program I have." I strongly disagree. It is perfectly reasonable to distribute a program as an executable and set of DLL's. Of course the installation procedure in such a case should arrange to handle the installation of the DLL's conveniently. Ted, I really think you underestimtae the performance value of DLL's. For example, it is VERY valuable that EPM uses an underlying DLL. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Norman H. Cohen 1996-04-19 0:00 ` Theodore E. Dennison 1996-04-20 0:00 ` Al Christians 2 siblings, 1 reply; 29+ messages in thread From: Norman H. Cohen @ 1996-04-19 0:00 UTC (permalink / raw) In article <317688E9.2781E494@escmail.orl.mmc.com>, "Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes: |> If we were talking embedded system, fine. But we're talking OS/2 |> systems here. OS/2 platforms are PCs, which these days come with |> oodles of hard disk space. In such an environment, executable size |> just isn't a real concern. I want programs to be robust, not squeezed. 1. That's a very narrow view of the world. Don't forget about small, portable PDA-like or tablet-based devices, with much more constrained hard disk space. 2. What does robustness have to do with it? We're not talking about programmers cutting corners to save space, but about a compiler doing its job well. 3. You describe a typical end-user environment, in which executables consume 3% of your disk space. However, in a development environment, there are projects that fill up disks with executables, requiring the expenditure of more money to buy more disks. (Indeed, as I write this, my OS/2 machine is busy doing a low-level format of the new 2.25GB disk I installed yesterday, for just this reason.) If you are planning a large project with thousands of files, a compiler producing executables ten times as large as necessary costs real money. There are other considerations in favor of compact code as well. To the extent that the size of the executable reflects the size of the object code itself, more compact code means faster loading and fewer I-cache misses, resulting in faster execution. For an Ada-to-Java-bytecode compiler, more compact code means faster transmission of an applet over the web. |> So what you are saying is this is a marketing issue? |> |> Again, I don't believe you here. I don't bat an eylash at any |> executable less than one MEG. If someone raises nonsense such as |> executable size as argument against Ada, you're just wasting your |> time trying to placate them. They will just keep shifting their |> argument, becuase the real problem isn't executable size, its that |> its not C. Don't even bother. This is nonsense. Someone who comes to the table without any prejudices about Ada is sure to walk away with a negative impression if he sees executables an order of magnitude larger than those produced using C. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-19 0:00 ` Norman H. Cohen @ 1996-04-19 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Robert Dewar 0 siblings, 1 reply; 29+ messages in thread From: Theodore E. Dennison @ 1996-04-19 0:00 UTC (permalink / raw) Norman H. Cohen wrote: > > In article <317688E9.2781E494@escmail.orl.mmc.com>, > "Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes: > > 1. That's a very narrow view of the world. Don't forget about small, > portable PDA-like or tablet-based devices, with much more constrained > hard disk space. Fair enough. I don't know how many OS/2 "PDA-like or tablet-based devices" there are out there, but they would have this concern. > 2. What does robustness have to do with it? We're not talking about > programmers cutting corners to save space, but about a compiler > doing its job well. That wasn't my impression. My impression (I think supported by the thread title of "How low can you go?") was that we were talking about space for space's sake. > 3. You describe a typical end-user environment, in which executables > consume 3% of your disk space. However, in a development environment, > there are projects that fill up disks with executables, requiring the For a development system, you will obviously have to have a signifigantly larger amout of hard-drive space than your target platform. You'll need that just to support the compilers, gui builders, bitmap editors, etc. I think the argument scales. > This is nonsense. Someone who comes to the table without any prejudices > about Ada is sure to walk away with a negative impression if he sees > executables an order of magnitude larger than those produced using C. Typically, when I go looking for a utility for my OS/2 system on the net, and I find two that preport to do the job (based on a comparison of their README's, or whatever), I compare their sizes and download the LARGER one. The reasoning here is that the larger one is very likely the more fully-featured and/or the more mature of the two. As to the "Hello World" issue: Anyone who TRULY had no prejudices wouldn't give a s**t how small the compiler makes an program that does nothing. This is the argumentative equivalent of a division by zero. (Anyone with a good math background knows that I can prove 5=7 if you'll let me divide by 0). Their real concern will be how fast, useful, and reliable the application is. This is an issue created by anti-Ada folks because it is one of the few points where they can point out an disadvantage to Ada (using most compilers). You are never going to convince them Ada is ok by making "Hello World" small. They will just change their argument (or more likely, pretend its still large). -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-19 0:00 ` Theodore E. Dennison @ 1996-04-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 29+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) T.E.D. said "That wasn't my impression. My impression (I think supported by the thread title of "How low can you go?") was that we were talking about space for space's sake." Exactly wrong, space for PERFORMANCE's sake, not space for SPACES's sake. disk is cheap and getting cheaper all the time, people's time is more expensive! ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` Robert Dewar 1996-04-19 0:00 ` Norman H. Cohen @ 1996-04-20 0:00 ` Al Christians 1996-04-22 0:00 ` Theodore E. Dennison 2 siblings, 1 reply; 29+ messages in thread From: Al Christians @ 1996-04-20 0:00 UTC (permalink / raw) In <317688E9.2781E494@escmail.orl.mmc.com> "Theodore E. Dennison" >Again, I don't believe you here. I don't bat an eylash at any >executable less than one MEG. If someone raises nonsense such as >executable size as argument against Ada, you're just wasting your >time trying to placate them. They will just keep shifting their >argument, becuase the real problem isn't executable size, its that >its not C. Don't even bother. I have worked in situations with networked DOS PC's in which the executable sizes are very important. Some systems are too big to be a single executable, so client PC's must load executables repeatedly as the users switch from task to task. Even compact executables represent a large portion of the load on the network, which is often close to capacity. The difference between compact and bloated executables is critical in these cases. Al ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-20 0:00 ` Al Christians @ 1996-04-22 0:00 ` Theodore E. Dennison 0 siblings, 0 replies; 29+ messages in thread From: Theodore E. Dennison @ 1996-04-22 0:00 UTC (permalink / raw) Al Christians wrote: > > I have worked in situations with networked DOS PC's in which the > executable sizes are very important. Some systems are too big to be a We're not talking DOS, we're talking OS/2. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-17 0:00 ` Geert Bosch 1996-04-17 0:00 ` Michael F Brenner 1996-04-18 0:00 ` Theodore E. Dennison @ 1996-04-19 0:00 ` Fergus Henderson 2 siblings, 0 replies; 29+ messages in thread From: Fergus Henderson @ 1996-04-19 0:00 UTC (permalink / raw) Geert Bosch <geert@fozzie.sun3.iaf.nl> writes: >I didn't expect to have to defend why small executables are an advantage, >but I'll try to list some reasons: You missed one: using shared libraries can significantly reduce turn-around time during development. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GNAT Executables: How low can you go? 1996-04-13 0:00 GNAT Executables: How low can you go? Geert Bosch 1996-04-13 0:00 ` Robert Dewar @ 1996-04-17 0:00 ` Cordes MJ 1 sibling, 0 replies; 29+ messages in thread From: Cordes MJ @ 1996-04-17 0:00 UTC (permalink / raw) : This is better... : ~~~~~~~~~~~~~~~~~ : Using GNAT v3.01 for OS/2 and default compilation, but with optimizations : on and checks suppressed resulted in an executable of 114 kB which ran about : 3 times as slow as the C version. Now with some tweaking the source has : changed a little (about 20 lines were modified) and now the code is : just 15-20% slower than the C version which is not bad considering the : extra robustness and safety. Be carefull - "with optimizations on and checks suppressed" does not lend itself to considerations of extra robustness and safety. Unless, of course, you were refering to extra robustness and safety in C ;) : slices, exception handlers, discriminated records containing : Regards, : Geert Bosch : -- : E-Mail: geert@sun3.iaf.nl *** As far as we know, there have not been *** : Phone: +31-53-4303054 ** any undetected failures in our software. ** ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~1996-04-30 0:00 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-04-13 0:00 GNAT Executables: How low can you go? Geert Bosch 1996-04-13 0:00 ` Robert Dewar 1996-04-16 0:00 ` Geert Bosch 1996-04-16 0:00 ` Theodore E. Dennison 1996-04-16 0:00 ` Robert Dewar 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` Robert Dewar 1996-04-19 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` John Howard 1996-04-19 0:00 ` Robert Dewar 1996-04-17 0:00 ` Geert Bosch 1996-04-17 0:00 ` Michael F Brenner 1996-04-18 0:00 ` Geert Bosch 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Geert Bosch 1996-04-19 0:00 ` Robert Dewar 1996-04-26 0:00 ` Richard A. O'Keefe 1996-04-29 0:00 ` Theodore E. Dennison 1996-04-30 0:00 ` mjp 1996-04-26 0:00 ` Geert Bosch 1996-04-18 0:00 ` Theodore E. Dennison 1996-04-18 0:00 ` Robert Dewar 1996-04-19 0:00 ` Norman H. Cohen 1996-04-19 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Robert Dewar 1996-04-20 0:00 ` Al Christians 1996-04-22 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Fergus Henderson 1996-04-17 0:00 ` Cordes MJ
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox