jpn@teddy.UUCP (John P. Nelson) (12/13/87)
I just recently aquired Microsoft C 5.0, and I decided that it would be interesting to pit both Quick C and MSC 5.0 against Turbo C with a few benchmark programs. I think that the net might be interested in the results. I don't claim that I did a COMPREHENSIVE comparison, but I did get a couple of interesting data points. I've got results from three programs: #1: sieve.c, as distributed with MSC. #2: dhrystone 1.1. #3: MicroEmacs 3.9e. #1 and #2 were compiled with the small model on all compilers, and #3 was compiled large model. I've got several comments that don't really fit into the table, also (see below): TCC: turbo C QCL: quick C CL: microsoft C 5.0 +---------+----------+---------+---------+------+------+------+---------------+ |Source | Compiler | Special | Compile | Run | .OBJ | .EXE | Special | |Program | | Flags | Time | Time | Size | SIZE | | +=============================================================================+ | | | | | | | | Before Exepack| | | TCC | | 16 | 26 | 8646 | 5791 | 13714 | | +----------+---------+---------+------+------+------+---------------+ | sieve.c | QCL | | 24 | 31 | 900 | 7221 | 15423 | | +----------+---------+---------+------+------+------+---------------+ | | CL | -Ox | 30 | 21 | 474 | 7189 | 15391 | +=============================================================================+ | | | | | | | | Dhrystones | | | TCC | | 17 | 55 | 2302 | 9044 | 909 | | +----------+---------+---------+------+------+------+---------------+ | dry.c | QCL | | 27 | 60 | 3634 |10683 | 833 | | +----------+---------+---------+------+------+------+---------------+ | | CL | | 50 | 48 | 2577 |10331 | 1014 | | +----------+---------+---------+------+------+------+---------------+ | | CL | -Ox | 50 | 39 | 2413 |10171 | 1282 | +=============================================================================+ | | | | | | | | .OBJ |LIBRARY| | | TCC | -ml -O | 9:04 | ** | ** | 94250| 65247 | 7857 | | Micro +----------+---------+---------+------+------+------+---------------+ | Emacs | QCL | -AL | 12:45 | ** | ** |136145| 94349 | 9569 | | 3.9e +----------+---------+---------+------+------+------+---------------+ | | CL | -AL -Os | 26:16 | ** | ** |113287| 72791 | 9569 | +=============================================================================+ Special Entries: 1. For sieve.c, all three compilers benefitted from EXEPACK, because of a large initialized (to zero) array. 2. For dry.c the # of drystones reported by the program. More is better. See the notes on hardware configuration. 3. For MicroEmacs, I did not list the execution time nor .OBJ size. What I DID list was the component of the text size contributed by the combined .OBJs, and the component contributed by the large model library. I also compiled using the "optimize for size" option, since I was hoping to shrink the program enough to make it fit into the Compact model. No such luck. Turbo C showed well. It generated the most compact code for all benchmarks. Both the library and the .OBJ code size beat both Quick C and MS C. Also, Turbo C beat quick C in compile time, execution time, and executable size. Quick C showed badly. It was inferior to the other compilers in nearly all respects (it is faster than QC, but that's about it). Microsoft C did about as I expected. It's still a slow mother of a compiler, but it generates fast code. One thing that surprised me was that it generated BIGGER code than Turbo C, even if it was faster. I also tried Microsoft C with the -Ox option on MicroEmacs, but that made even larger code. I don't really like the integrated environments, my main concern is compile speed and program performance. I also did not compile for debug under any compiler: this is the main benefit of QCC over Turbo. No doubt this would have increased the compile time. Note: You are almost GUARANTEED not to get the same results I did (timewise, anyway), because I have a weird configuration. I have a XT clone with an 80286 accelerator card, and a Megabyte of disk cache (EMS). I made sure the disk cache was flushed before each run to make sure that this did not effect the results (Turbo C ran even FASTER when I didn't do this).
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (12/15/87)
I think the recent benchmarks are reasonably representative of the state
of C compilers today. I rarely use QC, because all of the things I want
to do require options, libraries, etc. I like MSC because I have a
minimum number of surprizes porting UNIX code to the segmented
archetecture.
I *believe* that the size of MSC routine is not due to the object size,
but to the size of the routine in the library. It seems that some
compromise between link time and exe size was made. If many routines are
compiled into one object the load time will be better due to fewer
library searches, while separate compilation leads to smaller exes but
longer link time.
Some day when I have time I'll pull apart the library source, recompile
them in the smallest blocks I can, and see what it does for the exe
size.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -meroot@gryphon.CTS.COM (The Super User) (12/16/87)
In article <4516@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: >compiler, but it generates fast code. One thing that surprised me >was that it generated BIGGER code than Turbo C, even if it was faster. >I also tried Microsoft C with the -Ox option on MicroEmacs, but that made >even larger code. Microsoft C optimizes by default. Specifying -Ox enables loop optimzation, in-line intrinsic function generation, and relaxed alias checking. Loop optimization doesn't remove a whole lot of code (usually) and inline intrinsic generation trades larger code size for speed. Thus one might expect the code size to increase with the -Ox switch. There are some problems with inline intrinsic function generation as illustrated by the following sample: /* cl -c -Fc -G2 -Zl -Zi -K test.c */ good() { unsigned i, r; char *s; r = strlen(s); /* works ok */ r = 43 * strlen(s); /* works ok */ r = strlen(s)/40; /* works ok */ } bad() { unsigned i, r, k; char *s; r = 80/strlen(s); /* compiler loops (hangs) */ r = 43 * 80/strlen(s); /* "Compiler Internal Error" */ r = strlen(s)/strlen(s); /* "Compiler Internal Error " */ r = i/strlen(s); /* "Compiler Internal Error" */ } ------------ outp(port, a ? b : c); also gives an Internal Compiler Error under conditions. Use of intermediate variables or disabling inline generation works around these bugs. > >I don't really like the integrated environments, my main concern is >compile speed and program performance. I also did not compile >for debug under any compiler: this is the main benefit of QCC over >Turbo. No doubt this would have increased the compile time. > >Note: You are almost GUARANTEED not to get the same results I did (timewise, > anyway), because I have a weird configuration. I have a XT clone with > an 80286 accelerator card, and a Megabyte of disk cache (EMS). I > made sure the disk cache was flushed before each run to make sure > that this did not effect the results (Turbo C ran even FASTER when > I didn't do this).