Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!aplcen!haven!ncifcrf!lhc!usenet
From: usenet@nlm.nih.gov (usenet news poster)
Newsgroups: comp.arch
Subject: Re: Discontintuiy
Message-ID: <1990Sep24.041001.24220@nlm.nih.gov>
Date: 24 Sep 90 04:10:01 GMT
References: <10550@pt.cs.cmu.edu>
Reply-To: states@tech.NLM.NIH.GOV (David States)
Organization: National Library of Medicine, Bethesda, Md.
Lines: 36

In article <10550@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:
>[...]
>high speed is best served by having a fast primary cache, and a
>slightly slower secondary cache.  But notice the following simulation
 ^^^^^^^^^^^^^^^
>results (High Performance Systems, Sept89 P. 76):
>
>	Sustained Native MIPS for an idealized 100 MHz RISC CPU:
>
>Secondary Cache in KB =	64	128	256	512
>
>Primary =  8 K			49	62	75	80
>Primary = 16 KB		51	65	79	85
>Primary = 32 KB		52	67	83	89
>
>...that is, the cache faults slow the CPU from 100 MIPS to 89 MIPS
>(best case) or 49 MIPS (worst case).  The important thing here is to
>read these numbers across, and then read them down.  Notice that
>throughput just isn't that sensitive to the size of the primary
>cache.

Isn't the key here the use of a secondary cache which is only slightly
slower?  

>I conclude that between 1 MT and 100 MT, there is a region where we
>can't get the secondary cache on-chip, and a primary cache big enough
>to fill up the chip would have nil or negative benefit.

What would the results be in a system configured without a secondary cache?
Maybe the high end system will require secondary cache. Might not a big chip 
which didn't require secondary cache be an overall win on lower end systems?

>-- 
>Don		D.C.Lindsay

David States