[comp.parallel] Language support for vector instructions

gshippen%pollux.usc.edu@usc.edu (Gregory Shippen) (05/16/89)

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

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?

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?

Gregory B. Shippen
gshippen@pollux.usc.edu
University of Southern California
*****************************************************************************

dbailey@orville.nas.nasa.gov (Dave H. Bailey) (05/17/89)

In my view, there is a need both for automatic compiler-detected
generation of vector operations and for explicit programmer-directed
vector operations.

Let's face it, in the short term many new users of vector computers
will be unfamiliar with vectorization and furthermore will be faced
with the task of converting multi-thousand line 'dusty deck' codes to
run efficiently on a vector system.  For such users, 'automatic
vectorization' of normal sequential source code is very desirable.
Further, automatic vectorization, enhanced perhaps by
programmer-inserted 'compiler directives' (i.e. special comments)
allows a code to remain in ANSI-standard form, which guarantees that
it will run correctly if ported to another system.

On the other hand, it must be acknowledged that 'automatic
vectorization' is only a partial solution.  For one thing, I have
found that 'automatic vectorization' is somewhat of a misnomer --
'semiautomatic vectorization' would be a more appropriate name.  This
is because even the very best of these tools, such as the Pacific
Sierra VAST-2, can only detect safe vectorization part of the time.
In some of my FFT codes, for example, the majority of the vectorizable
inner loops are not detected as such by any automatic vectorizer, and
I have grown weary of trying to second guess whether or not I need to
insert a directive to force vectorization.

In other words, as an experienced user of vector computers, I would
prefer being able to write my original code with explicit vector
notation.  I find it ludicrous that I must translate the orignal
computational concept, which is inherently parallel, into a sequential
form, only to subsequently be analyzed by a very sophisticated
software tool, which tries to reconstruct the original parallel
concept, with only partial success.

Along this line, we here at NASA Ames are hoping that the ANSI
committee will finally make up its mind on the final version Fortran
8X.  The array constructs of Fortran 8X are exactly what Fortran users
need to conveniently and explicitly declare their array operations.
By the way, the array constructs in 8X probably have the widest
support of any of the new features in the proposed standard.  Even if
the current standard is drastically revised, with most new features
removed, it is likely that the array constructs will remain.  Here is
an example of a Fortran-77 code segment and its translatiion using the
8X array constructs:

Fortran 77 version:

      DIMENSION A(100,100), B(50,50), C(50,50)
.....
      DO 100 J = 1, 50
        DO 100 I = 1, 50
          T = B(I,J) - 1.
          A(I,J+50) = T**2 + C(I,J)
100   CONTINUE
.....
Fortran 8X version:

      A(1:50,51:100) = (B - 1) ** 2 + C

David H. Bailey
NASA Ames Research Center