Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!dg!Publius
From: Publius@dg.dg.com (Publius)
Newsgroups: comp.arch
Subject: Re: Multiprocessing in your own PC lab
Message-ID: <420@dg.dg.com>
Date: 2 May 90 15:25:23 GMT
References: <0093608E.3DCAF480@KING.ENG.UMD.EDU>
Reply-To: publius@dg-pag.webo.dg.com (Publius)
Organization: Data General, Westboro, MA.
Lines: 37

In article <0093608E.3DCAF480@KING.ENG.UMD.EDU> sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes:
>I know this will sound hairbrained, but you only live once...
>
>Couldn't you take a room full of workstations or PCs and (through the
>appropriate software) treat them as a one big parallel processing
>machine? Of course, you would have to set up a scheduler, figure out
>how to parallelize your code/problem accordingly (obviously this wouldn't
>work for a linear-type problem), and be able to parse everything out on
>the network to each one of your nodes. 
>
>You would also have to tolerate Ethernet as your 10Mb/second bus, something
>which the more religious would consider blasphmeous....but I guess it
>could be done. 
>
>Need another set of nodes? Shut down a terminal room for a weekend ;-).
>
>				Doug


Well, there are two sorts of issues here.  One is hardware and the other
is software.
On the hardware side, a network of workstations and PCs do not share
memory at the machine code level.  Thus, you have totally different
programming model.  Of course, this can be overcome by implementing
virtual addressing across the network.  Then you need a lot of additional
software and what kind of performance you will get out of it is a
question.
On the software side, you have a network of operating systems, instead of
a network operating system.  Each operating system has control only over
its own resources.  Besides, there are problems like naming resolution,......


-- 
Disclaimer: I speak (and write) only for myself, not my employer.

Publius     "Old federalists never die, they simply change their names."
publius@dg-pag.webo.dg.com