Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!kddlab!icot32.icot.or.jp!hawley
From: kddlab!icot32.icot.or.jp!hawley@uunet.UU.NET (David John Hawley)
Newsgroups: comp.parallel
Subject: Re: parallel programming model
Message-ID: <12326@hubcap.clemson.edu>
Date: 18 Dec 90 13:52:45 GMT
Sender: fpst@hubcap.clemson.edu
Organization: Fifth Generation Computing Systems (ICOT), Tokyo, Japan
Lines: 29
Approved: parallel@hubcap.clemson.edu

In article <12318@hubcap.clemson.edu> pratt@cs.stanford.edu (Vaughan Pratt) writes:
* 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.

I don't understand what the difference is between solving n Problems
concurrently in time 1, and solving n SubProblems concurrently in time 1.
Unless we are talking about timesharing, on some black box which happens
to be a distributed computer? If so, I don't see the relevance to performance.

There may be another side to "faster". If you can take a general, but
slow algorithm, and get it to go "faster", to the point of being
practically useable, then you can recover your development cost by not
worrying so much about developing special-case algorithms. Although
generality usually implies bigger O(_) complexity, to some extent
concurrency can make it worthwhile.

David Hawley