XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) (06/08/89)
Hallo everybody,
a friend of mine without a network connection (poor guy) reported the
following observation to me. When I was able to reproduce it, I didn't feel
really happy about it. Here it comes: my friend has the following Fortran code
PROGRAM TEST
WRITE(*,*) 'Test Test'
END
When compiling this code with several debug/optimize switches you get the
following sizes for the executable image files:
cc -xxx t.f -o t f77 -xxx t.f -o t
xxx=g 220472 byte 292984 byte
xxx=O1 220388 byte 292900 byte
xxx=O2 same as O1
xxx=O3 same as O1
The same program compiled on a VAX (I'm definitely not a great VAX friend) with
the most unfavourable switches (/DEBUG=ALL/NOOPT on compile and /DEBUG/NOSYSSHR
on link) gives a maximum size of 25000 byte (4000 byte using the shared libs).
I know that RISC code is larger than CISC code, but I didn't know that the
difference is that large. What I also don't understand is the difference
between cc and f77. I thought if cc detects a fortran file it would just do the
same as f77. As a last question, is SGI (or MIPS if thats the right target for
this problem) thinking about shareable libraries beside libgl_s.a ? I think
that would greatly reduce link time and disk usage.
Regards
Martin Knoblach
<xbr2d96d@ddathd21.bitnet>calvin@dinkum.wpd.sgi.com (Calvin H. Vu) (06/10/89)
In article <8906081116.aa29217@SMOKE.BRL.MIL>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: > Hallo everybody, > > my friend has the following Fortran code > > PROGRAM TEST > WRITE(*,*) 'Test Test' > END > > When compiling this code with several debug/optimize switches you get the > following sizes for the executable image files: > > cc -xxx t.f -o t f77 -xxx t.f -o t > xxx=g 220472 byte 292984 byte > xxx=O1 220388 byte 292900 byte > xxx=O2 same as O1 > xxx=O3 same as O1 > >The same program compiled on a VAX (I'm definitely not a great VAX friend) with >the most unfavourable switches (/DEBUG=ALL/NOOPT on compile and /DEBUG/NOSYSSHR > on link) gives a maximum size of 25000 byte (4000 byte using the shared libs). The large size of the executabes is due partly to the way libI77 is written (generic UNIX system problem ?) and partly to the addition of the ISAM library to the Fortran package. Roughly, the 290K bytes produced by the compiler/linker are picked up from: - 130K from libmpc.a (60K if you use libc.a. This accounts for the difference in size between using cc and f77) - 140K from libisam.a - 19K from other libraries - 1K from the program itself That's why it doesn't matter much whether you use -g or -O3 to optimize your program since the problem is in the packaging of the runtime I/O libraries and not in the code generated from the user source (the .o files is less than 1K for the test above). > > I know that RISC code is larger than CISC code, but I didn't know that the > difference is that large. The difference would be small if the same runtime I/O libraries were used. > What I also don't understand is the difference >between cc and f77. I thought if cc detects a fortran file it would just do the > same as f77. When you use f77 the multiprocessing libc (libmpc.a) is used instead of libc.a. > As a last question, is SGI (or MIPS if thats the right target for > this problem) thinking about shareable libraries beside libgl_s.a ? I think > that would greatly reduce link time and disk usage. > I plan to rewrite the runtime I/O libraries so that the ISAM routines will only be linked into the executable with a compilation flag. That will reduce the size by at least 100K. libc_s.a can also be used as an option to reduce the size by a further 50K. That would make the size of the executable for the test above about 80K. Of course, if libI77.a is also changed upside down so that only routines which are actually used will be linked then the size could be even less, maybe <40K, but ... :-(. And of course, the initial runtime I/O overhead of ~200K would become less of an annoyance if your program is large. > Regards > Martin Knoblach > <xbr2d96d@ddathd21.bitnet> Calvin Vu
khb@chiba.Sun.COM (chiba) (06/13/89)
In article <8906081116.aa29217@SMOKE.BRL.MIL> XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: >Hallo everybody, > > a friend of mine without a network connection (poor guy) reported the >following observation to me. When I was able to reproduce it, I didn't feel >really happy about it. Here it comes: my friend has the following Fortran code > > PROGRAM TEST > WRITE(*,*) 'Test Test' > END > > When compiling this code with several debug/optimize switches you get the >following sizes for the executable image files: > > cc -xxx t.f -o t f77 -xxx t.f -o t >xxx=g 220472 byte 292984 byte >xxx=O1 220388 byte 292900 byte >xxx=O2 same as O1 >xxx=O3 same as O1 > >The same program compiled on a VAX (I'm definitely not a great VAX friend) with >the most unfavourable switches (/DEBUG=ALL/NOOPT on compile and /DEBUG/NOSYSSHR >on link) gives a maximum size of 25000 byte (4000 byte using the shared libs). > >I know that RISC code is larger than CISC code, but I didn't know that the >difference is that large. What I also don't understand is the difference >between cc and f77. I thought if cc detects a fortran file it would just do the >same as f77. As a last question, is SGI (or MIPS if thats the right target for >this problem) thinking about shareable libraries beside libgl_s.a ? I think >that would greatly reduce link time and disk usage. > I must confess to finding these results strange. I don't have an SGI handy, and the local MIPSbox is busy so I tried a sun 4/330 Compiled f77 file.f chiba:/home/tipatina/khb>size a.out text data bss dec hex 40960 8192 7720 56872 de28 chiba:/home/tipatina/khb>ls -l a.out -rwxr-xr-x 1 khb 57344 Jun 12 23:26 a.out* So shared libraries are a big win ???? chiba:/home/tipatina/khb>f77 amy.f -Bstatic chiba:/home/tipatina/khb>r ls ls -l a.out -rwxr-xr-x 1 khb 98304 Jun 12 23:29 a.out* Yeah, somewhat 220472 byte or 292984 byte seems somewhat largeish... someone must be asleep in the library crafting group or some such.... btw: cc *.f probably gets you some slighly different library support. Try -v and other options to see what the compiler actually does. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)