Subject: hpff-distribute: Re: local computations, NEW clause and so.

From: [email-masked] (Chuck Koelbel)
Date: Fri, 3 Nov 1995 12:02:15 -0600 (CST)

---------------------------------------------------------------------------
[email-masked] is a mailing list for discussion of data
distribution in High Performance Fortran.  Instructions for adding or
deleting yourself from this list appear at the bottom of this message.
---------------------------------------------------------------------------

Hello, Fabien -

My first impression is that this should be subsumed by the ON clause.  This
directly tells the compiler which processor(s) should execute a section of
code.  It can be used for any section of code, not just the body of a loop.
(See the archives of messages to the hpff-task group, and hopefully more
messages in the next few weeks for details.)

The ON clause may need to add a NEW option (it's not there now).  I will
think about it more, and add the option unless there's a serious conflict.

                                                Chuck Koelbel

At 14:49 11/02/95, Fabien COELHO wrote:
>
>Hi out there !
>
>  A little problem solved by
>  a little hack that could be
>  a little directive:-)
>
>The independent and new directives state that a loop is parallel, possibly
>based on the private status of some scalar variables. With an "owner
>computes rule"-based implementation in a compiler, it also allows to
>express indirectly that only a subset of the processors are involved in a
>computation.
>
>I have a nice data-parallel code that performs some 2D seismic
>wave-propagation in an heterogeneous field. Different formulae are applied
>for the inner region, for the borders... and up to the corners, which have
>their own formulae.
>
>For a given corner, I would like the compiler to figure out simply that a
>set of assignments should only be computed on the processor that deals
>with that corner, and that's all. For sure, the same scalar variables are
>used at each corner, while these corners may be handled by different
>processors. In order to express that these variables are local to a
>processor and thus to avoid unnecessary synchronization and communications
>at run-time, I used the following hack:
>
>chpf$ independent(i), new(C3,W)
>      do i=0,0
>         C3          = 4/((1/V(NP,NP))+(1/V(NP,NP-1)) +
>     $        (1/V(NP-1,NP))+(1/V(NP-1,NP-1)) )
>         W           = C3*DELTAT
>         BS(NP-1,1) = 2*W/(4*W+3*H)
>         BS(NP-1,2) = 3*H/(4*W+3*H)
>         V(NP,NP-1)  = C3
>      enddo
>
>The stupid 1 element loop allows to use the new directive, and the
>do/enddo construction provides a scope for the private scalar variables.
>
>Now I think that allowing something like
>
>chpf$ local, new(C3,W)
>         C3          = 4/((1/V(NP,NP))+(1/V(NP,NP-1)) +
>     $        (1/V(NP-1,NP))+(1/V(NP-1,NP-1)) )
>         W           = C3*DELTAT
>         BS(NP-1,1) = 2*W/(4*W+3*H)
>         BS(NP-1,2) = 3*H/(4*W+3*H)
>         V(NP,NP-1)  = C3
>chpf$ endlocal
>
>although not essential to the language, would give a pretty-looking piece
>of code, compared to the previous one that looks just stupid.
>
>On the language point of view, it just means that variables with
>a local scope are welcome. The new directive states that the variables
>have a local scope/visibility/liveness, and the local/endlocal provides
>the needed scope, which cannot be expressed in Fortran 77. The C block {}
>with local variables are mimicked this way. With this information, the
>compiler finds quite easily that the other variables referenced are
>distributed, and that the references are aligned one to the other. The
>generated code selects the right processor and simply performs the
>required computations on local data.
>
>That's all for
>   the little problem,
>   the little hack and
>   the little directive:-)
>
>Fabien.
>
>Fabien COELHO __ http://www.cri.ensmp.fr/~coelho __ [email-masked]
>  CRI, ENSMP, 35, rue Saint HonorÈ, 77305 Fontainebleau Cedex, France
>     phone: 33 1 64 69 {voice: 48 52, fax: 47 09, standard: 47 08}
>       ________  All opinions expressed here are mine  ________

