Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!ncar!ames!amdahl!pyramid!prls!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Do RISC Compilers Consider Multipro
Message-ID: <2137@winchester.mips.COM>
Date: 6 May 88 08:07:35 GMT
References: <620@speedy.mcnc.org> <28200140@urbsdc> <52183@sun.uucp>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 74

In article <52183@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
....
>For example, the current virtual-address-cache Sun machines spend lots of their
>context-switch time flushing the old U page from the cache (I think this was
>mentioned in one of the Usenix or EUUG papers on the new SunOS 4.0 virtual
>memory system).  Even on Sun-4s, this time substantially dominates the
>register-window-flush time.  Arranging to have the U area at different virtual
>addresses in different processes will probably be a much bigger win than
>getting rid of the register windows.

There was a good article on this in the Summer 1987 Usenix (Phoenix),
although describing the virtual cache issue in the Sun3/2xx (same issue).
Guy is right on: you really have to add up ALL of the effects for
context-switching, many of which are hard to measure.
My list of effects, for context-switching amongst N processes:

1) Time to save state of previous process necessary to be saved.

2) Time to load in as much of the state of the new process as necessary.

3) Time to flush/setup memory management hardware.

4) Time to do any cache-flushing needed.

5) Time to execute the OS code paths needed.

Note that 1-4 are mostly architecture-related, while 5) is a function of
the OS choice (i.e., vanilla UNIXes may be rather different than real-time
OS's).  Items 1&2 are mostly instruction-set architecture dependent.

Note that one might add some implicit effects that may well cause
programs to run at different speeds in multiprogramming envrionment:

6) Linearity or lack thereof in 2), 3), and 4).  For example,
a VAX is linear on 3), because the TLB has entries for 1 user process,
and you flush it each time.  In systems with M contexts, you may notice
nonlinearities of overhead for 3)  when you start rapidly switching
amongst >M processes. (This happens with any such resource).

7) For cached systems, impact of multiple-processes and kernel
upon cache hit ratio of any given process.  This can depend a lot
of cache design, although it doesn't matter much for small caches.
As machines get faster, and caches bigger, the nature of the cache
design may become relevant, although relatively little is published
on this.  However, we're getting to the point where useful programs are
actually smaller than caches, and it is nice if programs don't
unnecessarily stomp on each other in the cache.  In a multi-process
environment with multiple instances of the same programs being used,
either the text segments should be shared in the cache,
or one should go to shared libraries.  (The latter is probably useful
for some virtual cache designs that make the former hard.)

As can be seen from this discussion, there is very little that has
anything to do with RISC versus CISC, especially in the long run.
Given a similar OS, the first-order effects are likely to come
from MMU & cache design effects.

It is interesting to note that uncached machines are likely to be
more linear (with increased processes) than cached ones, whether RISC or CISC,
i.e., an uncached machine can switch amongst processes with zero cache-related
penalties, whereas a cached one will usually take at least some hit.
Note: more linear does not necessarily equal faster! (thank goodness)

Thus, to answer the question that started all of this:
	a) Certainly some RISC machine designs carefully considered
	multiprogramming (HP Precision and MIPS R2000 are certainly
	examples, and I'm sure there are more.)
	b)  However, ti doesn't matter much: most of the first-order
	effects have nothing to do with RISC versus CISC.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086