Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.arch
Subject: Re: RISC cache vs CISC u-code
Message-ID: <447@umcp-cs.UUCP>
Date: Sun, 23-Mar-86 12:08:02 EST
Article-I.D.: umcp-cs.447
Posted: Sun Mar 23 12:08:02 1986
Date-Received: Tue, 25-Mar-86 04:43:22 EST
References: <570@imag.UUCP> <5093@alice.uUCp> <1128@unc.unc.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 28

In article <1128@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes:

>>If no more than 100 or so context switches occur per
>>second, and the machine executes tens of thousands of instructions
>>between context switches, it doesn't really matter that the cache
>>is flushed each time.  [Andrew Koenig]

>It *can* matter, depending on how big the cache is and on how full it
>must be to achieve a good hit ratio.

[followed by some numbers to demonstrate this]

True enough, or at least from my software perspective (I know little
about cache design).  However, one argument on the RISC side is
that if the processors are simple and cheap enough, you need never
context switch.  Just assign one processor-plus-cache per process.

This sounds like a parallel computation engine, but it need not
be.  If it is easier to design the rest of the system as a
single-CPU-at-a-time machine, and each CPU costs, say, $5, you
can easily stick 100 CPUs into a $40K machine.  This cuts the
context switch rate by a factor of 100.  Of course, there are
cache contention problems if you have shared data.  Just a crazy
idea, no doubt...?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu