Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!ark
From: ark@alice.UucP (Andrew Koenig)
Newsgroups: net.arch
Subject: Re: RISC cache vs CISC u-code
Message-ID: <5093@alice.uUCp>
Date: Sat, 8-Mar-86 20:19:52 EST
Article-I.D.: alice.5093
Posted: Sat Mar  8 20:19:52 1986
Date-Received: Sun, 9-Mar-86 08:17:13 EST
References: <570@imag.UUCP>
Organization: Bell Labs, Murray Hill
Lines: 25

> OK, but what when the system is multiprogrammed? Frequent swaps between
> processes aren't likely to break the cache efficiency?   This could be
> the cause of important degradation of RISC performance in multiuser
> environment (Cf previous discussions about the Ridge).
>
> ... Or am I missing something?....

The IBM 360/91 was one of the fastest machines of its time.
Although it took 360 nanoseconds to read from memory and
720 nanoseconds to write, the machine was nevertheless capable
of executing one instruction every 60-nanosecond cycle (when
running a well-tuned program) because of heavy memory interleaving
and pipelining.

This raised the problem of how to synchronize the CPU with the
clock, which was apparently stored in memory and was updated
every 60th of a second.  They did it by quiescing the entire
machine for each clock tick.  The loss of performance was trivial
compared with the expense of handling the clock some other way.

The same may be true of context switching on RISC machines with
caches.  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.