Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!orchid!clyde!rutgers!mit-eddie!uw-beaver!tektronix!reed!omen!caf
From: caf@omen.UUCP
Newsgroups: comp.sys.m68k,comp.sys.intel
Subject: Re: Recent Motorola ad seen in Byte
Message-ID: <518@omen.UUCP>
Date: Wed, 15-Apr-87 00:10:05 EST
Article-I.D.: omen.518
Posted: Wed Apr 15 00:10:05 1987
Date-Received: Fri, 17-Apr-87 05:26:05 EST
References: <362@sbcs.UUCP> <1466@ncr-sd.SanDiego.NCR.COM> <580@plx.UUCP> <513@omen.UUCP> <285@winchester.mips.UUCP>
Reply-To: caf@.UUCP (PUT YOUR NAME HERE)
Distribution: comp
Organization: Omen Technology Inc, Portland Oregon
Lines: 22
Keywords: Sieve, 68020 vs. 80386
Xref: utgpu comp.sys.m68k:334 comp.sys.intel:140

In article <285@winchester.mips.UUCP> djl@mips.UUCP (Dan Levin) writes:
: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.

I thought many programs spend time looping in fairly localized loops,
especially on machines that lack high powered string instructions that
are useful to C.  What are "for" and "while" statements for?  Note that
you can have a 50 line for loop that still gets good cache hits if most
of the code is usually not executed.

So let's ask: how does the performance improvement provided by a small
chache on sieve compare with the performance improvement with ditroff
and tpscript for example?

While it is conceivable that Motorola put the 256 byte cache in the 68020
just to help certain benchmarks,  it is more likely that the cache
actually improves performance rather inexpensively.

Does somebody have real data on how the 68020's cache improves performance
on sieve, troff, sort, and other Unix CPU hogs?