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