Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!pyramid!prls!mips!djl
From: djl@mips.UUCP
Newsgroups: comp.sys.m68k,comp.sys.intel
Subject: Re: Recent Motorola ad seen in Byte
Message-ID: <285@winchester.mips.UUCP>
Date: Sun, 12-Apr-87 21:11:38 EST
Article-I.D.: winchest.285
Posted: Sun Apr 12 21:11:38 1987
Date-Received: Tue, 14-Apr-87 00:38:56 EST
References: <362@sbcs.UUCP> <1466@ncr-sd.SanDiego.NCR.COM> <580@plx.UUCP> <513@omen.UUCP>
Distribution: comp
Lines: 28
Keywords: Sieve, 68020 vs. 80386
Xref: utgpu comp.sys.m68k:326 comp.sys.intel:136
Summary: Beware Small Integer Benchmarks

In article <513@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
> In article <930@intsc.UUCP> tomk@intsc.UUCP (Tom Kohrs @fae) writes:
> 
> :Show me a benchmark that does not fit in 256 bytes thats even keeps up
> :with at 16MHz 386.  386's are now shipping at 20MHz for the speed freaks.
> :25MHz soon.
> 
> Well, here's one that takes 8k, somewhat larger than 256 bytes.  A 25 mHz
> 68020 board more than keeps up with a 18 mHz 386 box (let alone 16 mHz.)

Goes on to include a version of seive, a classic small integer benchmark.
Please note, on the MIPS R2000, the entire main() procedure of this
benchmark (not just the inner loop, which is what counts), is 53
instructions, or 224 bytes.  Most of the total text size comes from printf().

It is safe to assume that on a CISC machine, the inner loop fits quite
nicely in a 256 byte I cache. this is exactly what you must avoid if trying
to get a real handle on performance under actual conditions.

If what you care about is performance of a processor on very small
integer compute loops, then use sieve and its ilk.  If what you care
about is performance under actual application conditions, you must
use benchmarks that more accurately reproduce those types of environments.

-- 
			***dan

decwrl!mips!djl                  mips!djl@decwrl.dec.com