tower@WHEATIES.AI.MIT.EDU (Leonard H. Tower Jr.) (11/11/88)
Return-Path: <@ai.ai.mit.edu:osu-cis!uucp@tut.cis.ohio-state.edu> To: gnu-announce@tut.cis.ohio-state.edu Path: osu-cis!att!cbnews!res From: res@cbnews.att.com (Robert E. Stampfli) Newsgroups: unix-pc.general,gnu.announce Subject: benchmarking gcc 1.30 on a Unix-PC 7300 Keywords: gnu cc benchmark dhrystone Date: 31 Oct 88 02:10:08 GMT Organization: AT&T Bell Laboratories, Columbus I just recently reconstituted the gnu C compiler posted to unix-pc.sources by Mike Thompson (thanks, Mike!) and thought I would try to gage how good it is against the vanilla compiler provided as part of the 3.5 development set. So I pulled out a copy of the dhrystone benchmarks. Here are the results: System: Unix-PC 7300 w/2.0 Megs Memory (0.5 on motherboard/1.5 on combo board) Running Unix 3.5.1.3 CC: Standard C compiler provided with 3.5 development set for the 7300. GCC: Gnu C compiler version 1.30 provided by Mike Thompson. Benchmark: Dhrystone Version 2.0 CC GCC options dhry size c-time dhry size c-time ------- ------ ----- ------ ------ ----- ------ none 887.6 27168 1m12s 793.7 27220 1m33s -DREG 966.2 27168 1m13s 854.7 26196 1m34s -O 953.9 27168 1m21s 1022.1 26196 1m41s -DREG -O 1030.9 26144 1m20s 1022.1 26196 1m39s Notes: 1. Each dhrystone benchmark was run 3 times, calculating 10000 dhrystones per run. The high and low runs were discarded. What appears above in the dhry column is the run that was left. (Bigger number means faster calculation -- the actual number is the time in microseconds to calculate one dhrystone.) 2. The size is the actual size of the executable a.out, in bytes, after stripping. 3. c-time is the total elapsed time to compile the dhrystone program, using the ksh built-in "time" command (minutes and secs). 4. -DREG=register is an option to the dhrystone benchmark which explicitly declares register variables. Without it, no variables are declared to be registers. 5. -O is the compiler optimizer flag. 6. The test was conducted on an otherwise idle system. When cron fired up something during a test phase, the results of that phase were discarded and the test rerun. 7. The standard cc command consistently issued a warning dhry_pack_2.c, line 42: warning: enumeration type clash, operator = during every compile. 8. With the optimizer under gcc, the dhrystone program complained, when run, that the array element *Arr_2_Glob[8][9] == 9, when it should contain the number of runs + 10 (10010). With cc, and non-optimized gcc, the value of this array element was correct. So what does this mean? It looks to me like both compilers produce excellent code. Obviously, this is only one benchmark, and both compilers have their problems. For instance, cc has known problems with code generation for functions returning unsigned quantities, while gcc was unable to produce a runnable copy of the obsfrucated "maze" program, recently posted to the net (when the executable it produced was run, it dropped a core). There may be a bug in the optimization phase of gcc, but heck, how can you argue with the price? For me, cc appears to be more mature and seems to have a slight edge in compilation speed. I think I will stick with the provided compiler, for now, but keep gcc around just in case. Hope you find this interesting. I'd like to know if you try any other benchmarks with gcc, or notice other problems with it. Rob Stampfli att!cbnews!res (work) osu-cis!n8emr!kd8wk!res (home)