Article View: comp.arch
Article #13035Re: shared memory multiproc. question
From: ian
Date: Fri, 20 Feb 1987 23:26
Date: Fri, 20 Feb 1987 23:26
53 lines
3495 bytes
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!ianReferences:
<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