Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mandrill!gatech!hubcap!Robert
From: colwell@mfci (Robert Colwell)
Newsgroups: comp.parallel
Subject: Re: parallel numerical algorithms
Message-ID: <1763@hubcap.UUCP>
Date: 27 May 88 15:42:46 GMT
Sender: fpst@hubcap.UUCP
Lines: 47
Approved: parallel@hubcap.clemson.edu


In article <29851@yale-celray.yale.UUCP> lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) writes:
=In article <1684@hubcap.UUCP= eugene@pioneer.arc.nasa.gov (Eugene N. Miya)
=writes:
==for comp.parallel:
===Although I am mostly interested in true parallelism, I wouldn't mind
===receiving algorithms based on vectorization, and such like.
==
==The English language is marvelously vague.  I wish I knew what 'true'
==parallelism is or was.
=....
==If we are going to make a distinction between vector and parallel, it had
==better have better basis for making that distinction.
=
=In my world it is very simple. parallelism is when you do several things at
=once, at different places. Vector operations are usually executed in a
=pipeline. When the pipeline is filled every stage in it will execute in
=parallel. Thus vector operations provide a special form of parallelism.
=
=Bjorn Lisper

I think what Eugene's pointing out is that we don't really know what
the coin of the realm is here.  If your hammer says "vector machine"
on it, then you'll quantize your parallelism in units of "percent
vectorization".  But the code or application doesn't know you're
doing that, and it may possess fine-grain parallelism far beyond the
stretches that a vector machine can take advantage of.

"Vector ops" are too high a level of abstraction to be of use in
distinguishing between vectorization and parallelism.  I think we
have to break down the vector ops into their constituent parts.
Fine-grain parallelism is the principal diet of VLIWs, and we (well,
I) define it to be one of a small set of things:  memory load or
store, register-to-register integer or floating operation, and I/O.
When you've broken down your program into ops at that level, you can
then schedule them for execution in an optimal way.  Operations that
are (at that time) unconstrained save for data dependencies exhibit
what I think of as useful parallelism.

Of course, as soon as we have a decent enough definition, somebody
will try to apply it to a systolic or connection machine
and we'll have to start over. ;-)

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090