[comp.parallel] Language support for vector

eugene@eos.arc.nasa.gov (Eugene Miya) (05/16/89)

>Question for the experienced vector folks (Eugene Maya perhaps?):

A slight typo.  I will ignore ;).  I am just one blindman trying to figure
out what an elephant looks like.  I don't have much experience, but...

>To those who have some experience in explicit vector support in languages:
>does this support make it easier or more difficult for the average programmer?

Er, yes, ... and no...
I don't think there is a single straight-forward answer.

>In other words, would you prefer to see the compiler create the vector 
>instructions without explicit programmer help (if it could do it well) or are 
>vector instructions a win for the programmer?

I think most end users with dusty deck programs, dusty deck JCL, and
dusty deck brains would prefer the drop-in, no-help compiler.  The
comment about brains should not be taken negatively, they have a job to do.
That requires a considerable level of commitment.  Do you want them to throw
out 20 years of work (in some cases more)?  This is a real problem,
you are implicitly asking for a total rewrite of the last N-years of science
in some cases for your latter case.  "Oh, the elephant is a creature
like a wall, its big, and flat, and..."  Realize that this has been
attempted several times before.  See next case.

You see there is "THE problem" and there is its expression (implementation)
in some language.  A few people CAN make use of new languages with vector
or parallel constructs.  This was tried consider APL (possibly the oldest
of the implemented vector languages).  Then there were numerous
Parallel Pascals, more obscure languages like Glypnir, CFD, and others.
Then languages with small scale explicit MIMD constructs like ALGOL 68,
Ada, etc.  And now with the new generation of Unix boxes we see
Concurrent C and vector Cs emerging.  You want me to rewrite everything
in one of these languages?  You are crazy!?  Oh, I forgot all the parallel
LISPs.  "Ah, the elephant is like a snake! It's narrow and twists and turns!"

The expression of parallelism is a good thing, much of the world is
"parallel [boy I hate that word, I wish there was a better, clearer word],"
but the way we describe it is not well understood.  Lots isn't parallel.
Vector C = vector A * vector B is one thing, too simple.  See this is
the YES part of the answer.  Fortran 8x has this.
Anyone can think of this.  More is needed.  What isn't understood
is how to write a syntax which minimizes dependences.  How do you handle
boundaries of structures?  Edges?  How do you handle exceptions?
I don't know how to do this. SISAL was supposed to handle this, but the
group is folding.

Are we trying to hide the hardware, or find justification for feature
existence?
So are we going to reinvent some new APL which will never get used,
die in some academic journal to the praises of the CS-types and howls
of end-users?  Dammed is you do, and dammed if you don't.

>University of Southern California

USC? Well, I don't hold that against you 8).

Longish signature follows "Type 'n' now"

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.

rro@bizet.CS.ColoState.Edu (Rod Oldehoeft) (05/17/89)

In article <5493@hubcap.clemson.edu> eugene@eos.arc.nasa.gov (Eugene Miya) writes:
>
>I don't know how to do this. SISAL was supposed to handle this, but the
>group is folding.
>

Wrong, Eugene.  The SISAL project is alive and well, with very encouraging
recent results.  Stay tuned, I'll send you something when I can.


Rod Oldehoeft, Chairman          rro@handel.CS.ColoState.EDU
Computer Science Department      303/491-5792
Colorado State University
Fort Collins, CO  80523

northrup@wpi.wpi.edu (Jim Northrup) (05/17/89)

My experience has been that whenever you want to vectorize (or just parallel-
ize) existing serial code, you're going to have to go through the program
anyway looking for dependencies.  By making myself convert existing loops
into vector (or parallel) constructs explicitely, I catch dependencies that
I might have otherwise overlooked.  So, if you really do want fast code, I'm
an advocate of doing it by hand.  The bottom line, I think, is that it's a
trade off between how fast you want the program to go, and how much time
you're willing to spend on it.

It's kind of like the trick of proof-reading a document backwards, so that
your eye won't skip over errors.

-- 
Jim Northrup                                               northrup@wpi.wpi.edu
Assistant Professor, Department of Mathematical Sciences
Worcester Polytechnic Institute, Worcester MA  01609
I wish I could hear the soundtrack to my life.  Then I would know when to duck.