nall@sun8.scri.fsu.edu (John Nall) (12/12/90)
Running both standard Minix 1.5.10 and Minix-386 (on different partitions), and having recently installed GCC (with many thanks to Alan Black and friends), and having also done some testing with the new ANSI compiler, I had the unique opportunity to compare the four compilers on my system. I found the following comparisons rather interesting, and thought I would share them.... John Nall nall@sun8.scri.fsu.edu OBJECT OBJECT OBJECT OBJECT OBJECT PROGRAM SIZE SIZE SIZE SIZE NAME (ACK) (ANSI) (BCC) (GCC) ---------------------------------------------------------------------------- dosread 10888 13920 14740 32800 libpack 4400 7912 11020 28704 libupack 1908 2756 2884 22560 readclock 5948 9232 8924 22560 term 4390 6328 5468 24608 -- John W. Nall | Supercomputer Computations Research Institute nall@sun8.scri.fsu.edu | Florida State University, Tallahassee, FL 32306 WB4LOQ (why? I dunno....everyone else seems to be doing it. _._)
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (12/12/90)
In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes: >NAME (ACK) (ANSI) (BCC) (GCC) >---------------------------------------------------------------------------- object size smallest bigger bigger yet biggest Can you please compare the speed of execution for these various binaries? This would be very interesting information. -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
jds@cs.umd.edu (James da Silva) (12/12/90)
In article <28751@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) >writes: >>NAME (ACK) (ANSI) (BCC) (GCC) >>---------------------------------------------------------------------------- > object size smallest bigger bigger yet biggest > >Can you please compare the speed of execution for these various >binaries? This would be very interesting information. In general I would agree, but I guess that none of those programs is particularly CPU bound, except perhaps for the libpack/libupack programs. What I'd like to know is: - are these the .o sizes, or the final executable sizes? - whether you used bcc -0 or bcc -3? (I would guess -0 from the size) - whether you used the same libraries among the 16-bit compilers? It's not the least bit surprising that the 32 bit code is much bigger than the small model 8086 code; every integer and address in the program is twice as big. The most surprising numbers are that for the ANSI compiler versus ACK. Has the code quality gone way down, or is the libary or linker just different? The best way to compare compiler code density is to look at the size of the text segment in the .o files. Is that what you did? Jaime ........................................................................... : domain: jds@cs.umd.edu James da Silva : path: uunet!mimsy!jds Systems Design & Analysis Group
nall@sun8.scri.fsu.edu (John Nall) (12/12/90)
In article <28751@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes: >>NAME (ACK) (ANSI) (BCC) (GCC) >>---------------------------------------------------------------------------- > object size smallest bigger bigger yet biggest > >Can you please compare the speed of execution for these various >binaries? This would be very interesting information. Actually, I did do some speed of execution tests, but found them to be pretty much inconclusive. The size of the object files seems to me to be pretty much cut and dried, but execution speed, like beauty, tends to be in the mind of the beholder. I suspect that an example can be found which will make each of them look good. And of course we cannot ignore that GCC and BCC (for me) are running under Minix-386, while ACK and ANSI are running under Standard Minix 1.5.10. So I would not like to make any general statements concerning execution speed of the object code produced by the four compilers. -- John W. Nall | Supercomputer Computations Research Institute nall@sun8.scri.fsu.edu | Florida State University, Tallahassee, FL 32306 WB4LOQ (why? I dunno....everyone else seems to be doing it. _._)
ast@cs.vu.nl (Andy Tanenbaum) (12/12/90)
In article <28515@mimsy.umd.edu> jds@cs.umd.edu (James da Silva) writes: >The most surprising numbers are that for the ANSI compiler versus ACK. Has >the code quality gone way down, or is the libary or linker just different? I suspect these are the a.out sizes. The large increase with the ANSI compiler is due to ANSI itself. It requires all kinds of horrible things, like the ability to handle %f in printf and heaven-knows-what involving time. I am fairly sure most of the increase is due to the larger libraries required by ANSI. John: do nm -ng a.out and see where the program stops and libs start. Andy Tanenbaum (ast@cs.vu.nl)
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (12/12/90)
In article <8484@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >I suspect these are the a.out sizes. The large increase with the ANSI >compiler is due to ANSI itself. It requires all kinds of horrible things, >like the ability to handle %f in printf and heaven-knows-what involving >time. I am fairly sure most of the increase is due to the larger libraries >required by ANSI. Wow! Does this mean that 1.6.0, with the ANSI C compiler, will have floating point support? (That sure would make us engineering types happy.) <inserting foot in mouth, I say:> I volunteer to write library routines (or adapt somebody else's) to support the 80x87 co-processor, and modify the kernel as required. Somebody else can do it for the superior but less ubiquitous Motorola chips. -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
adrie@philica.ica.philips.nl (Adrie Koolen) (12/12/90)
In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes: >Running both standard Minix 1.5.10 and Minix-386 (on different partitions), >and having recently installed GCC (with many thanks to Alan Black and friends), >and having also done some testing with the new ANSI compiler, I had the unique >opportunity to compare the four compilers on my system. I found the following >comparisons rather interesting, and thought I would share them.... > >John Nall >nall@sun8.scri.fsu.edu > >OBJECT OBJECT OBJECT OBJECT OBJECT >PROGRAM SIZE SIZE SIZE SIZE >NAME (ACK) (ANSI) (BCC) (GCC) >---------------------------------------------------------------------------- >dosread 10888 13920 14740 32800 >libpack 4400 7912 11020 28704 >libupack 1908 2756 2884 22560 >readclock 5948 9232 8924 22560 >term 4390 6328 5468 24608 I'm puzzled by the fact, that the GCC object files are so big! I'm using GCC 1.37.1 under Minix-Sparc and it's supposed to be the same as the 386 version apart from the back-end, which is of course Sparc specific. The middle three programs are useless for the SparcStation, but the first and the last program I have compiled under Minix-Sparc with GCC and got the following object size. `dosread', which doesn't work properly because of byte ordering problems, is 19224 bytes, and `term' compiles to an object of 5464 bytes. These objects are stripped, so no symbol table is appended. Now, the Sparc processor, being a RISC processor, generally needs bigger object files than a CISC processor (like the 386). So I'd expect the GCC 386 object files to be somewhat smaller than the Sparc versions. I suspect, that the exorbitant size of the GCC object files is not because of size-inefficient code generation of the GNU compiler, but due to link or library problems. On the SparcStation, object are linked with the data segment immediately following the text segment. Only word alignment takes place. Also, the symbol table (when not stripped) is stored directly after the (initialized) data segment. Maybe, the GCC object files, mentioned in the table, are not stripped or use excessive (4K?, 8K?) alignment? Under SunOS, the first 8K of a process are not used (trap null pointer dereferences). Maybe also on the GCC 386 object files? On Minix-Sparc, I support floating point. When a small program calls printf, a lot of floating point subroutines are linked in, whether it is used or not! If term.c is compiled to term.o (`cc -c term.c'), how big is term.o? My term.o (on a SparcStation) is 5314 bytes. That is with symbol table, of course. I can't believe, that the GCC 386 back-end is that inefficient! Compile the programs to assembly with the compilers and then compare the size. I like to know where the big sizes come from. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
L.Parkes@comp.vuw.ac.nz (Lloyd Parkes) (12/13/90)
In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes:
Running both standard Minix 1.5.10 and Minix-386 (on different partitions),
...
Huh. Nice for some. :-)
OBJECT OBJECT OBJECT OBJECT OBJECT
PROGRAM SIZE SIZE SIZE SIZE
NAME (ACK) (ANSI) (BCC) (GCC)
----------------------------------------------------------------------------
dosread 10888 13920 14740 32800
libpack 4400 7912 11020 28704
libupack 1908 2756 2884 22560
readclock 5948 9232 8924 22560
term 4390 6328 5468 24608
--
So what?? (Said in the nicest possible way). This probably means that
gcc includes a hell of a lot more libraries than the other compilers.
It appears to be quite consistent about it as well. This can usually
be fixed much easier than abominable code generation for instance. I
have also heard reports that gcc on a sequent produces binaries 1/3
smaller than the system compiler.
By the way you did strip the binaries didn't you. I wouldn't put it
past gcc to generate _lots_ of symbolic information.
Lloyd
p.s. I am a bit of a gcc fan
--
------------------------------------------------------------------------
Lloyd Parkes | The stereotypical young adult male in New
lloyd@comp.vuw.ac.nz | Zealand is a good reason for being lesbian.
------------------------------------------------------------------------sac@decuk.uvo.dec.com (Stephen A Carpenter) (12/13/90)
How about using the -S switch and looking at the size/quality of the assembly language code? The example is too small to be conclusive. Try comparing the stripped exe size of program that is several thousand lines long. Stephen.
ast@cs.vu.nl (Andy Tanenbaum) (12/14/90)
In article <28769@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >Wow! Does this mean that 1.6.0, with the ANSI C compiler, will have >floating point support? (That sure would make us engineering types >happy.) The ANSI compiler fully supports floating point. It can both use the 8087 chip or emulate it in software. The compiler is in beta test now. Andy Tanenbaum (ast@cs.vu.nl)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (12/14/90)
do not write libraries to support 80x87, is is better to support this directly in the code generator. when I worked on my 386 code generator yesterday, I learned that the 80387 is very friendly to code generator writers since it is a stack machine. C.v.W.
awb@uk.ac.ed.aipna (Alan W Black) (12/14/90)
In article <722@philica.ica.philips.nl>, adrie@philica.ica.philips.nl (Adrie Koolen) writes: |>In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes: |>>Running both standard Minix 1.5.10 and Minix-386 (on different partitions), |>>and having recently installed GCC (with many thanks to Alan Black and friends), |>>and having also done some testing with the new ANSI compiler, I had the unique |>>opportunity to compare the four compilers on my system. I found the following |>>comparisons rather interesting, and thought I would share them.... |>> |>>John Nall |>>nall@sun8.scri.fsu.edu |>> |>>OBJECT OBJECT OBJECT OBJECT OBJECT |>>PROGRAM SIZE SIZE SIZE SIZE |>>NAME (ACK) (ANSI) (BCC) (GCC) |>>---------------------------------------------------------------------------- |>>dosread 10888 13920 14740 32800 |>>libpack 4400 7912 11020 28704 |>>libupack 1908 2756 2884 22560 |>>readclock 5948 9232 8924 22560 |>>term 4390 6328 5468 24608 |> |>I'm puzzled by the fact, that the GCC object files are so big! I'm using |>GCC 1.37.1 under Minix-Sparc and it's supposed to be the same as the 386 |>version apart from the back-end, which is of course Sparc specific. The |>middle three programs are useless for the SparcStation, but the first and |>the last program I have compiled under Minix-Sparc with GCC and got the |>following object size. `dosread', which doesn't work properly because of |>byte ordering problems, is 19224 bytes, and `term' compiles to an object |>of 5464 bytes. These objects are stripped, so no symbol table is appended. |> |> |> On the SparcStation, object are linked with the data segment immediately |> following the text segment. Only word alignment takes place. Also, the |> symbol table (when not stripped) is stored directly after the (initialized) |> data segment. Maybe, the GCC object files, mentioned in the table, are not |> stripped or use excessive (4K?, 8K?) alignment? Under SunOS, the first 8K |> of a process are not used (trap null pointer dereferences). Maybe also on |> the GCC 386 object files? |> |>Adrie Koolen (adrie@ica.philips.nl) |>Philips Innovation Centre Aachen This is exactly the problem with GCC 386. I can't offhand remember if its 4K or 8K (or bigger -- as I've said before Richard Tobin did the difficult bit, and he's away at the moment) alignment for the data segment but there is rather a nasty space in there which is rather a large percentage of small programs. Also there is always basic floating point signal handlers linked in. There also has been mention about gcc compiled programs having a large chmem size. This is because the basic gcc a.out format has no size associated with it, so when it is converted it is simply set to 65535 which could be far too large, or even too small but some figure was required. You should really tune that yourself. I suppose we never really considered worrying about this size problem as GCC is such a win when compiling big programs, itself, emacs, various prologs, lisps and ml. And big programs were the reason for porting it. Maybe I've adopted too much of the gnu philosophy if I say I don't care enough about the lost memory :-) I have been thinking about recompiling the whole of 1.5 with gcc and I think then I might begin to care. But at present if you're worried about space use bcc, if you are worried about time use gcc -O and if the program will compile to greater than, say 64K with bcc, it'll probably be smaller with gcc Alan Alan W Black 80 South Bridge, Edinburgh, UK Dept of Artificial Intelligence tel: (+44) -31 225 7774 x228 or x223 University of Edinburgh email: awb@ed.ac.uk
hp@vmars.tuwien.ac.at (Peter Holzer) (12/15/90)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >do not write libraries to support 80x87, is is better to support this >directly in the code generator. To whoever proposed to write a library for the 387: If you want to please a lot of people write a 387 emulator. Many 386-users don't have a 387. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
archer%segin4.segin.fr@relay.prime.com (Vincent Archer) (12/17/90)
I've seen haggling about various compilers and the size of the object they
produce. In my opinion, a sure way to compare those compilers is the (in)famous
dhrystone benchmark. So, select dhrystone.c and figure:
- How long it takes to compile (on an idle system) the stuff?
- The size of the .o (forget ACK's .s) produced?
- The size of the stripped executable?
- The number of dhrystones reported by the program?
(this with registers, without registers, with -O, without -O. 4 tests in all).
I think that this test would be very representative of the compiler (more than
code) quality, since dhrystone is a widely distributed & used benchmark. I'll
do the same on my ST, but I've only two compilers to compare: C68 and ACK
(btw, the number of dhrystones for each were posted by CvW earlier). GCC
wouldn't run on my 1Mo ST... :-)
Vincent Archer
Email: archer%segin4.segin.fr@relay.prime.com
"When you define a problem, evaluate it in two ways; what is going wrong, and
what isn't going right..."MDOELL%DOSUNI1.BITNET@cunyvm.cuny.edu (Magnus Doell) (12/19/90)
The following doesn't compare a big program but a standard benchmark
program. So it might help to know about:
dhrystone 1.1 - test
These are the results for my system, a 16MHz 386sx with 2M RAM
running MINIX-386 with my extensions to allow 16-bit processes.
All tests were made on an empty system (kill -9 -1).
compiler segment-sizes files-sizes speed
-O text data bss stack memory normal stripped
------------------------------------------------------------------------------
cc 4832 630 7406 8192 21060 7766 5494 1724
bcc -0 5888 352 7396 8192 21828 8272 6272 2272
bcc -3 6064 428 12700 8192 27384 7900 6524 1785
gcc(1) 5744 244 12700 8192 26880 7412 6020 2500
(1) I use Bruce' port of gcc to MINIX
This isn't equal to the one found in pub/Minix/uk at plains.nodak.edu
Hope this helps.
Ma.D.
-------------------------------------------------------------
Magnus Doell <MDOELL@DOSUNI1.BITNET>
Parkstr. 7a
D-4500 Osnabrueck (Germany)HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (12/28/90)
Yes you are right. My 386 compiler has a -nofpu option which makes the compiler generate calls to some library support functions. These are not present at the moment and the nofpu stuff is untested, but the 387 code worke. C.v.W.
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (01/07/91)
In article <722@philica.ica.philips.nl>, adrie@philica.ica.philips.nl (Adrie Koolen) writes: > In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes: > >Running both standard Minix 1.5.10 and Minix-386 (on different partitions), > >and having recently installed GCC (with many thanks to Alan Black and friends), > >and having also done some testing with the new ANSI compiler, I had the unique > >opportunity to compare the four compilers on my system. I found the following > >comparisons rather interesting, and thought I would share them.... > > > >John Nall > >nall@sun8.scri.fsu.edu ( Figures deleted ) > > I can't believe, that the GCC 386 back-end is that inefficient! Compile the > programs to assembly with the compilers and then compare the size. I like > to know where the big sizes come from. > > Adrie Koolen (adrie@ica.philips.nl) > Philips Innovation Centre Aachen What exactly are we comparing here ? What are the stack sizes for the examples quoted ? I have taken a couple of examples from my 386 - text data bss stack memory 21504 2048 11224 8192 42968 /usr/bin.old/dhrystone 15360 1024 12284 8192 36860 /usr/bin/dhrystone 26624 2048 2708 8192 39572 /usr/bin.old/sort 19456 1024 4884 8192 33556 /usr/bin/sort In these cases the binaries in /usr/bin.old are compiled with bcc, and the ones in /usr/bin with gcc. In virtually all the cases I looked at quickly recently the gcc compiled binary was smaller than the bcc version, so I don't see a problem ! One should also be careful when comparing the sizes of text produced by gcc since gcc regards strings as constants. If you want to compare the sizes accurately, make sure you use -fwritable-strings when compiling with gcc. Regards - Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) " Emulation is the sincerest 85 Hawthorne Crescent form of pottery." West Drayton Middlesex - William Frend De Morgan UB7 9PA
adrie@philica.ica.philips.nl (Adrie Koolen) (01/09/91)
In article <1921@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: >I have taken a couple of examples from my 386 - > > text data bss stack memory > > 21504 2048 11224 8192 42968 /usr/bin.old/dhrystone > 15360 1024 12284 8192 36860 /usr/bin/dhrystone > 26624 2048 2708 8192 39572 /usr/bin.old/sort > 19456 1024 4884 8192 33556 /usr/bin/sort > >In these cases the binaries in /usr/bin.old are compiled with bcc, and the >ones in /usr/bin with gcc. This still puzzles me. I use GCC 1.37.1 for Minix-Sparc and get: text data bss stack memory 12096 1096 12824 16384 42400 /usr/bin/dhrystone 12840 488 2936 60000 76264 /usr/bin/sort I've always been under the impression, that RISC processors need more instructions than a CISC processor to do the same job. The excess code is some 30%, depending on the exact processor (SPARC, MIPS, i860, 88000, etc.). Your examples show that the Sparc processor is significantly more (code) efficient than the 386!?! I still refuse to believe that. Give me the size of sort.o and dhrystone.o or, better yet, the `nm' list of sort.o and dhrystone.o (GCC includes a nm.c to list the symbol table of gcc generated object files). BTW, the total memory reported is not true. Minix-Sparc stores the text, data and bss segments right after eachother in memory. The stack segment however, is moved slightly to high-memory until it fills the last 4KB page entirely! So the `memory' number should be rounded to the next 4096 multiple. I assume, that Minix-386 does do something like that. The Sparc processor needs a large stack because it uses quite some stackspace to store register windows. The 386 text and bss segments have random (unaligned) sizes. The stacks are 8KB, but why are the sizes of the data segments a multiple of 1KB? >One should also be careful when comparing the sizes of text produced by gcc >since gcc regards strings as constants. And places them in the text, in stead of the data segment. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (01/13/91)
In article <729@philica.ica.philips.nl>, adrie@philica.ica.philips.nl (Adrie Koolen) writes: > In article <1921@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: > >I have taken a couple of examples from my 386 - (Stuff deleted) > I've always been under the impression, that RISC processors need more > instructions than a CISC processor to do the same job. The excess code is > some 30%, depending on the exact processor (SPARC, MIPS, i860, 88000, etc.). > Your examples show that the Sparc processor is significantly more (code) > efficient than the 386!?! I still refuse to believe that. Give me the size > of sort.o and dhrystone.o or, better yet, the `nm' list of sort.o and > dhrystone.o (GCC includes a nm.c to list the symbol table of gcc generated > object files). Your wish is my command. I can't get at the nm output on this machine, but doing a compilation on the 386 and doing an ls -l of the object files gives: sort.o - gcc: 10975 bcc: 9224 dhrystone.o: - gcc: 2739 bcc: 2581 > Adrie Koolen (adrie@ica.philips.nl) > Philips Innovation Centre Aachen Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) " Emulation is the sincerest 85 Hawthorne Crescent form of pottery." West Drayton Middlesex - William Frend De Morgan UB7 9PA
adrie@philica.ica.philips.nl (Adrie Koolen) (01/14/91)
In article <1926@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: >Your wish is my command. I can't get at the nm output on this machine, but >doing a compilation on the 386 and doing an ls -l of the object files gives: > > sort.o - gcc: 10975 bcc: 9224 > dhrystone.o: - gcc: 2739 bcc: 2581 That's interesting. The sort and dhrystone executables were much larger under bcc (26624 and 21504 text sizes) than under gcc (19456 and 15360 text sizes). As you can see, BEFORE linking, the bcc objects were slightly SMALLER than the gcc object files! Do you use the same linker with bcc and gcc? I guess not. I also assume, that you use different libraries. How do they compare in size? Anyway, the sizes of the two object files under Minix-Sparc are: sort.o: 17056 dhrystone.o: 3805 As I already expected, the Sparc objects are somewhat bigger than the 386 gcc and bcc object files! I must say that a relatively big part of the objects is the symbol table. sort.o, for instance, has some 10KB of text + data and a symbol table of 7KB! I still think that the big sizes of the 386 executable are due to bad linking and/or big library files (the Minix-Sparc libc.a is 156KB). Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen