Subject: hpff-task: Re: HPF reduce directive

From: Fabien COELHO <[email-masked]>
Date: Tue, 2 Jan 96 20:22:00 +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,

> I know this is a subtle issue.   I thought we had unabiguously defined the
> answer to the "shich loop" question as the outermost DO loop that:
> 
> i)  Is independent
> ii)  Does not have a NEW clause for the reduction variable, and
> iii)  Does not *contain* in its range an independent DO loop with a NEW
>       clause for the reduction variable.
> 
> Also, the reduction statement must be in the lexical range of the DO loop.

Ok. These conditions do make sense and allow the compiler to find the
"right" outer loop by going up the syntax tree. Note that there is no
contradiction with my point: 

>> My point is that the way the "reduce" directive is placed in the loop nest
>> does not give this information to the compiler, thus some analysis will be
>> needed. This analysis could be avoided with some other syntax in the "new"
>> and "independent" spirit.

I haven't claimed that such a condition would not exist or would be that
difficult to check. My point is just that this search for the "right" loop
nest is *not* needed at all if the reduction is expressed at the loop level. 
Thus the compiler is directly at the right point and knows where to insert
the parallel reduction code for a given scalar, instead of having first to
look for the loop level. You can switch from some analysis to none.

> Thus, we have addressed the issues of whether more than one reduction
> statment may occur (there is no restriction on the number or the place)
> and which loops are the scope of the reduction. 

Great!

> Nevertheless, your points about economy of expression are very well
> taken. We should discuss this alternative.

As a matter of taste, I like vey much the "homegeneity" (with new, but not
independent...) argument. A simple syntactic issue for a language is that
things from one point of the language are the same at another point of the
language, if possible, so that the end-user won't have to learn different
"look and feel" syntax within the same language. This is not a simple
issue to look at for a language being discussed by a forum, where
aesthetics is not the primary goal. However it is an issue when you have
to teach/learn the language. With this in mind, I think that 

chpf$ independent(x), new(y), reduce(z)...
                 ^^^
could be allowed in HPF because it is simpler to teach and remember, every
body needs a list of or argument between parenthesis. On the other hand,
to be consistent with the "old" Fortran look and feel, one might have
prefered

chpf$ independent x
chpf$ new y
chpf$ reduce z

because it looks like declarations:

      real a
chpf$ dynamic w
chpf$ template t
chpf$ processors p

Well, not that easy an issue:-) It becomes an issue with teh *many*
suggested extensions considered by the forum for HPF-later...

Well, happy new year, 

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