🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13057

Re: shared memory multiproc. question

#13057
From: pase
Date: Mon, 23 Feb 1987 17:36
40 lines
3098 bytes
In article <loral.1379> ian@loral.UUCP (Ian Kaplan) writes:
>In article <5699@amdahl.UUCP> chuck@amdahl.UUCP (Charles Simmons) writes:
>>Seeing how two different people suggested that distributed memory is
>>inappropriate for multiple users running independent tasks, maybe someone
>>could tell me why.  I find it hard to imagine a problem which is more
>>partitionable.  
>
>  Someone else in this news group has already suggested that one problem
>  that must be solved before a distributed memory parallel processor can 
>  be used to support multiple users is access to I/O resources.  I agree 
>  with this, but meeting this requirement is not sufficient.  Assuming 
>  that the objective is to do the sort of work that is done on the average 
>  UN*X system, a distributed memory parallel processors is a poor choice
>  for supporting multiple users.
>  [...]

Distributed memory networks have been used for multi-user systems for several
years now - cf. Apollo networks.  Some, at least, would argue they have been
used successfully.  However, machines like the iPSC were designed to do heavy
computing, and NOT a lot of resource sharing.  The cube manager is too much of
a bottleneck to be used as a resource server to the tower.

At FPS we used a 10-node Apollo network.  5 nodes had disks, but performance
was still poor.  Our best guess was that the network more than anything else
was the limiting factor.  Processors were idle while they waited for the data
to come back over the net.  The Apollo network used a ring, which is slow,
but the point is that half of the nodes had local disks, all nodes had 2 Mbyte
of memory, and performance was often bad.  The iPSC has 512 Kbyte, a better
network topology, and a bottleneck called the cube manager.  The I/O throughput
is such that it might successfully support 4 to 8 processors as task servers,
but the cube manager would be absolutely swamped with much more than that.  As
poor as the Apollo performed, the iPSC would do worse.  (To be perfectly fair
to Apollo, our load was heavier than their system was really designed for.)

The hypercube is set up to do number crunching, with lots of operations per
byte of I/O.  If your application is heavily biased towards I/O, or sharing
a particular resource, the iPSC will not perform as well.  What it does, it
does well.  Supporting lots of users just isn't one of the things it does.
-- 
Doug Pase   --   ...ucbvax!tektronix!ogcvax!pase   or   pase@Oregon-Grad
Technical Details
Message-ID: <1210@ogcvax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!vrdxhq!verdix!ogcvax!pase
References: <1205@ogcvax.UUCP> <5699@amdahl.UUCP> <loral.1379>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!vrdxhq!verdix!ogcvax!pase
From: pase@ogcvax.UUCP
Newsgroups: comp.arch
Subject: Re: shared memory multiproc. question
Message-ID: <1210@ogcvax.UUCP>
Date: Mon, 23-Feb-87 12:36:06 EST
Article-I.D.: ogcvax.1210
Posted: Mon Feb 23 12:36:06 1987
Date-Received: Fri, 27-Feb-87 01:06:14 EST
References: <1205@ogcvax.UUCP> <5699@amdahl.UUCP> <loral.1379>
Reply-To: pase@ogcvax.UUCP (Douglas M. Pase)
Organization: Oregon Graduate Center, Beaverton, OR
Lines: 40