Kang.ESM8@xerox.com, DYun.ESAE@xerox.com (08/27/90)
I'm interested in the performance differences between the SunOs 4.1 cc compiler vs. Gnu-C 1.37.1. Which generates better code? Are there patches to Gnu-C for a better code generator/optimizer? Thanks. -Steve
richard@unipalm.co.uk (Richard) (10/08/90)
> I'm interested in the performance differences between the SunOs 4.1 cc > compiler vs. Gnu-C 1.37.1. Which generates better code? Are there > patches to Gnu-C for a better code generator/optimizer? Thanks. -Steve From previous experience of gcc, it is important to distinguish which architecture you are running on. On the Sun/3 gcc makes a significant improvement (3 times faster in places) to the X server, but hardly makes any difference for Sparc or 386i architectures. Also important for us is the fact that gcc can't (in my version) handle shared libraries. Richard Nuttall richard@xtech.uucp XTech Limited, 145 St Neots Road, (richard@unipalm.uucp) Cambridge CB3 7QJ, England Tel: +44 954 211862 Fax: +44 954 211244
wolfgang@uunet.uu.net (Wolfgang S. Rupprecht) (11/01/90)
>> I'm interested in the performance differences between the SunOs 4.1 cc >> compiler vs. Gnu-C 1.37.1. >On the Sun/3 gcc makes a significant improvement (3 times faster in >places) to the X server, but hardly makes any difference for Sparc or 386i >architectures. Well, the truth is on a SPARC (SLC if it matters) gcc 1.37.1 is sometimes even worse than cc. The infamous drystone string copy test runs about 19,000 drysstones with 'cc -O' and only 14,000 with 'gcc -O'. Setting the more esoteric gcc flags singly or in groups has little effect. I suspect a few 'inline' directives would help gcc's numbers but that would be cheating. Wolfgang Rupprecht uunet!{nancy,usaos,media!ka3ovk}!wsrcc!wolfgang Snail Mail Address: Box 6524, Alexandria, VA 22306-0524
scs@lokkur.dexter.mi.us (Steve Simmons) (11/02/90)
richard@unipalm.co.uk (Richard) writes: >Also important for us is the fact that gcc can't (in my version) handle >shared libraries. Not so; gnu ld cannot handle shared libraries. If you use the system ld (or simply do 'gcc -o file -O file.o') it will use shared libraries just fine. True from 3.4 thru 4.0. Steve
jbuck@galileo.Berkeley.EDU (Joe Buck) (11/21/90)
In article <1990Oct31.235041.21555@rice.edu>, wsrcc!wolfgang@uunet.uu.net (Wolfgang S. Rupprecht) writes: > >On the Sun/3 gcc makes a significant improvement (3 times faster in > >places) to the X server, but hardly makes any difference for Sparc or 386i > >architectures. > Well, the truth is on a SPARC (SLC if it matters) gcc 1.37.1 is sometimes > even worse than cc. The infamous drystone string copy test runs about > 19,000 drysstones with 'cc -O' and only 14,000 with 'gcc -O'. Setting the > more esoteric gcc flags singly or in groups has little effect. The main reason for gcc's worse performance on Sparc is that it doesn't do instruction scheduling or delayed branches. However, Mike Tiemann (author of g++) has an instruction scheduler that will be included in the 2.0 version of gcc/g++ that does these things; he claimed a 30% performance improvement for Sparc last April when he talked at the Usenix C++ Conference. Needless to say, I am eagerly awaiting this compiler, which will also integrate NeXT's Objective-C compiler so that the same program will compile C, C++, and Objective-C. On the other hand, dhrystone is a bogus benchmark; it doesn't mean anything because it doesn't produce output that depends on input. A very smart compiler, detecting that certain loops don't do anything, will throw away whole functions. So the dhrystone people tell you to run your compiler with some types of optimization turned off! Stupid. People who write toy benchmarks like this call standard compiler optimizations "cheating" and figure out how to insert code that defeats optimizers, even though such code has nothing to do with what people really do with computers. Vendors end up putting little tricks in their compiler to make Dhrystone, Whetstone, etc, run fast at the expense of other code. Pay attention to real benchmarks, like SPEC, which measures how fast real applications run. Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck