Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site frog.UUCP
Path: utzoo!linus!decvax!genrad!panda!talcott!harvard!think!mit-eddie!cybvax0!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: net.arch
Subject: Re: Cache revisited
Message-ID: <268@frog.UUCP>
Date: Thu, 15-Aug-85 12:57:14 EDT
Article-I.D.: frog.268
Posted: Thu Aug 15 12:57:14 1985
Date-Received: Wed, 21-Aug-85 05:53:15 EDT
References: <5374@fortune.UUCP> <901@loral.UUCP> <2583@sun.uucp> <5459@fortune.UUCP>
Distribution: net
Organization: Charles River Data Systems, Framingham MA
Lines: 28

>Someone...said that the hit rate on the internal cache in the 68020 is about
> 50%. Anyone care to agree with that?  Anyone care to tell me what 
> reasonable application or operating system spends 50% of its time
> in loops that are smaller that 256 bytes??
> ... 
> But, hey, I could be wrong. It's happened before. So let's hear it. Anyone
> who claims high cache hit rates on normal applications, let's hear the
> justification for them.
> 
We recently measured the cache-hit performance of our prototype 68020 board
on a number of programs, some useful, some benchmark type programs (including
the good old Knight's tour).  Results were:

	The '20 I-cache had a hit rate of between 30% and 58%.  Our 8Kb
external cache had a hit rate of 70-83%; between them (when both turned on),
they had a hit rate of 76-89%.  The 68000 board (our current product, and
from which the current 68020 board was devised [roughly]) had a cache hit
rate (only an 8Kb external cache, of course) of between 86% and 93% on the
same programs.

	And indeed, we found that few reasonable loops are small enough to
fit into the I-cache (especially since the Greenhills C compiler tries to
be really clever about loop unrolling and re-ordering of code).


--
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA