Subject: hpff-task: HPF directives (reduce, on, new and so again)

From: Fabien COELHO <[email-masked]>
Date: Wed, 3 Jan 96 12:34:43 +0100

---------------------------------------------------------------------------
[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.
---------------------------------------------------------------------------

Dear Rob,

> 	By the way, many directives are orthogonal. I cannot remember from
> 	the "ON" proposal whether something like
> 	
> 	chpf$ independent, new(y), reduction(z(:)), on home(a(i))
> 	      do i=...
> 	
> 	would make sense.
>
> ON is now not viewed as a clause of the independent directive. It can apply
> to any code block including, but not exclusively a loop body.

Sure; I would like to suggest a scope directive (in the spirit of what is
suggested for the on directive, and as a general replacement for it) to
allow some time things like: 

chpf$ reduction(x=0.), new(z,z2) [, on ...]
chpf$ scope
      z = 1./epsilon
      z2 = .5*z
      A(1) = z*(B(2)-B(1))
      x = x + A(1)
chpf$ independent
      do i=2, n-1
         A(i) = z2*(B(i+1)-B(i-1))
         x = x + A(i)
      enddo
      A(n) = z*(B(n)-B(n-1))
      x = x + A(n)
chpf$ end scope
      ! now x is available as SUM(A). 
      ! (x = f(B(1),B(2),B(n-1),B(n)), 
         the computation does not make sense here:-)

the reduction involves the loop and the corners which are computed.
this causes not much problem as far as compilation is concerned, in my
opinion. The benefit is to avoid the global synchronizations at 
x = x + A(1) and x = x + A(n), and every thing is made after the 
"end scope" as it would have been for a reduction in a do loop.

Even if this is not yet allowed, I think that the scope provider and
the directives should be distinct for allowing this in the future if
it may be desired... at least for HPF-later...

My opinion is that it could also be considered for HPF{2,kernel}...

> 	Moreover all these directives should commute and be optionnal?
> Reduction is not optional if independent is used and the loop contains
> reductions....

I just mean on a syntactic point of view, that all directives should be:

HPF-directive-list is HPF-directive [, HPF-directive-list ]

HPF-directive is independent-directive
              or new-directive
              or reduction-directive
              or on-directive
              or ...

Constraint 1: After an HPF-directive-list is a scope provider [or maybe
              another HPF-directive-list], that is:
              - a do loop
              - a forall loop
              - a "scope-directive"

Constraints 2: are disallowed:
              - independent for "scope"
              - new and reduction for "forall" (okay, okay:-)
              (that's all?!)

We could also think of "independent(i)" in a scope, making all loops as
parallel in this scope, relaxing one of constraints...

chpf$ independent(i), reduction(x), new(z), on ...
chpf$ scope ! all needed directives are declared before the code...
      ...
      do i = ... ! independent!
      ...
      do i = ... ! independent!
      ...
      do j = ... ! not necessarily ...!
      ...
chpf$ end scope
      ...
      do i = ... ! not necessarily independent!

I'll finalize this some day. The issues to be discussed:

 - sofware engineering (quality improved, I think)
 - ease of use (sure!)
 - economy (sure!)
 - clarity (I think so!)
 - compilability (I think so, quite easily!)
 - teachability (improved because it is in a general framework, it is
                 homegeneous, ...)

Well, part is syntactic sugar, but not all of it... 
Have a nice day, regards,

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>
---------------------------------------------------------------------------