lange@ames.arc.nasa.gov (Christopher Lange) (12/19/90)
main() {
printf("Hello, world!\n") ;
system("ksh $a/c/hello.explained") ;
exit(0);
}
According to the Usenet "Jargon" file, HELLO WORLD is:
the first C program
required of a novice C programmer. Compilers that produce large
executables from such a program, or require bulky linking/loading, are
said to automatically LOSE.
This is what ls -l says:
-rwxr-xr-x 1 lange 24576 Dec 16 12:05 /u9/lange/alex/c/hello
-rw-r--r-- 1 lange 88 Dec 16 13:59 /u9/lange/alex/c/hello.c
-rwxr-xr-x 1 lange 1335 Dec 16 14:28 /u9/lange/alex/c/hello.explained
So that's a ratio of 24576 / 88 , which we can get the
shell to evaluate for us with the shell command
expr 24576 / 88
279
which, I would say, means that Sun loses... .
[[Ed's Note: Just out of curiosity, I compiled the following program:
main(){}
on a couple of different machines just to see what kind of executables
each produced. This program does absolutely nothing, so what we are seeing
is the size of the routines to handle passing in args and staring up. All
were compiled with cc.
Apollo (Domain/OS SR10.1) 2715 bytes
HP-9000 (HPUX 6.5) 5114 bytes
Sun (4.0.3 & 4.1) 24576 bytes
So that was kind of interesting, so I looked at object code output (cc -c)
Apollo 1391 bytes
HP-9000 103 bytes
Sun 80 bytes (Sparcstation, 4.1)
Sun 78 bytes (Sun 3/60, 4.0.3)
So, most of the space is taken up in the link/load process. Note that by
stripping the relocation bits (ld -s), you can reduce the size of the
executable to 16384 bytes. -bdg]]
Alex Lange
Publications Engineer - Everyone spoke of an information overload,
Lockheed Missiles & Space - but what there was in fact was
lange@iscnvx.lmsc.lockheed.com - a non-information overload.falk@peregrine.eng.sun.com (Ed Falk) (12/30/90)
In article <903@brchh104.bnr.ca> amdcad!netcom!lange@ames.arc.nasa.gov (Christopher Lange) writes: > >main() { > printf("Hello, world!\n") ; > system("ksh $a/c/hello.explained") ; > exit(0); >} [produces a 24k executable] >which, I would say, means that Sun loses... . [our moderator tries this on different systems: > Apollo (Domain/OS SR10.1) 2715 bytes > HP-9000 (HPUX 6.5) 5114 bytes > Sun (4.0.3 & 4.1) 24576 bytes > >So that was kind of interesting, so I looked at object code output (cc -c) > > Apollo 1391 bytes > HP-9000 103 bytes > Sun 80 bytes (Sparcstation, 4.1) > Sun 78 bytes (Sun 3/60, 4.0.3) > >So, most of the space is taken up in the link/load process. Note that by >stripping the relocation bits (ld -s), you can reduce the size of the >executable to 16384 bytes. -bdg]] You can do a *lot* better than that, if you want. The reason the Sun executable is so large seems to be the fact that things are being aligned on page boundaries so that the text can be shared. If you don't care about sharing the text, compile like this: % cc -O -n -Bdynamic -o hello hello.c % strip hello % ls -l hello* -rwxrwxr-x 1 falk 1344 Dec 21 16:44 hello* -rw-rw-r-- 1 falk 89 Dec 21 16:44 hello.c Disclaimer: I'm not a compiler guru, just an end user. I'm sure some compiler guru could tell me I'm all wet.
das@think.com (David Steffens) (12/30/90)
In article <903@brchh104.bnr.ca>, amdcad!netcom!lange@ames.arc.nasa.gov (Christopher Lange) says: > This is what ls -l says: When comparing executables, "size" is preferred to "ls -l". > [[Ed's Note: Just out of curiosity... Curiosity causes all manner of troubles, for humans as well as for cats. > ... This program does absolutely nothing, so what we are seeing > is the size of the routines to handle passing in args and staring up... Perhaps, but if you check the symbol table of the executable with "nm", you may be surprized by what you find -- Sun includes all of the standard IO support package even though your program doesn't reference it. This is in fact the bulk of the code in the Sun executable file. Whether this is good or bad is debatable, but unless you have checked to see what the other systems are packaging up into the executable, you may be comparing apples and oranges. An example: on our Ultrix system, stdio is included by default but under 4.3bsd it isn't. This results in executable sizes which differ by several kilobytes. > ... So, most of the space is taken up in the link/load process... ]] You have missed at least one other point. Under SunOS, the text segment of executables are rounded UP to the next largest 8K unit to be compatible with the filesystem block size. Therefore, a 16K executable may actually only contain 8193 bytes of text. In fact, using "nm" it is easy to show that the text segement of your test program begins at 0x2020 and extends to just past 0x4000. Since this is just over 8K, the text segment size is rounded up to 16K. The net effect is almost 8K of dead space, not machine instructions. David Allan Steffens | I believe in learning from past mistakes... Eaton-Peabody Laboratory | ...but does a good education require so many? Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114 {harvard,mit-eddie,think}!eplunix!das (617) 573-3748 (1400-1900h EST)