Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!mips!phoenix!chrism
From: chrism@mips.COM (Christopher Marino)
Newsgroups: comp.arch
Subject: Re: Discontintuiy
Message-ID: <41750@mips.mips.COM>
Date: 26 Sep 90 19:37:48 GMT
References: <10550@pt.cs.cmu.edu>
Sender: news@mips.COM
Reply-To: chrism@mips.COM (Christopher Marino)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 45

In article <10550@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:
>
>It occurs to me that as chips get bigger, we have to cross an
>interesting discontinuity.

I don't dispute your observation that there is somewhat of a
discontinuity here. However, there are implementation issues that complicate
the problem a little.

The MIPS 6280 is a machine that confirms the data that you present.  Here is 
a machine that has a relatively small primary cache and a large secondary
cache. (16 KB primary data, 64 KB primary instruction, 512 KB shared secondary)
The penalty of a primary cache miss depends a lot on how you build it (speed
of the parts, datapaths etc.). Given the constraints of this design, the
benefits of larger primary caches could not be justified.

My guess is that the design of the secondary cache would be optimized to take
full advantage of the primary cache that does get integrated on the chip.
What comes to mind is that faster parts and wider datapaths would be used for
the secondary cache.  This would alter the performance characteristics of the
machine as the secondary cache gets smaller (the penalty of a miss would be
smaller).

Getting the primary cache on chip will be change many of the working
assumption that were used to generate the data that you present. 
>

>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.
>
>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.
>
>-- 
>Don		D.C.Lindsay