Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Discontintuiy
Message-ID: <10550@pt.cs.cmu.edu>
Date: 24 Sep 90 02:55:14 GMT
Organization: Carnegie-Mellon University, CS/RI
Lines: 35


It occurs to me that as chips get bigger, we have to cross an
interesting discontinuity.

Today, a million transistor chip (like the 68040 or i860) will have 8
KB of onchip cache.  Of course, that's not enough: a high end system
needs 128 KB or even 1 MB per processor.  When we get to 50 or 100
MT/chip, then we can do that.

The discontinuity is that for intermediate chip sizes, we _don't_
want to just have an intermediate sized cache. The reason is that
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.

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