Subject: hpff-distribute: distribution ranges

From: Fabien COELHO <[email-masked]>
Date: Tue, 27 Feb 96 10:29:55 +0100

---------------------------------------------------------------------------
[email-masked] 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,

I just had a look at the "distribution range" proposal briefly outlined
in the HPFF meeting minutes. The aim seems to be the same than some
suggestion I posted, i.e. to tell the compiler about several reaching
mappings for a subroutine, in place of (?) inherit. I would like to point
out some defficiencies of this proposal (if I understood it correctly): 

 1/ the syntax does not seem to be consistent with any other part of HPF... 
    RANGE seems to be another word for DISTRIBUTE somehow? 
    Why one more keyword? 
    what if I want to specify some alignments? 
    processor arrangement?
    why going away from ALIGN and DISTRIBUTE?
    It does not allow to express the varity of reaching mappings of HPF.

 2/ It seems that you cannot specify the relative mapping of data one with
    respect to the other. For instance

    subroutine sub(A,B)
    real A(:), B(:)
    real TMP
    INHERIT A, B
    RANGE A (BLOCK), (CYCLIC) 
    RANGE B (BLOCK), (CYCLIC)
    DISTRIBUTE TMP (BLOCK) ??? OR CYCLIC...
    A=B+TMP

    If it happens that A and B are always distributed the same, BLOCK or
    CYCLIC, you cannot provide this information to the compiler.
    It seems that you can just specify the mapping on a array per array
    basis, but the compiler must deal with 4 potential mappings when
    compiling A=B. 

  3/ It seems that you cannot specify a mapping for local data which would
     depend on the reaching mappings. (TMP example above)

  4/ you cannot play with several descriptive or prescriptive mappings as
     a default.

  5/ I cannot see the simple and efficient implemementation. I suspect
     that the intent is to have some boolean everywhere to guard 
     array references (???) but that does not help much when
     communication implying two such arrays must be managed; for a
     cloning based approach the cross product of distributions must
     be handled what may be both costly and useless (see 2)

To summarize my points: in my opinion the suggested approach is

  - ugly (syntax, interaction with DISTRIBUTE...)
  - not very expressive (ALIGN?, related arrays? default case?)
  - not straighforward/expensive to implement.

Ad: 

I outlined an "ASSUME" directive in report A-284 that can be found from my
web page, to describe several reaching mappings, which is far from being
perfect, but which is

  - consistent with ALIGN and DISTRIBUTE that are just reused...
  - expressive (full HPF mappings, related arrays, default...)
  - efficiently compilable (compile/link time) with the *current* compiler
    technology!

End Ad:-)

========

As a general comment to the minutes, I don't think that the perception
people have of current HPF developments is wrong, and that it is just a
marketing problem for the Forum to change this. It think that nobody there
has a clear understanding of the path to follow for making something
useful of HPF, and that this lack of vision is just revealed by the many
contradictory decisions made by the forum... For instance, having to
change the voting rules and splitting the language into pieces, changing
old definitions and constraints, aso, just make people outside feel that
there may be some problem, and there is actually a problem. It is not just
marketing. The issue is the interaction of people with a complex object as
such a programming language, the benefit they may get from it if it is
expressive and compilable, or the otherway around the missed opportunity
if it is too big, not balanced and difficult to compile, thus useless for
them. I'm not very construtive here, but it is not simple a problem. 

My point is just that it is not just a marketing problem. The problem is
not that the message is not well perceived from outside, it is that the
message is not clear by itself, or that there is no message, yet:-)

I think that one of the problem is to try to make an industrial product
from research areas that are not well cleaned and analyzed and understood
and accepted, yet again:-) Also all these ideas interact one with the
other and this complexity is not really managed.

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