---------------------------------------------------------------------------
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: Mon, 13 Nov 95 21:55:47 +0100

Hi Chuck,

> My first impression is that this should be subsumed by the ON clause. 

Why not, The fewer keywords and concepts and so, the better the language.

> This directly tells the compiler which processor(s) should execute a
> section of code. 
> It can be used for any section of code, not just the body of a loop.

Great. My (small) problem was too attach the NEW sub-directive to
something that can provide a scope, but this scope provider does not need
to be private to the "NEW" sub-directive/clause or whatever.

I had a (quick) look at your August 18 proposal.

Seems okay to me but to one point: do I wish to specify the processor on
which some variables may be private? I guess not in *all* cases. 
At least not for the particular seismic code I have. 

All I mean is that the concepts seem independent one from the other.
Thus it would be okay if you could allow not to specify a HOME if not
needed or desired, while allowing the HOME and NEW directive to share
the BLOCK/END BLOCK scope if that does make sense. Also it seems to me
that a NEW clause without the BLOCK/END BLOCK, that is attached to
simple-on-directive, is not very interesting. 

On the compiler point of view, it just mean that you can attach various
informations to code sequences. BTW, I guess no arbitrary control flow
would be allowed in a BLOCK/END BLOCK... just for the compiler:-)

Something like 

  [ON HOME(...) [, LOCAL(...)]] [,? NEW(...)] [BLOCK/... END BLOCK].

That is putting the HOME stuff as optional. Allowing 

  ON HOME(...), NEW(...) BLOCK
  NEW(...) BLOCK
  ON HOME(...) BLOCK
or even the other order around:
  NEW(...), ON HOME(...), LOCAL(...) BLOCK

may be in such a case the [,] between the LOCAL and its corresponding
HOME could be avoided/not mandatory, or changed to a keyword to relate it
more closely to its corresponding HOME specification? 

  Also something like 

chpf$ BLOCK, ON HOME (...) WITH LOCAL(...), NEW(...), [any other dir]
      ...
chpf$ END BLOCK

would make sense if the idea of the BLOCK/END BLOCK is just to support 
a scope for directives such as HOME/NEW/and potentially others? 

Moreover on a personnal point of view I don't feel at ease with a BLOCK
put at the end of the line, because it is not easy for the eye to catch
the BLOCK/END BLOCK structure in one glance, since they are not aligned
(in the column of the text). It is also unusual? I guess there is some
rationale behind.

  Just for fun, one could imagine such a scope "spliter" for parallel
tasks, based on BLOCK/END BLOCK. I do not know what is being discussed
in HPF 2 about the task syntax, but I guess it looks like that in some
way. The point is just to share/split/materialize a scope and parallel
tasks with the same syntax. It would also allow to specify a HOME and
other informations for each task with the same syntax... 

chpf$ BLOCK, ON HOME(...) WITH LOCAL(...)
      task 1 sequence of statements
chpf$ PARALLEL [or any other keyword, like PARALLEL TASK or TASK...].
chpf$x  ON HOME(...), NEW(...)
      task 2...
chpf$ PARALLEL, ON HOME(...) WITH LOCAL(...), NEW(...)
      task 3...
chpf$ END BLOCK

  Finally I'm not sure to like the "BLOCK" name much, because I already
have a BLOCK in the distribute directives:-). My simple tr/sed HPF parser
won't like that:-) I would vote for BEGIN if I had to.

> think about it more, and add the option unless there's a serious conflict.

Well, you don't have to take into account all the remarks I made here:-)
I guess the last idea is that from the language point of view the
BLOCK/END BLOCK stuff does not need to be attached to the ON HOME
directive, but could have a life of its own, supporting other directives
with kind of a scope.

Have a nice day,

Fabien.

--
  CRI, ENSMP, 35, rue Saint Honoré, 77305 Fontainebleau Cedex, France