[comp.sys.apple] benchmarking compilers vs. processors

dlyons@Apple.COM (David A. Lyons) (02/15/90)

In article <16747.apple.net@pro-sol> ruzun@pro-sol.cts.com (Roger Uzun) writes:
>In-Reply-To: message from gsnow@pro-freedom.cts.com
>
>I base the 65816 running at 1/3 to 1/4 the speed of a similar
>clocked 68030 on ACTUAL BENCHMARKS.  for example
>the following standard C benchmarks [...]
>These are all on a 28 Mhz 68030 system.  Compare to the 65816 values.
>-Roger

I've never seen a 65816 C compiler produce impressive object code--
benchmarking a compiler isn't the same thing as benchmarking the
processor.
-- 
David A. Lyons, Apple Computer, Inc.      |   DAL Systems
Apple II Developer Technical Support      |   P.O. Box 875
America Online: Dave Lyons                |   Cupertino, CA 95015-0875
GEnie: D.LYONS2 or DAVE.LYONS         CompuServe: 72177,3233
Internet/BITNET:  dlyons@apple.com    UUCP:  ...!ames!apple!dlyons
   
My opinions are my own, not Apple's.

gwyn@smoke.BRL.MIL (Doug Gwyn) (02/15/90)

In article <38645@apple.Apple.COM> dlyons@Apple.COM (David A. Lyons) writes:
>I've never seen a 65816 C compiler produce impressive object code--
>benchmarking a compiler isn't the same thing as benchmarking the
>processor.

If one is going to be using the compiler, then it had better be included
in the performance measurement!

ORCA/C doesn't seem to do too badly when full optimization is enabled.

I long ago learned not to code in assembly language unless it was forced
by the circumstances (e.g. in writing some of the run-time support for a
compiler).  My time is too valuable to waste like that on a one-machine
project.

ruzun@pro-sol.cts.com (Roger Uzun) (02/17/90)

In-Reply-To: message from dlyons@Apple.COM

>> Comment from David Lyons about benchmarks and C compilers.
You are quite right, the benchmarks in general test the system with
it compiler.  They bench the system and compiler together, and are unfair
to the system if the compiler is of low quality.  The fact that there are
a lot of high quality 680x0 compilers are a big plus for that architecture in
my opinion.  However note that lichty and eyes, in their 65816 book, indicate
that the 65816 is not as fast as a similar clocked 68000 for the sieve
benchmark in optimized assembler.  They further state that the sieve is a good
indication of cpu performance.  Note that the 68030 is 6 times faster than a
68000 at the same clock rate, if the 68000 is 0 wait states and the 68030 uses
a 1 wait state, burst mode enabled design.  All in all, a 65816 system could
probably not achieve 1/4th the speed, in hand optimized assembly benchmarks,
of a 68030 system clocked at the same speed.
 
-Roger