Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!Eugene
From: eugene@eos.arc.nasa.gov (Eugene Miya)
Newsgroups: comp.parallel
Subject: Re: parallelism terminology
Message-ID: <7932@hubcap.clemson.edu>
Date: 9 Feb 90 13:13:40 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 49
Approved: parallel@hubcap.clemson.edu

I enjoyed reading Guido's commenst below and I openly respond.
Yes I know exactly what you are saying.

>In my original posting I only mentioned different kinds of *parallelism*
>because I consciously wanted to separate "characteristics" of programs/
>algorithms from their implementation or the architectures they run on.
>That's why I don't want to deal with such issues as loosely-coupled,
>fault-tolerant, etc.  That's a whole other ballgame...

Parallelism is a very large elephant and all the researchers around it
are Indian Blindmen (to use the analogy).  They dealt with characteristics.

So attempt most researchers, and that is where many of them fail.
Permit me to draw an analogy: warm fusion.  Physicists are only
able to achieve fusion for very short periods of time with lots
and lots of preparation and concern for problems (overheads, costs).
They have the concept of "breakeven."  Parallel processing has a
somewhat similar problem.  We get parallelism for very short periods
of time with high overheads.  At best we can get super-unitary, but linear
speed ups.

The most successful parallel architectures have paid attention to serious
designs of some type of "graceful degradation."  Parallel machines
aren't by default more reliable because of replication.  It has to be designed
in from the beginning.  It doesn't just come naturally.  This attention
to detail is critical in making systems.  Unfortunately, a few people
have adopted these buzzwords without much thought and a lot of assumption.

Increasingly we will have to see parallel computers used like telescopes
and particle accelerators as tools for research about computation.

>I think it's important to separate program or algorithm "characteristics"
>(i.e. kinds of parallelism present) from the way in which such programs
>are actually run (e.g. processor-farm model, divide-and-conquer, static
>pipeline, etc.).

Yes, your key word is "virtual."  It's that separation of concept from
detail.  But I would like to eventually see the hardware you run on.
Programs are written for architectures.  Architectures are rarely built
for programs (a few like GF-11).

I was told a joke by George Adams [Hi George] which I passed on to Steve
(your moderator):  In short: An EE and CS are stranded on a desert island.
They decide that to design a boat, a computer would be useful.  The EE says,
"Desert island, lots of sand around? I will build a computer."  The CS says,
"Posit a machine......"

Not a flame, just a comment.
--eugene miya