Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!umnd-cs!umn-cs!herndon
From: herndon@umn-cs.UUCP
Newsgroups: comp.arch
Subject: Re: chewing up mips with graphics [parallel computing]
Message-ID: <1716@umn-cs.UUCP>
Date: Tue, 7-Jul-87 19:42:31 EDT
Article-I.D.: umn-cs.1716
Posted: Tue Jul  7 19:42:31 1987
Date-Received: Fri, 10-Jul-87 04:11:52 EDT
References: <8270@amdahl.amdahl.com> <359@rocky2.UUCP> <338@astroatc.UUCP> <350@astroatc.UUCP>
Organization: University of Minnesota, Minneapolis
Lines: 70
Keywords: parrallel computing; performance; vector computing
Summary: You missed the point!

In article <350@astroatc.UUCP>, johnw@astroatc.UUCP (John F. Wardale) writes:
> In article <1683@umn-cs.UUCP> herndon@umn-cs.UUCP (Robert Herndon) writes:
> >  Parallelize that, no.  Parallelize the same problem, which presumably
> >is "tell me how projectile X under conditions Y will fall", is
> >entirely a different question, and may be parallelizable,
> >depending on the differential equation involved.  Just as
> 		...example of... [deleted for brevity]
>  Your garden variety scanner is serial, but
> a fancy-new algorithm called "a Mealy Machine" is much better.
Point #1.

> >  If you mean "ALL" problems, then I'd have to agree with you.
> >There certainly are problems that seem to require a serial
> >solution strategy.  BUT:  you must differentiate between
> >"a problem" and "code to solve a problem".  They are NOT identical,
> >and an algorithm change makes it a whole new ball game.
> 
> New methods are great for new codes, but given the amount of code
> in the world, and the number of new machines comming out, how much 
> effort do you REALLY think goes into each conversion ???
Point #2.

> ...
> I think you intentionally chose the "scanner" example so you could
> claim that its in the code distributed with the system, and will
> therefore be in all the vendor-supplied (system) programs, but
> scanning constitues a very *SMALL* fraction of the total CPU time,
> so these sort of algorithmic improvements must be applied in a
> wholesale manner to all the sub-parts of each program.  That will
> (99.9% likely) be VERY expensive!!
Point #3.
  Point #1.  "The Mealy Machine" is a standard creature from
automata theory.  It has nothing to do with parallelism. I simply
described an algorithm outlined in Hillis's and Steele's article
in the Dec. '86 CACM that can be used to simulate a Mealy machine
in parallel.
  Point #2.  Conversion efforts vary with the amount of work
required to convert something, and the benefits to be accrued
to the conversion.  Many heavy duty numerical simulations (e.g.,
airflow simulations, weather modeling, seismic analysis, ...)
require large amounts (e.g., weeks) of time on Cray class computers,
and are still economies.  If the time could be cut down even
one or two orders of magnitude by recoding these for parallel
hardware, using entirely different algorithms, many firms would
find it profitable to do so.  Most programs do not require these
kinds of efforts.  So be it.  Future programs, written by future
programmers familiar with parallel algorithms and hardware are
likely to write programs that use parallelism.  Just because there
is a cost to parallelism, and the cost is high, doesn't mean
that there are no algorithms that will benefit from it now.
  There will be a learning curve, like the learning curve for
high level languages.  Twenty years ago, the cost of compilers
was very high, and many shops refused to use them, coding
everything in assembler.  The transition to HLLs has been less
than painless, and less than economical for the average shop
in the beginning, but I don't see too many people arguing that
HLLs are a mistake.
  Point #3.  I chose the example because I knew it, it is of
concern to me (being a languages & OS person), and it is something
that is always presented alongside serial algorithms.  Scanners and
such can be automatically generated, and many programs use them.
So they do drain only a small amount of CPU time in most systems.
Any one algorithm you care to choose does.  The power of the
algorithm scheme (no pun intended) outlined is that it can be applied
to many tasks to yield performance gains.
-- 
Robert Herndon				Dept. of Computer Science,
...!ihnp4!umn-cs!herndon		Univ. of Minnesota,
herndon@umn-cs.ARPA			136 Lind Hall, 207 Church St. SE
herndon.umn-cs@csnet-relay.ARPA		Minneapolis, MN  55455