Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!bbn!gatech!mcnc!davis
From: davis@mcnc.org (Mark C. Davis)
Newsgroups: comp.arch
Subject: Do RISC Compilers Consider Multiprogramming?
Message-ID: <620@speedy.mcnc.org>
Date: 3 May 88 12:56:43 GMT
Organization: Microelectronics Center of NC; RTP, NC
Lines: 41
Keywords: RISC compiler context-switch architecture multiprogramming


(This is a repost.  If you have seen this before, I appologize, but my
first posting did not make it to some nearby sites).

This is an extension of the discussion of using RISC processors for real
time jobs.  Real time is actually large order multiprogramming
with deadlines (as averse to large order multiprogramming without
deadlines - i.e. timesharing).

A central assumption for RISC is that modern optimizing compilers can
produce efficient code for such machines.  These compilers further
assume that they can predict the state of the machine, eg. register 1
contains a certain variable or keeping inner loop code close together
will make it more likely for a cache hit.

These assumptions seem quite reasonable for uniprocessors and low order
multiprogramming (which I will arbitrarily define as < 20 context
switches / sec which on my Sun 3/60 corresponds to a load average
(processes waiting to run) of < 0.50)).

However, on a high order multiprogramming machine ( > 100 context
switches / sec) assumptions about machine state may no longer be
correct.  Data may need to be reloaded into registers before continuing
(admittedly an operating system task, but one that must be done if data
is kept in registers) and code may no longer be in the cache.

My questions for comp.arch are these:

        1. Do any RISC compilers consider the effects of frequent
           context switch on their optimizations?

        2. Does large order multiprogramming invalidate a primary
           assumption of RISC so that other architectures are better for
           this application?

Disclaimer: I believe that RISC is the best solution to low order
multiprogramming (like my workstation).  But, there does seem to be this
application of uniprocessor high order multiprogramming that will not go
away (people wanting to put 40 users on a sun 4 and process control
with zillions of independent processes).

Thanks for you thoughts - Mark (davis@cs.unc.edu or decvax!mcnc!davis)