From owner-hpff-task Fri Nov 3 12:04:09 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA04084 for hpff-task-out; Fri, 3 Nov 1995 12:04:09 -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-task: Re: local computations, NEW clause and so. Cc: hpff-distribute@cs.rice.edu, coelho@chailly.ensmp.fr, hpff-task Sender: owner-hpff-task Precedence: bulk --------------------------------------------------------------------------- hpff-task@cs.rice.edu 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. --------------------------------------------------------------------------- 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-task-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-task Mon Nov 13 14:57:10 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id OAA08892 for hpff-task-out; Mon, 13 Nov 1995 14:57:10 -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-task: Re: local computations, NEW clause and so. Sender: owner-hpff-task Precedence: bulk --------------------------------------------------------------------------- hpff-task@cs.rice.edu 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. --------------------------------------------------------------------------- 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-task-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------