Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!emory!hubcap!Vaughan
From: pratt@cs.stanford.edu (Vaughan Pratt)
Newsgroups: comp.parallel
Subject: Re: parallel programming model
Message-ID: <12318@hubcap.clemson.edu>
Date: 17 Dec 90 21:21:37 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 45
Approved: parallel@hubcap.clemson.edu


	From: Vaughan Pratt <pratt@cs.stanford.edu>
	However it would not impact the main purpose of networking,
	which is not performance but rather simply to spare people the
	inconvenience, cost, and unreliability of moving data around on
	magnetic tapes

Hmm, that isn't quite right.  Let me add interactive computing (but
that's a fine example of an application for which convenience, economy,
and reliability are higher priority for many people than performance),
and also replace "main" by "original."  Hope that nips a few if not all
flames in the bud.

Note that I'm not saying people don't want performance, they do (I
do).  For example links with higher throughput facilitate interactive
graphics, and the ever-increasing number and size of objects being
shipped around means performance has to at least keep pace.  But people
badly want those other three attributes (convenience, economy,
reliability) too, and you can't measure the quality of distributed and
concurrent computing solely or even primarily on the basis of its
performance.

If you insist on concentrating on performance issues for concurrency,
there is still room for good and bad perspectives.  Don't think of the
main performance gain of n-fold concurrency as being solving one
problem up to n times faster.  Think of it instead as being for solving
n problems in the time of one.  If you're lucky you may be able to
solve n/k problems up to k times faster for k larger than 1, but you
stretch your luck as you let k approach n.  The situation at k = n is
approximately that of low-level coding, as in assembly language and
microcode: the investment is so high that only a very few returns on
the investment can justify it, e.g. calculations for particle physics
or cryptography.  Such expensive high-k applications are far from being
the only application of concurrent computing, in fact I venture to say
they constitute only a small and unrepresentative fraction of the
concurrency milieu.

The twin offspring of sequential computing are Together and Faster.
Together is the more sociable twin, a good organizer, likely to become
a company president one day.  Faster is a loner, always out on his bike
trying to beat his personal best.  Faster may make a big splash one day
in the Indy 500, but his impact on the world economy will never match
that of Together.

	Vaughan Pratt