From owner-hpff-distribute Thu Nov 2 07:53:38 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id HAA14920 for hpff-distribute-out; Thu, 2 Nov 1995 07:53:38 -0600 (CST) Received: from fontainebleau.ensmp.fr (root@fontainebleau.ensmp.fr [192.54.148.100]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id HAA14913 for ; Thu, 2 Nov 1995 07:53:28 -0600 (CST) Received: from cri.ensmp.fr (chailly.ensmp.fr) by fontainebleau.ensmp.fr with SMTP id AA12369 (5.67a8/IDA-1.5 for ); Thu, 2 Nov 1995 14:49:32 +0100 Received: from provins.caii by cri.ensmp.fr (4.1/SMI-4.0) id AA08640; Thu, 2 Nov 95 14:49:31 +0100 Date: Thu, 2 Nov 95 14:49:31 +0100 Message-Id: <9511021349.AA08640@cri.ensmp.fr> Received: by provins.caii (4.1/SMI-4.1) id AA00953; Thu, 2 Nov 95 14:49:27 +0100 From: Fabien COELHO To: hpff-distribute@cs.rice.edu Subject: hpff-distribute: local computations, NEW clause and so. Cc: coelho@chailly.ensmp.fr Sender: owner-hpff-distribute Precedence: bulk --------------------------------------------------------------------------- hpff-distribute@cs.rice.edu 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. --------------------------------------------------------------------------- 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 __ coelho@cri.ensmp.fr 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 hpff-distribute-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-distribute Fri Nov 3 12:02:26 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA04017 for hpff-distribute-out; Fri, 3 Nov 1995 12:02:26 -0600 (CST) Received: from [128.42.5.160] (pasyn-32.rice.edu [128.42.5.160]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id MAA04009; Fri, 3 Nov 1995 12:02:15 -0600 (CST) Date: Fri, 3 Nov 1995 12:02:15 -0600 (CST) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Fabien COELHO From: chk@cs.rice.edu (Chuck Koelbel) Subject: hpff-distribute: Re: local computations, NEW clause and so. Cc: hpff-distribute@cs.rice.edu, coelho@chailly.ensmp.fr, hpff-task Sender: owner-hpff-distribute Precedence: bulk --------------------------------------------------------------------------- hpff-distribute@cs.rice.edu 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=3D0,0 > C3 =3D 4/((1/V(NP,NP))+(1/V(NP,NP-1)) + > $ (1/V(NP-1,NP))+(1/V(NP-1,NP-1)) ) > W =3D C3*DELTAT > BS(NP-1,1) =3D 2*W/(4*W+3*H) > BS(NP-1,2) =3D 3*H/(4*W+3*H) > V(NP,NP-1) =3D 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 =3D 4/((1/V(NP,NP))+(1/V(NP,NP-1)) + > $ (1/V(NP-1,NP))+(1/V(NP-1,NP-1)) ) > W =3D C3*DELTAT > BS(NP-1,1) =3D 2*W/(4*W+3*H) > BS(NP-1,2) =3D 3*H/(4*W+3*H) > V(NP,NP-1) =3D 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 __ coelho@cri.ensmp.fr > CRI, ENSMP, 35, rue Saint Honor=C8, 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 hpff-distribute-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-distribute Mon Nov 13 15:00:19 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id PAA09060 for hpff-distribute-out; Mon, 13 Nov 1995 15:00:19 -0600 (CST) Received: from fontainebleau (root@fontainebleau.ensmp.fr [192.54.148.100]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id OAA08857; Mon, 13 Nov 1995 14:56:33 -0600 (CST) Received: from cri.ensmp.fr (chailly.ensmp.fr) by fontainebleau with SMTP id AA06397 (5.67a8/IDA-1.5); Mon, 13 Nov 1995 21:55:48 +0100 Received: from provins.caii by cri.ensmp.fr (4.1/SMI-4.0) id AA05259; Mon, 13 Nov 95 21:55:47 +0100 Date: Mon, 13 Nov 95 21:55:47 +0100 Message-Id: <9511132055.AA05259@cri.ensmp.fr> Received: by provins.caii (4.1/SMI-4.1) id AA17100; Mon, 13 Nov 95 21:54:57 +0100 From: Fabien COELHO To: chk@cs.rice.edu Cc: hpff-distribute@cs.rice.edu, hpff-task@cs.rice.edu, coelho@chailly.ensmp.fr In-Reply-To: (chk@cs.rice.edu) Subject: hpff-distribute: Re: local computations, NEW clause and so. Sender: owner-hpff-distribute Precedence: bulk --------------------------------------------------------------------------- hpff-distribute@cs.rice.edu 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. --------------------------------------------------------------------------- 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. > 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. 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. -- Fabien COELHO __ http://www.cri.ensmp.fr/~coelho __ coelho@cri.ensmp.fr 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 hpff-distribute-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------