Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!preece
From: preece@ccvaxa.UUCP
Newsgroups: comp.arch
Subject: Re: Single tasking the wave of the futu
Message-ID: <28200076@ccvaxa>
Date: 16 Dec 87 20:06:00 GMT
References: <3445@hoptoad.uucp>
Lines: 45
Nf-ID: #R:hoptoad.uucp:3445:ccvaxa:28200076:000:2030
Nf-From: ccvaxa.UUCP!preece    Dec 16 14:06:00 1987


  fay@encore.UUCP:
> Every fork() (or thread_create() in Mach) in every program can get
> scheduled on a different cpu (that includes every shell per user,
> daemon, background task, ... Also, don't forget all those kernel
> processes (or tasks, threads) running on different cpus (pagers, signal
> handlers, ...). How difficult is it when the O.S.  does it
> transparently?
----------
Oh, goody, then I can just forget about all my cache history, whether
my process has to go through any extra latency to get to its memory,
inter-processor signalling delays, and all those little things that
get tacked on when everything isn't all in one big processor?

There is a reasonably strong literature showing that,
in general, each additional processor buys you less additional
throughput than the one before (ELXSI to the contrary notwithstanding).
There are some nasty overheads and bottlenecks that add up; in most
implementations they add up more than linearly.

> Since this is not true, the only thing to overcome is common prejudice.
> Price/performance advantage (for small multiprocessor minis and up) is
> huge.

[I must confess, someone inside encore told me once that the good thing
about the machine was its flat response to additional load -- it started
out like a soggy 750 and stayed just the same until the load killed it
completely, which is not bad for the processors involved.]

> By the way, I don't fault people for not understanding about multis
> (e.g., from past exposure or school). It takes some time for common
> misconceptions to catch up to current reality.

Nobody outside of sales and marketing should try to claim that current
reality is anything but "Nobody understands multiprocessing yet."
It certainly is not the case that the kind of simple task migration
mechanisms you describe can buy anything like effective transparent use
of multiprocessing beyond a very small number of shared memory
processors.

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@Gould.com