🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13035

Re: shared memory multiproc. question

#13035
From: ian
Date: Fri, 20 Feb 1987 23:26
53 lines
3495 bytes
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.

  Charles Simmons suggests in his article that one way to allow multiple
  users to make use of a distributed memory parallel processor is to 
  dedicate individual processors to the system's users.  I have seen 
  "home grown" systems that did just this.  A system that permanently 
  allocates a processor to a user until the user logs out makes very 
  poor use of the system hardware, since it is used only a fraction of 
  the time.  Such a system could not compete with shared memory systems 
  like those offered by Sequent or Encore.

  In a distributed memory system hardware utilization cannot be increased
  by dynamically moving a process between processors, since the overhead
  incurred is so large.  This option is only realistic for tasks that take
  so long that the overhead is a small part of the execution time.  This 
  is not true for many applications.

  Dynamic process "allocation" is practical on a distributed memory system
  that uses the Single Program Multiple Data Stream (SPMD).  This 
  model is used on the iNTEL cube.  SPMD downloads the same code to all
  processors.  To execute a process, a short message is sent to a
  processor telling it what to execute.  There is little overhead since 
  the code is already resident.  However this model introduces some 
  significant costs.  Consider a parallel processor that consists of 32 
  processing elements (PEs), where each one has 512K bytes of memory.  The 
  processor potentially has 16M bytes of memory available.  Under the SPMD 
  model, only 512K bytes is really available for use, since all 
  processors have the same code.

  Other problems with trying to use a distributed memory parallel processor
  to support multiple users include developing a distributed operating
  system and assuring deterministic system operation.  These are not
  trivial problems.


		     Ian Kaplan
		     Loral Dataflow Group
		     Loral Instrumentation
	     USENET: {ucbvax,decvax,ihnp4}!sdcsvax!loral!ian
	     ARPA:   sdcc6!loral!ian@UCSD
	     USPS:   8401 Aero Dr. San Diego, CA 92123
Technical Details
Message-ID: <1379@loral.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!sdcc6!loral!ian
References: <76700001@uiucdcsp> <rocheste.24385> <1205@ogcvax.UUCP> <5699@amdahl.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!sdcc6!loral!ian
From: ian@loral.UUCP
Newsgroups: comp.arch
Subject: Re: shared memory multiproc. question
Message-ID: <1379@loral.UUCP>
Date: Fri, 20-Feb-87 18:26:54 EST
Article-I.D.: loral.1379
Posted: Fri Feb 20 18:26:54 1987
Date-Received: Sat, 21-Feb-87 19:58:06 EST
References: <76700001@uiucdcsp> <rocheste.24385> <1205@ogcvax.UUCP> <5699@amdahl.UUCP>
Reply-To: ian@loral.UUCP (Ian Kaplan)
Organization: Loral Instrumentation, San Diego
Lines: 53