trohling@uceng.UC.EDU (tom rohling) (02/24/90)
On a related note to my other article, can the size of an executable
be reduced while still being an executable? I noticed that the size of the
exec for some of the demos and such are very small but any extensive
graphics thing I do is easily over 800k in size so something must have been
done to 'em right?
Any ideas?
===========================================================================
Tom Rohling "Infinity is where things happen
trohling@uceng.uc.edu that don't." -Anonymous
or
rohling@afiris.ase.uc.edu
===========================================================================mcqueen@acf4.NYU.EDU (David M. McQueen) (02/24/90)
/* acf4:comp.sys.sgi / trohling@uceng.UC.EDU (tom rohling) / 12:27 am Feb 24, 1990 */ > On a related note to my other article, can the size of an executable >be reduced while still being an executable? I noticed that the size of the >exec for some of the demos and such are very small but any extensive >graphics thing I do is easily over 800k in size so something must have been >done to 'em right? > > Any ideas? > >=========================================================================== >Tom Rohling "Infinity is where things happen >trohling@uceng.uc.edu that don't." -Anonymous > or >rohling@afiris.ase.uc.edu >=========================================================================== /* ---------- */ Two ways I have found to reduce the size of executables are: 1) compile using shared graphics libraries. As an example (Fortran, but similar and even greater reductions are possible with C programs): With f77 program.f -lfgl -lgl : 652704 bytes With f77 program.f -lfgl -lgl_s : 453440 bytes a reduction of about 200 Kbytes 2) again in Fortran, if you are using large arrays, place those arrays in labelled common blocks. =============================================================================== Disclaimer: The above is just my opinion. God Alone Knows. David M. McQueen,Courant Institute of Mathematical Sciences,New York University "The difference between long-distance commuting and long-distance computing is that with long-distance computing you can stay in your office and get stuck in traffic."
ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) (02/25/90)
In article <17280032@acf4.NYU.EDU>, mcqueen@acf4.NYU.EDU (David M. McQueen) writes: > /* acf4:comp.sys.sgi / trohling@uceng.UC.EDU (tom rohling) / 12:27 am Feb 24, 1990 */ > > > On a related note to my other article, can the size of an executable > >be reduced while still being an executable? I noticed that the size of the > >exec for some of the demos and such are very small but any extensive > >graphics thing I do is easily over 800k in size so something must have been > >done to 'em right? > > > > Any ideas? > > > >=========================================================================== > >Tom Rohling "Infinity is where things happen > >trohling@uceng.uc.edu that don't." -Anonymous > > or > >rohling@afiris.ase.uc.edu > >=========================================================================== > /* ---------- */ > > Two ways I have found to reduce the size of executables are: > > 1) compile using shared graphics libraries. As an example (Fortran, but > similar and even greater reductions are possible with C programs): > > With f77 program.f -lfgl -lgl : 652704 bytes > With f77 program.f -lfgl -lgl_s : 453440 bytes > > a reduction of about 200 Kbytes > > 2) again in Fortran, if you are using large arrays, place those arrays > in labelled common blocks. > > > =============================================================================== > Disclaimer: The above is just my opinion. God Alone Knows. > > David M. McQueen,Courant Institute of Mathematical Sciences,New York University > > "The difference between long-distance commuting and long-distance computing is > that with long-distance computing you can stay in your office and get stuck in > traffic." The MIPS compilers used on SGI, MIPS, and other competitor's workstations generate a lot of symbol information in executables, even if no debugging is selected. This symbol info includes function names, globals, and line number information. This level of detail allows you to dbx an executable (too a limited extent) or use pixie for profiling. If you are satisfied that you do not want or need any of this symbol info in you code (i.e. if you are shipping it to customers), you can strip your executable using the program strip(1). This should reduce the size of your executables by possible a couple hundred 'k'. Don't go stripping your libraries though -- you won't be able to link to them. --- Ciemo
robert@victoria.esd.sgi.com (Robert Skinner) (02/27/90)
In article <17280032@acf4.NYU.EDU>, mcqueen@acf4.NYU.EDU (David M. McQueen) writes: > /* acf4:comp.sys.sgi / trohling@uceng.UC.EDU (tom rohling) / 12:27 am Feb 24, 1990 */ > > Two ways I have found to reduce the size of executables are: > > 1) compile using shared graphics libraries. As an example (Fortran, but > similar and even greater reductions are possible with C programs): > > With f77 program.f -lfgl -lgl : 652704 bytes > With f77 program.f -lfgl -lgl_s : 453440 bytes > don't forget to link with the shared C library also (-lc_s). This results in an additional savings for any program, graphics or not. Robert Skinner robert@sgi.com Whoa Homer, don't have a cow. - Bart Simpson
mberger@relay.nswc.navy.mil (02/28/90)
You can use the "strip" command which removes the symbol table and relocation bits. Using strip can reduce our executables by about a third.
calvin@dinkum.sgi.com (Calvin H. Vu) (03/01/90)
I planned to e-mail this to glennrp@brl.mil to respond to his question but since so many people seem to be unaware of this I will make a general posting instead. Here it goes: ---------------------------------------------------------------------- By defaults, f77 uses the libmpc.a library to allow multiprocessing system calls. This MP capability adds about 70K to the executable size as compared to the standard libc.a library. If you can use the shared C library you can cut another 30K from your executable. To use the standard libc.a library all you need to do is to replace the f77 driver with the cc driver i.e. use: (BTW, this will also make your executable runs marginally faster if you don't need MP Fortran) cc -g -G 0 *.o -lfgl -lgl_s instead of: f77 -g -G 0 *.o -lfgl -lgl_s To use the shared libc_s.a library, you need to include all Fortran runtime libraries before the -lc_s to make sure that all C systems calls will be resolved by using the shared library, not the libc.a library. In other words, use: cc -g -G 0 *.o -lfgl -lgl_s -lF77 -lI77 -lU77 -lisam -lm -lc_s The multiply-defined warnings you get when using -lc_s on the command line stems from the fact that those multiply-defined routines are resolved in libc_s.a but are also defined in libmpc.a. This should be O.K. unless you do want to use MP Fortran. In that case forget everything I said above and just use the default f77 driver. The additional 100K is the price you have to pay for this extra MP capability and you will need every bit of it (pun intended). Another major factor which makes Fortran executable size much bigger than C is the libisam.a library which adds over 100K to the size. Currently, this ISAM library is intertwined with the standard runtime I/O library (libI77.a) and will be dragged in even if you do not need ISAM capability. In future releases, we will remove this interdependency to reduce the size of the executable. And of course you can use 'strip' to make the executable even smaller. All in all, after everything is said AND DONE :-), the size of a simple 'hello world' program can probably be reduced from 310K to under 60K. Right now, if you apply all the tricks above you can reduce it to about 140K. Oh well, you never have a REAL Fortran program which is less than 1M anyway, so an extra 100K of overhead is nothing. Right ? Right ? Hmmm, I guess I can't take over Johny Carson's job yet :-). BTW, if you don't have the standard 4 gigabytes of disk space on your standard Unix system and are desperate enough to to go after the 100K+ added by libisam.a you can remove -lisam from the linker command line generated by 'f77 -v' and get a list of undefined references then use dummy procedures for all of them. This is royally painful, but as I said, if you are desperate ... Calvin Vu ----------------------------------------------------------------------- "Don't blame it on RISC. Just blame it on FORTRAN and Rio"
stephen@mincom.OZ (Stephen Kirby) (03/01/90)
Subject: Shared library implentation problems. Mincom would like to be able to reduce the size of their executable files by utilizing shared libraries. There are a couple of restrictions which prevent us from making full use of shared libraries. Would you please find out if and when these problems will be addressed in IRIX. 1. A routine in a shared library cannot call a routine from another shared library. Even though it is documented on page 13-33 in the IRIS-4D Programmers Guide. ( the #objects noload directive.) 2. There are no shared libraries available for the fortran compiler. The fortran runtime library is not shared. 3. There is no facility to make our own shared libraries from our fortran routines. If the above restrictions were fixed we would be able to produce smaller executables and improve our development environment. MINCOM Pty Ltd Ph: (07) 3948000 1st Floor 109 Logan Road, 138 Juliette St, Woollongabba. Greenslopes 4120 BRISBANE BRISBANE Fax (07) 3942844 Stephen Kirby.