From owner-hpff-distribute Fri Feb 9 10:37:46 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA23651 for hpff-distribute-out; Fri, 9 Feb 1996 10:37:46 -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 KAA23645; Fri, 9 Feb 1996 10:37:36 -0600 (CST) Received: from cri.ensmp.fr (chailly.ensmp.fr) by fontainebleau with SMTP id AA10037 (5.67a8/IDA-1.5); Fri, 9 Feb 1996 17:37:16 +0100 Received: from provins.caii by cri.ensmp.fr (4.1/SMI-4.0) id AA21791; Fri, 9 Feb 96 17:37:16 +0100 Date: Fri, 9 Feb 96 17:37:16 +0100 Message-Id: <9602091637.AA21791@cri.ensmp.fr> Received: by provins.caii (4.1/SMI-4.1) id AA14645; Fri, 9 Feb 96 17:37:14 +0100 From: Fabien COELHO To: hpff-task@cs.rice.edu, hpff-distribute@cs.rice.edu Subject: hpff-distribute: technical report about HPF design issues 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, The following report summarizes and discusses some ideas I sent on the HPF mailing lists in the last months: "HPF Design Issues" by Fabien Coelho. Report EMP CRI A-284, February 1996. 9 pages, 15 references. Abstract As High Performance Fortran (HPF) is being both developed and redesigned by the HPF Forum, it is important to provide comprehensive criteria for analyzing HPF features. This paper presents such criteria related to three aspects: adequacy to applications, aesthetic and soundness in a language, and implementability. Some features already in HPF or being currently discussed are analyzed according to these criteria. They are shown as not balanced. Thus new or improved features are suggested to solve the outlined deficiencies: namely a scope provider, multiple mapping declarations and simpler remappings. http://www.cri.ensmp.fr/~coelho/bibliography.html http://www.cri.ensmp.fr/~coelho/doc/A-284.ps.gz http://www.cri.ensmp.fr/~coelho/doc/A-284.ps 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 Tue Feb 27 03:31:03 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id DAA07383 for hpff-distribute-out; Tue, 27 Feb 1996 03:31:03 -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 DAA07375 for ; Tue, 27 Feb 1996 03:30:32 -0600 (CST) Received: from cri.ensmp.fr (chailly.ensmp.fr) by fontainebleau with SMTP id AA23104 (5.67a8/IDA-1.5 for ); Tue, 27 Feb 1996 10:29:55 +0100 Received: from provins.caii by cri.ensmp.fr (4.1/SMI-4.0) id AA08408; Tue, 27 Feb 96 10:29:55 +0100 Date: Tue, 27 Feb 96 10:29:55 +0100 Message-Id: <9602270929.AA08408@cri.ensmp.fr> Received: by provins.caii (4.1/SMI-4.1) id AA23912; Tue, 27 Feb 96 10:29:50 +0100 From: Fabien COELHO To: zongaro@vnet.ibm.com Subject: hpff-distribute: distribution ranges Cc: hpff-distribute@cs.rice.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 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.= =2E. = 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 wit= h 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=3DB+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=3DB. = 3/ It seems that you cannot specify a mapping for local data which woul= d 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 m= y 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* compile= r technology! End Ad:-) =3D=3D=3D=3D=3D=3D=3D=3D 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 ther= e 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 jus= t marketing. The issue is the interaction of people with a complex object a= s 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 __ coelho@cri.ensmp.fr CRI, ENSMP, 35, rue Saint Honor=E9, 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 ---------------------------------------------------------------------------