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