Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!pyramid!prls!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: comp.sys.m68k,comp.sys.intel
Subject: Re: 386 vs 020 and big benchmarks (sieve)
Message-ID: <318@winchester.UUCP>
Date: Sun, 19-Apr-87 15:57:09 EST
Article-I.D.: winchest.318
Posted: Sun Apr 19 15:57:09 1987
Date-Received: Sun, 19-Apr-87 23:46:13 EST
References: <930@intsc.UUCP> <513@omen.UUCP> <933@intsc.UUCP> <523@omen.UUCP>
Reply-To: mash@winchester.UUCP (John Mashey)
Distribution: comp
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 41
Xref: mnetor comp.sys.m68k:375 comp.sys.intel:168

In article <523@omen.UUCP> caf@.UUCP (PUT YOUR NAME HERE) writes:
>In article <933@intsc.UUCP> tomk@intsc.UUCP (Tom Kohrs @fae) writes:
>:> :Show me a benchmark that does not fit in 256 bytes thats even keeps up
>:                                            ^^^^^^^^^  (note for ref.)
>:> :with at 16MHz 386.  386's are now shipping at 20MHz for the speed freaks.
>:> :25MHz soon.
>OK, here's one that may not fit in 256 bytes.
>
>time bc <<f
>2 ^ 4096
>f
>

Sigh.  This illustrates how extremely careful one must be, and how nonintuitive
computer performance analysis can be.  The rest of this is NOT in support of
a 256-byte cache being "enough" (for lots of real programs, it sure would
help to have bigger ones), but simply to show 2 things:
a) One must be careful.
b) The classic "bc" tests are VERY unrepresentative of most real programs.

I ran this program, using our program that turns an executable into a
profiled executable [of dc, of course, most of the time is spent in dc].
99% of the CPU time is spent in one function [mult]
98% of the CPU is spent in 6 source lines [1080-1085 in 4.3BSD dc.c].
On MIPS R2000 [which uses 32-bit instructions, and is often less dense than
more CISCy machines,] this code occupies......
	260 bytes.
Even stranger, about 35-40% of the total cycles are in multiply, divide,
and remainder, a behavior pattern found in no other benchmark that
we've looked at [and we have detailed statistics on dozens of large,
real programs].  On many programs, you see <1% for these together,
on some you might get up to 10%, but that's about it.

One more time: computer architecture arguments CANNOT be settled
by intuition and examination of isolated examples.  If you aren't
following comp.arch, turn it on and retrieve the last few weeks'
flurry of discussions on strings and word-vs-byte addressing.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086