Subject: hpff-task: Re: not attached "new" directive

From: [email-masked] (Chuck Koelbel)
Date: Wed, 3 Jan 1996 11:10:38 -0600 (CST)

---------------------------------------------------------------------------
[email-masked] is a mailing list for discussion of control-parallel
features in HPF.  Instructions for adding or deleting yourself from this
list appear at the bottom of this message.
---------------------------------------------------------------------------

At 11:26 01/03/96, Fabien COELHO wrote:
>>
>> The intent of FORALL was to provide a different syntax and more general
>> shapes for array assignments.  This makes it orthogonal to reduction
>> operators like the one in your first example.
>
>My understanding of "orthogonal" is that two concepts may apply on
>something with no special constraint or interaction. This is just my
>point! the "reduction", "new" and possibly "on" concepts apply to parallel
>loops, whether "independent" or not. I think they also apply on sections
>of code, as I argued for the corner computations of my basic seismic
>application in a previous mail. I'll argue on that in another mail,
>some day.

What I meant was "FORALL and reductions solve different problems".  While I
agree that two constructs that solve the same problem should have the same
restrictions, I do not agree that constructs doing different things must
have the same behavior.

You are arguing that FORALL should be (a? the?) general parallel construct.
I am arguing that the INDEPENDENT DO is a better candidate for this.  In
particular, making FORALL fully general would require major changes - for
starters, we would have to define the semantics of CALL and WRITE inside of
FORALL.  (We tried this in HPFF 1 meetings for CALL, and could not reach
concensus.)  INDEPENDENT requires fewer changes, essentially relaxing
constraints rather than defining new behavior.

If you want to pursue generalizing FORALL, my suggestion is to write up a
full proposal.  (Feel free to start with the text in the HPF language spec
if you want.)  That will at least ensure that we're talking about the same
thing.

>I'm not promoting the FORALL. It is neither Fortran 77 nor Fortran 90, so
>any code that do use a forall cannot be compiled and is not portable apart
>on HPF compilers. I hope F95 (F96?) will have the same one? Well...

Fortran 95 will include FORALL, defined as in HPF 1.0.

>There are 2 "parallel" loops in HPF. The FORALL may or may not be
>"independent", it is nevertheless parallel, with a SIMD execution
>order. HPF allows "independent" to characterize these loops, but not "new"
>(constraint line 10, page 81 of HPF 1.0). I cannot see why, apart the
>history of the proposal, where forall is an extension of the array
>assignment syntax. I'm arguing that *if possible*, "new" and "reduction"
>and "on" or whatever directive should apply on foralls as well as on do
>loops.

The problem is that NEW and REDUCTION and ON are directives.  They are not
first-class statements of the language.  Therefore, they cannot change the
meaning of the program by themselves.  They can change the efficiency of
the implementation (that's their job).  You make this point later in your
letter.

FORALL is a first-class statement, because its meaning is different from DO
(or any other construct.  Therefore, NEW cannot apply to FORALL, since the
FORALL would be incorrect without the NEW directive.

INDEPENDENT is an assertion of fact about the program.  The program will
produce the same answer whether INDEPENDENT is used or not, although how
quickly it produces the answer may be very different.  NEW modifies this
assertion (in particular, it says certain variables "don't count" in
determining dependences).

As a programmer, you need to understand what a program means.  If you can
explain what FORALL with a non-NEW scalar assignment means (and get the
rest of the world to agree with you), then we have a basis for adding NEW
to FORALL.  For example, what does this print *without NEW*?
        FORALL ( i = 1:n )
          x = a(i)
        END FORALL
        print x

>Conclusion: I think I must give up on "new" and "reduction" directives on
>foralls, but the language loses expressivity and orthogonality. If the
>forall is not to be considered by some sequential fortran, it should be
>allowed in HPF.
>
>I guess it is worth the discussion, at least...
>
>Fabien.

I don't necessarily agree that the language loses much expressivity.
However, I wish I could think of a way to make the difference between
FORALL and INDEPENDENT clearer.  HPF students (tutorials, etc.) always seem
to have trouble with this point, as do HPF implementors.

                                                Chuck

---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------

---

From: Fabien COELHO <[email-masked]>
Date: Wed, 3 Jan 96 19:30:14 +0100

Dear Chuck,

> You are arguing that FORALL should be (a? the?) general parallel

Not exactely. There is a bit of misunderstanding with the goal of my
previous mail and the opinion which is actually mine. I guess my poor
English and quite passionate arguments are no stranger to this...
Sorry about it.

> I am arguing that the INDEPENDENT DO is a better candidate for this. 
> [...]

Although this may not be clear from my mail, I definitely agree with you
on that point, and on the discussion that followed in your mail. 

I'm arguing more about the perception that people have/may have/should
have of the HPF language constructs, and their relations and
interactions. 

I don't parse FORALL with my prototype compiler, and I'm not planning to
add it, because I feel it as a particular case compared to the general
INDEPENDENT (do) loop. Also I want my test programs to be compiled by a
F77 compiler, for checking that my compilation is correct.

On the other hand the HPF compilers I had a look at did not parse/consider
the INDEPENDENT directive but only rely on the forall and array sections
for parallelism (I think this is not case with the new versions now).

If you look at examples in papers about HPF compilation, you may notice
that most of the time the examples are based on the FORALL syntax even if
the loop is INDEPENDENT, and the INDEPENDENT directive is not specified.

These facts show that the FORALL is perceived as an essential part
of the HPF language by some people (but *not* me).

If (other) people feel that FORALL is important, I was trying to argue
about giving them the same "services" that they can have with the
sympathetic INDEPENDENT do loops, namely "new" and "reduction", if
possible. 

The conclusion was that it is not possible, although I think (but you
don't necessarily think, fine) it would have been desirable (for
orthogonality) and that in some cases it it would have facilitate
expressivety (by not requiring from the programmer to manage explicitely
temporary arrays in their code while it could have been avoided with the
forall with extension, the compiler managing the temporary by itself).

> If you can
> to FORALL. 

I can't:-) And I don't want to!

> For example, what does this print *without NEW*? [...]

>         print x

I think that the intent is that without new it should be "semantical"
error. As if you mofify a constant passed as an argument to a function for
instance. 

However, if I simply extend the "Scalarization of forall statement" 
(Section 4.1.4 page 63 to 65) very precisely defined in the HPF
specification to this case I could answer "if n<1 then initial x else
a(n)":-). This is definitely deterministic and useless:-) 

for 

FORALL(i=1:n)
  x = a(i)
  b(i) = x
END FORALL

it would mean "b(1:n)=a(n)". A little bit disappointing for the user:-)

However you may have noticed in my previous mail that I gave up on my
initial claim because of this very problem: whatever the meaning without a
"new" clause, it cannot be the same in parallel and in sequential...

> I don't necessarily agree that the language loses much expressivity.

Well, what meant is just about the "expressivity" point is that it
requires the user to use an explicite temporary array to do the 
equivalent with independent loop. This is not big an issue, and doesn't
change the fact that it is not possible to have simply the new directive
for the forall.

> to have trouble with this point, as do HPF implementors.

Suggestion (50% joke): don't tell them about the FORALL!

For people that never used a SIMD machine, the SIMD execution order of the
forall is not intuitive, although they have no problem with array
sections...

Regards,

Fabien.