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

From: [email-masked] (Chuck Koelbel)
Date: Wed, 3 Jan 1996 11:29:45 -0600 (CST)

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

>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
>...
>chpf$ end scope

This idea seems appealing.  But I think it is better sent to the Fortran
2000 committee than to HPF.  Many things in F95 and HPF would be simpler if
we had a block-structured language.  In particular, we would not need NEW
if there were real local variables within a loop.

I'm a little curious - is SCOPE just a syntactic marker, or do you have
some further meaning for it?  For example, if there is no HPF-directive
before SCOPE, does it signify anything?

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

I assume that "..." doesn't include DISTRIBUTE, REALIGN, and the other
mapping directives?  If it does, what does
        !HPF$ REALIGN x(BLOCK)
        !HPF$ SCOPE
          x = CSHIFT(x,1)
        !HPF$ END SCOPE
        y = x
mean (in particular, what is the distribution of x when it is assigned to y)?

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

I tend to think this is a bad idea, since it moves the assertion pretty far
from where it is used.  But it's reasonable to discuss.

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

If you really want it to be discussed in HPF 2, you'd better get it written
up quickly.  The next HPFF 2 meeting is next week, and there aren't that
many more planned.

There is more time to send it off to Fortran 2000, which might be the
better choice anyway.  Why improve just HPF when you can help all of
Fortran?

                                                Chuck

---------------------------------------------------------------------------
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: Thu, 4 Jan 96 10:31:38 +0100

Hi Chuck,

> [...]
> Many things in F95 and HPF would be simpler if we had a block-structured
> language.  In particular, we would not need NEW if there were real local
> variables within a loop.

Sure. This is no more than the {} of C. Allowing local declarations would
drop the new directive, or just make it obsolete...

What stuck me is that there are TWO directives to provide a scope which
are being independently discussed by the HPF Forum: one for ON and one for
TASK. I think this should be noticed and stopped before having them in the
language... While a more general and pretty approach might unify both (and
possibly more) constructs...

In the example above, I do not necessary which to specify a ON or a
task, but I want one for reduction and new. Could be new alone or
reduction alone. Just mean that there is a need for some "scoping" in HPF
which is not related to loops. I don't think it would be nice to have two
different constructs in the language and not to be allowed to write the
reduction example above... Thus the Forum should consider such an
extension just for the language to be nice/pretty. For the syntax to be
homogeneous accross different HPF extensions...

If some BLOCK/END BLOCK or any other block structure is proposed by
F-later, fine, it will just obsolete the corresponding HPF structure and
few corrections will be needed to the standard to add the Fortran
structure as another possible scope provider...
 
> before SCOPE, does it signify anything?

Not in my mind. I was just thinking of putting some constraints on it so
that there is only one entry point (scope) and one exit point (end scope),
because such constraints would ease the compilation process, maybe.
Additional constraint might be added when directives are added. 
Say for instance no I/O...

> mapping directives? 

Not in my mind. I just thought about declaration and advices to the
compiler about the code. But it is worth duscussing the point. 
I don't think that static mapping directives would make sense. 
I don't think that the idea of "executable" directive should be changed to
have some kind of implicite meaning in this context. 

> from where it is used.  But it's reasonable to discuss.

Ya. The motivation here was just to relax one of the constraint between
directives and scope providers. 

> up quickly.  The next HPFF 2 meeting is next week, and there aren't that

I don't think I'll have time for next week... 

There are a couple of things that I would like the Forum to think about
and at least to consider as a possible path for improving/cleaning/...
HPF and the kernel. But I won't be sent to the US for talking about this
to the forum:-) All I can do is to send mail describying and arguing about
these ideas, so that people chat about them, and if they find them
interesting then some more formal process for including them in the 
language could be launched. At the time these ideas are:

[mail of Dec 13 to hpff-distribute]

 - disallowing ambiguity for remappings and putting them into the kernel
   (if no "dynamic" ambiguity about the mapping is allowed, and since the
    mappings are quite simplified in the kernel, it is not that
    difficult to handle them. I can suggest a simple algorithm to manage
    them with "renamings" and copie. It is implemented in my prototype,
    so it must be quite easy:-) 

 - allowing several static descriptive mappings to be specified for an
   array in a subroutine. for the kernel.
   (=> (maybe) automatic cloning for the different cases by the compiler.
    better than inherit I think, because it gives some information
    to the compiler, and simple implementation)

[mail of Jan 2 to hpff-distribute, forwarded to hpff-task]

 - the reduction syntax attached to the loop instead of the statement.
   was included by Rob in the last proposal, so it's ok.
 
[mail of Jan 3 to hpff-task]

 - some scope/split/endscope directive as a scope provider and hook
   for some HPF-directives (independent/new/reduction/on/task/???).

[???]

 - independent(i,j) as syntactic sugar for "independent, new/ind..."
   before a loop nest.

That's all at the moment:-)

> better choice anyway.  Why improve just HPF when you can help all of

Well, because I don't like Fortran as a programming language, while HPF
compilation is my PhD subject, so I want to improve HPF features:-)
Seriously, I think the HPF Forum might be quicker to consider such ideas
if they  appear to be meaningful and desirable, while the Fortran
definition is much slower.

Have a nice day.

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