From owner-hpff-interpret Tue Jul 2 10:32:11 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA00964 for hpff-interpret-out; Tue, 2 Jul 1996 10:32:11 -0500 (CDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id KAA00959 for ; Tue, 2 Jul 1996 10:32:03 -0500 (CDT) Received: from mpsg.hpc.pko.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA01733; Tue, 2 Jul 1996 11:06:44 -0400 (EDT) Received: by mpsg.hpc.pko.dec.com; id AA12229; Tue, 2 Jul 1996 11:07:09 -0400 From: offner@hpc.pko.dec.com (Carl Offner) Received: by hardy.hpc.pko.dec.com; (5.65v3.2/1.1.8.2/01Nov94-0839AM) id AA26055; Tue, 2 Jul 1996 11:06:26 -0400 Date: Tue, 2 Jul 1996 11:06:26 -0400 Message-Id: <9607021506.AA26055@hardy.hpc.pko.dec.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: Wording change for RANGE Cc: offner@hpc.pko.dec.com Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- ************************************ * * * Re-Wording the RANGE Directive * * * ************************************ Carl D. Offner Digital Equipment Corporation offner@hpc.pko.dec.com ***************** Executive Summary ***************** The RANGE directive, as currently specified, contains a serious weakness that makes it virtually useless for a compiler and counter-intuitive for a programmer. This re-wording restores the original intent. ************************ Proposal for re-wording: ************************ Replace lines 36-44 (lines 3-10 in the draft document; i.e., the following lines) ----------------------------------------------------------------------- If a ranger is given the RANGE attribute, every range-attr in at least one of the range-attr-stuffs must be compatible with the distribution format of the corresponding dimension of the 1. template of the ranger, if the ranger is transcriptively distributed; 2. target of the ranger, if the ranger has the POINTER attribute, and is associated; or 3. ranger, if the ranger has the DYNAMIC attribute. ----------------------------------------------------------------------- with the following two paragraphs: ----------------------------------------------------------------------- Since the length of each range-attr-list is the same as the rank of the ranger, each range-attr R in each range-attr-stuff corresponds positionally to a dimension D of the ranger. This dimension D in turn corresponds (though in general, not positionally) to an axis A of the template with which the ranger is ultimately aligned. With this notation, a RANGE attribute on a ranger is equivalent to the following constraint: For at least one range-attr-stuff in the range-attr-stuff-list, every range-attr R must be compatible with the distribution format of the corresponding axis A. ----------------------------------------------------------------------- *********** Discussion: *********** This was actually my understanding of the meaning of the RANGE attribute when I originally proposed something similar to this in Group D. The point was this: in the presence of the new distributions (generalized block, indirect mapping), it is quite significant for the compiler to know that the ultimate align target of an argument or a pointer is or is not distributed generalized block, for instance. (It is also good to be able to distinguish between BLOCK and CYCLIC, but distinguishing between generalized block and other mappings is even more important.) The precise alignment of the object with its template, on the other hand, is nice to know at compile time, but is not nearly so important in terms of generating efficient code. So we need a syntactic device enabling the user to specify a range of possible distributions, leaving open the associated alignment. This proposal would do that. In addition, it should be noted that without this facility, an explicitly mapped pointer could not be used to point to an array section. My understanding is that one of the main uses of pointers is to give names to array sections. ****************** Example: Pointers ****************** REAL, DIMENSION(:), POINTER :: A !HPF$ RANGE A (BLOCK) This now means that A is a pointer that can be used to point to (a section of) a block-distributed array. For instance, A => B(1:307:3) where B is distributed BLOCK. Without the rewording suggested above, such a pointer assignment would be impossible. ******************************************** Example: Dummies with the INHERIT attribute ******************************************** The discussion here is a bit subtle. Consider first of all the following fragment: ----------------------------------------------------------- module sub_mod contains subroutine sub(d) dimension(:,:) :: d !hpf$ inherit d ... end subroutine end module program main use sub_mod real, dimension(100,100,100) :: a !hpf$ distribute(block,*,cyclic) :: a call sub(a(:,:,1)) call sub(a(:,1,:)) call sub(a(1,:,:)) end ----------------------------------------------------------- If the dummy d in the subroutine sub is constrained by the directive !hpf$ range d (block,cyclic) then only the second call is legal. However, all three calls could be made legal, even with a RANGE directive, as follows: !hpf$ range d (cyclic(),cyclic()), (*,cyclic()), (cyclic(),*) ************************ What is the alternative? ************************ An alternative interpretation of RANGE (which is explicitly rejected in this proposal) would be to say, in the case of a dummy with the INHERIT attribute, that the the range-dist-attr-list must refer to the entire template with which the actual is ultimately aligned. This would be similar to the current meaning of a DISTRIBUTE directive applied to a dummy with the INHERIT attribute; Carol Munroe has a proposal pointing out similar problems with that usage and suggesting it be done away with. Under this alternative interpretation, the only allowable RANGE directive in this case would be !hpf$ range d (block, *, cyclic) or something subsuming this, such as !hpf$ range d (cyclic(), *, cyclic()) However, this gives the compiler very little useful information -- in fact, the only real information it gives the compiler is the rank of the template with which the actual is ultimately aligned. The situation is far worse if we allow some of the new distributions that are approved extensions. For instance, suppose the example is modified as follows: ----------------------------------------------------------- module sub_mod contains subroutine sub(d) dimension(:,:) :: d !hpf$ inherit d ... end subroutine end module program main use sub_mod real, dimension(100,100,100) :: a !hpf$ distribute(gen_block(extents), cyclic, indirect(map)) :: a call sub(a(:,:,1)) call sub(a(:,1,:)) call sub(a(1,:,:)) end ----------------------------------------------------------- In this case, the only RANGE directive that would be allowable under this proposal (that makes all three calls legal) would be !hpf$ range d (all, all) It might seem that the alternative interpretation, under which one could write !hpf$ range d (gen_block, cyclic, indirect) would give more information. But actually, it does not, because the compiler has no way of knowing which dimension of the dummy has which distribution. I believe that the directive should be construed in such a way that it gives the compiler as much meaningful information as possible. --------------------------------------------------------------------- Aside: For the Digital compiler, it is quite important to know (i.e., at compile-time) whether the distribution of the template axis corresponding to each dummy axis is a) in the cyclic(n) family (i.e., block, cyclic, block(n), cyclic(n), or *), or b) generalized block, or c) an indirect map. It would even be nice to know in case (a) whether the mapping was actually block or cyclic, for instance. This, however, is a secondary consideration, although one that the language proposed here also handles. It is fair to say that without this information, the quality of the generated code will be compromised. Given this information, the compiler generates quite different loop structures and addressing expressions. Without this information, all the work must be left to run-time routines, and we end up with more of an interpreted language than a compiled one. Other compilers may well have different requirements, but the general idea is probably similar---more information is better. --------------------------------------------------------------------- In addition, the proposal presented here is much more in line with what a programmer would naturally expect. In fact, the already stated constraint on line 33 (line 48 of the previous page in the draft document) Constraint: The length of any range-attr-list must equal the rank of the ranger. is compatible ONLY with the new wording suggested here; this supports the contention that this interpretation is what programmers will undoubtedly expect. In summary, I believe that this alternative interpretation has the following defects: * It is nearly useless for the compiler: it does not give the compiler information that it really needs to know and could make good use of. * It will make it much more difficult to support the generalized block and indirect mapping extensions. * It is counter-intuitive for programmers. * It will most likely lead to the RANGE directive being ignored by actual implementations; this in turn will probably be regarded, incorrectly, as some sort of a bug by programmers who will then have to be educated by the vendors on the curious meaning of this syntax. --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jul 2 11:33:57 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id LAA03431 for hpff-interpret-out; Tue, 2 Jul 1996 11:33:57 -0500 (CDT) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id LAA03426 for ; Tue, 2 Jul 1996 11:33:54 -0500 (CDT) Received: from Gandalf.Think.COM by mail.think.com; Tue, 2 Jul 96 12:12:14 -0400 From: Carol Munroe Received: by gandalf.think.com (4.1/Think-1.2) id AA14735; Tue, 2 Jul 96 12:33:51 EDT Date: Tue, 2 Jul 96 12:33:51 EDT Message-Id: <9607021633.AA14735@gandalf.think.com> To: hpff-interpret@cs.rice.edu Cc: munroe@think.com Subject: hpff-interpret: Proposal to disallow INHERIT + DISTRIBUTE combination Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- ************************************* Should all INHERITs be transcriptive? ************************************* An argument for disallowing the combination INHERIT + DISTRIBUTE This proposal was inspired by an earlier CCI raised by Carl Offner concerning the combination of INHERIT and DISTRIBUTE directives for the same dummy array, and related to his current RANGE rewording proposal. When a dummy argument is used in an INHERIT directive, then, as long as the actual argument is either a whole array or a regular array section, the template for the dummy argument is a copy of the template with which the actual argument or its parent array is ultimately aligned. (In any other case, nothing can be predicted about the shape or distribution of the template for the dummy argument, and no explicit DISTRIBUTE attribute is allowed, and such cases will be ignored in the following discussion.) A problem of either interpretation or rank arises when a dummy argument has both an INHERIT attribute and an explicit DISTRIBUTE attribute. In this case the dummy argument D must a) Have the same alignment as the actual argument, but with a copy of the template with which the actual argument (or its parent array) is aligned, and b) Have a default transcriptive distribution of the form !hpf$ distribute D * onto *. that may be wholly or partially overridden by the explicit DISTRIBUTE (descriptive, prescriptive, or transcriptive). ***************************** The first question raised is: "Does an explicit DISTRIBUTION of an inherited dummy logically apply to the (newly copied) template rather than to the dummy itself?" ***************************** Suppose the answer is "No, explicit distributions are meant to describe the mapping of the dummy argument itself." This is presumably the answer if the DISTRIBUTE axis info must match the rank of the dummy argument given as the distributee. Then what precisely is the sense of the inherited alignment, when the dummy argument itself is explicitly distributed? This would logically contradict the rule that no variable may have both a DISTRIBUTE and an INHERIT attribute simultaneously and that only ultimate align targets can be explicitly distributed. Since the dummy argument itself is stated to be aligned with its freshly copied template, consistency with all the mapping principles for all other variables implies that it is the nameless template which is actually being mapped, so the answer should be "Yes, it's really the template that is logically being distributed." This creates an awkwardness, since the object actually named in a DISTRIBUTE directive can only be the dummy argument, not the unnamed template, while the rank of the mapping must agree with that of the template, not necessarily with the declared rank of the dummy argument itself. The rules for DISTRIBUTE require the "rank of the distributee" to equal the number of axes for which mapping information is given. When the actual argument is an array section of lower rank than the whole array, or when the actual argument is a whole array aligned with an template of a different rank from itself, this would force the DISTRIBUTE directive to appear to contradict that rule. This conflict between declared and implied rank is highly non-intuitive for users. Moreover, the correctness of such a DISTRIBUTE directive cannot be verified during separate compilation of the subprogram, and the compiler would be hard-pressed to find any advantage in the information it attempts to convey. For example: ***************************** subroutine sub(x,y,z) real, dimension(100,200) :: x,y,z !hpf$ inherit :: x,y,z !hpf$ distribute$ x(block,block,cyclic) !hpf$ distribute$ y(cyclic) !hpf$ distribute$ z(block,cyclic) ***************************** could perhaps be correctly called by a program like the following, ***************************** program main real, dimension(100,200) :: a,b,c !hpf$ template, dimension(100,200,300) :: t1 !hpf$ distribute t1(block,block,cyclic) !hpf$ template, dimension(100) :: t2 !hpf$ distribute t2(cyclic) !hpf$ template, dimension(200,300) :: t3 !hpf$ distribute t3(block,cyclic) !hpf$ align a(:,:) with t1(:,:,*) !hpf$ align b(*,:) with t2(:) !hpf$ align c(*,:) with t3(:,*) call sub(a,b,c) end ***************************** but directives like these are ugly to write and to maintain, as they fly in the face of the Fortran principle that array rank is always determined at compile time. Furthermore, the distribution directives contain almost no information that could be used at compile time. For example, the compiler could not tell whether x's 1st axis in the above example is to be distributed BLOCK, CYCLIC, or collapsed, or whether z is itself distributed (block,cyclic), or, as in this case, has its 1st axis collapsed, its second axis block-distributed, and is replicated over a cyclic-distributed axis. Included in an interface block, such information could be compared with the actual subroutine calls and used to remap arguments, but they seem useless in the routine itself. ******************************** The question that now arises is: "Why allow INHERIT + DISTRIBUTE in the first place?" ******************************** We should consider whether the advantages of being able to redistribute an align target of a dummy argument outweigh the disadvantages of of permitting such unreadable and uncheckable syntax. One might argue that it would suffice to prohibit INHERIT + DISTRIBUTE in cases where the dummy argument and its inherited template are of different rank, but the example of the third argument C to the subroutine above shows that even when the ranks are the same, the alignment can involve permutation of axes or collapsing plus replicating, so that mapping information for the axes of the dummy's template do not predict much about specific axes of the dummy. One of the most likely reasons appears to have been to support Subset HPF 1.0, which included the INHERIT directive but not the transcriptive forms of the DISTRIBUTE directive, so users of INHERIT were obliged to have prescriptive or descriptive DISTRIBUTE directives to accompany every INHERIT (presumably to avoid implying a transcriptive mapping that could not be indicated explicitly). However, the changes to Subset HPF since version 1.1 invalidate this argument, since HPF 1.1 removed INHERIT from Subset HPF entirely, while including the transcriptive forms (and all forms) of DISTRIBUTE. What else is INHERIT + DISTRIBUTE good for? INHERIT is most valuable for allowing objects to be passed in place, with no remapping, allowing both any alignment and any distribution, the so-called "transcriptive INHERIT". It is essential for implementing library code that must accept arguments with a wide variety of mappings. The allowed types of the mappings can be detailed if the RANGE extension is implemented. If either the axis mapping types or the "ONTO" processor arrangement is indicated explicitly, then it becomes essentially either a "descriptive" or "prescriptive INHERIT". The old "descriptive INHERIT" allows one to specify mapping attributes for a nameless template copied from the calling program. But since neither the shape of the template nor the pattern of alignment of the dummy is described, this is fairly useless information as described above, and cannot reasonably be expected to generate more efficient code than the "transcriptive" INHERIT with a default * ONTO * distribution. Either a new ALIGN directive to an explicitly declared template, itself with an explicit distribution would convey much more useful information to the system. Similarly, useful information could also be conveyed to the compiler via the optional RANGE directive, which (according to Carl Offner's latest proposal) can give an axis by axis description of the mapping or possible range of mappings of a dummy argument with the INHERIT attribute. Such information is probably more useful to the compiler than a descriptive distribution of the unnamed, copied template, particularly if it is required to correspond axis-by-axis with the dummy argument itself, thus avoiding another mixed rank problem. The "prescriptive INHERIT", which in HPF 2.0 is equivalent to having both the INHERIT and DISTRIBUTE attributes for an argument in an explicit interface, does offer some additional functionality by allowing an arbitrary pattern of alignment to be inherited from an actual argument, while also choosing to remap the ultimate align target. But it is hard to imagine an example that could not be handled in another more efficient fashion. Inheriting an alignment while remapping data might seem to offer some advantage if multiple actual arguments are to maintain an unknown but preexisting alignment with a template that gets remapped for the duration of the subprogram. However, it is difficult to see how a system could take any advantage of this information, since no relation between the arguments would be indicated in the code. Each of the arguments would have a separate copy of the old template, and each could have an INHERIT + DISTRIBUTE mapping preserving the original type of alignment although to an individually remapped template, but the compiler would have no hint of their relationship, and dummy arguments would not share a common template. Certainly no optimization could be done at compile time. In particular, if multiple actual arguments had an identical alignment with the same template, it would be far more useful for one argument to be chosen for redistribution (or aligned with a dynamically redistributed template, declared in a module) and for the other arguments to be aligned explicitly with the designated one. Then the compiler could benefit from knowledge that the arguments were aligned with each other. More generally, an arbitrary pattern of alignment can be described via a list of scalar arguments, which could be passed to a subprogram along with the aligned array or array section. Such data would permit the alignment to be described in an ALIGN directive, with the target TEMPLATE redeclared locally and given any desired explicit mapping. Thus a more explicit alignment would achieve the same mapping, and its presence in the subprogram could provide useful information that the compiler could use. ********************** Conclusion ********************** I hereby propose that the combination of INHERIT + DISTRIBUTE be eliminated from HPF completely, letting the other rules for INHERIT stand. Thus each instance of INHERIT would be both a transcriptive type of alignment plus a transcriptive distribution, with no remapping desired, and would take the place of the nonexistent syntax ALIGN X * WITH * (by rough analogy with DISTRIBUTE), plus an implied DISTRIBUTE * ONTO * for its template. Just as ALIGN and DISTRIBUTE attributes cannot be combined for the same object, INHERIT and DISTRIBUTE attributes could not be combined explicitly for the same object. The result will be a simplification of the language that preserves its useful functionality as well as the principle of constancy of rank for data objects in HPF directives as in Fortran expressions. Implementation note: In the interest of supporting any existing codes that might now use INHERIT + DISTRIBUTE in combination, I would suggest that HPF 2.0 implementations simply provide warnings that DISTRIBUTE attributes of INHERITed dummy arguments are replaced by a default DISTRIBUTE * ONTO * in effect, but not making such a combination an error that prevents compilation. --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jul 2 12:34:20 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id MAA05531 for hpff-interpret-out; Tue, 2 Jul 1996 12:34:20 -0500 (CDT) Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk [138.253.100.84]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id MAA05524 for ; Tue, 2 Jul 1996 12:34:12 -0500 (CDT) Received: from chad2-13.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Tue, 2 Jul 1996 18:23:42 +0100 From: "Dr A.C. Marshall" Message-Id: <199607021723.SAA10007@chad2-13.liv.ac.uk> Subject: hpff-interpret: New HPF Courseware To: hpff-interpret@cs.rice.edu (HPFF), ukfortran@ed.ac.uk (ukfortran mailbase), comp-fortran-90@mailbase.ac.uk Date: Tue, 2 Jul 1996 18:23:37 +0100 (BST) Cc: adamm@liverpool.ac.uk (Dr A.C. Marshall) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- New HPF Courses +++++++++++++++ The Computing Services Department of the University of Liverpool has just finished updating their HPF Courses. These courses have been funded by JISC New Technologies Initiative and are available for downloading from URL: http://www.liv.ac.uk/HPC/HPFpage.html The previous incarnation of these courses received good reports - any feedback on the improved versions is strongly welcomed. The following text is taken from the above web page: -- There are two main Courses lasting 3 and 5 days and a shorter Seminar. The courses comprise OHP Slides, Course Notes, Student Exercises and Lecturers Guide. There is also a set of OHPs for a 40 minute Seminar explaining the conversion Fortran 77 codes into HPF. The 5 Day Course is a complete guide to to Fortran 90 / HPF. This course is for programmers who are familliar with a high level language such as C or Pascal. The 3 Day Course is designed for the those with programming experience in Fortran 90 and who whish to learn the basics of HPF. Each day is divided into two 3 hour sessions: 1 hour lecture, 2 hours practical. The course therefore is divided into 6 x 1 hour sessions: Data Parallelism (Introduction), Alignment and Distribution, Forall and Prallel Loops, Procedures, Extrinsic Procedures and Vectorisation and The HPF Library and HPF in the Future. The HPF Seminar will give a good introduction to HPF Programminmg. The Fortran 77 to HPF Conversion Seminar is designed for the those who whish to convert old Fortran 77 into a format suitable for submission to an HPF system. The slides explain some simple conversion productions and give simplistic examples as illustrations. -- These courses may be used for non-commercial gain. -- Dr AC Marshall | Cheese of the Week: CSD, University of Liverpool. L69 3BX | St Paulin. Tel: +44-151-794 3722 (Fax: 3759) | Mmmmm, St Paulin. http://www.liv.ac.uk/HPC/HPCpage.html http://www.liv.ac.uk/~adamm/HomePage.html --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jul 2 15:49:55 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id PAA12870 for hpff-interpret-out; Tue, 2 Jul 1996 15:49:55 -0500 (CDT) Received: from hermes.fundp.ac.be ([138.48.4.4]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id PAA12865 for ; Tue, 2 Jul 1996 15:49:51 -0500 (CDT) Received: from dialin02.net.fundp.ac.be by hermes.fundp.ac.be; (5.65v3.2/1.1.8.2/14Dec95-0443PM) id AA16389; Tue, 2 Jul 1996 22:52:27 +0200 Message-Id: <1.5.4.32.19960702205045.00683760@verdi.scf.fundp.ac.be> X-Sender: vigneron@verdi.scf.fundp.ac.be X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 02 Jul 1996 22:50:45 +0200 To: hpff-interpret@cs.rice.edu (HPFF), ukfortran@ed.ac.uk (ukfortran mailbase), comp-fortran-90@mailbase.ac.uk From: Philippe Destree Subject: hpff-interpret: New HPF Courseware Cc: adamm@liverpool.ac.uk (Dr A.C. Marshall) Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- New HPF Courses +++++++++++++++ The Computing Services Department of the University of Liverpool has just finished updating their HPF Courses. These courses have been funded by JISC New Technologies Initiative and are available for downloading from URL: http://www.liv.ac.uk/HPC/HPFpage.html The previous incarnation of these courses received good reports - any feedback on the improved versions is strongly welcomed. The following text is taken from the above web page: -- There are two main Courses lasting 3 and 5 days and a shorter Seminar. The courses comprise OHP Slides, Course Notes, Student Exercises and Lecturers Guide. There is also a set of OHPs for a 40 minute Seminar explaining the conversion Fortran 77 codes into HPF. The 5 Day Course is a complete guide to to Fortran 90 / HPF. This course is for programmers who are familliar with a high level language such as C or Pascal. The 3 Day Course is designed for the those with programming experience in Fortran 90 and who whish to learn the basics of HPF. Each day is divided into two 3 hour sessions: 1 hour lecture, 2 hours practical. The course therefore is divided into 6 x 1 hour sessions: Data Parallelism (Introduction), Alignment and Distribution, Forall and Prallel Loops, Procedures, Extrinsic Procedures and Vectorisation and The HPF Library and HPF in the Future. The HPF Seminar will give a good introduction to HPF Programminmg. The Fortran 77 to HPF Conversion Seminar is designed for the those who whish to convert old Fortran 77 into a format suitable for submission to an HPF system. The slides explain some simple conversion productions and give simplistic examples as illustrations. -- These courses may be used for non-commercial gain. -- Dr AC Marshall | Cheese of the Week: CSD, University of Liverpool. L69 3BX | St Paulin. Tel: +44-151-794 3722 (Fax: 3759) | Mmmmm, St Paulin. http://www.liv.ac.uk/HPC/HPCpage.html http://www.liv.ac.uk/~adamm/HomePage.html --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Mon Jul 8 17:21:22 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id RAA14571 for hpff-interpret-out; Mon, 8 Jul 1996 17:21:22 -0500 (CDT) Received: from [128.42.1.213] (morpheus.cs.rice.edu [128.42.1.213]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id RAA14557; Mon, 8 Jul 1996 17:21:16 -0500 (CDT) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Jul 1996 17:23:32 -0600 To: Carol Munroe From: chk@cs.rice.edu (Chuck Koelbel) Subject: Re: hpff-interpret: Proposal to disallow INHERIT + DISTRIBUTE combination Cc: hpff-interpret@cs.rice.edu, munroe@think.com, hpff-distribute Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- I agree both with Carol's goal (simplifying HPF's arcane subroutine interfaces) and tactics (making INHERIT mean what programmers think it means). There are, of course, details that may get in the way. For example, can RANGE tell us everything about INHERITed dummies? (I suspect pathological cases of permuting axes in ALIGNs can reduce the effectiveness of RANGE - after all, the reason for INHERIT in the first place was that we found incoming distributions that we couldn't describe using just DISTRIBUTE...) But these can be debated in subcommittee... I suggest that discussions continue on the hpff-distribute list, rather than hpff-interpret (which is supposed to be there for answering questions about the existing language). Chuck At 12:33 07/02/96, Carol Munroe wrote: > ************************************* > Should all INHERITs be transcriptive? > ************************************* > > An argument for disallowing the combination > INHERIT + DISTRIBUTE > >This proposal was inspired by an earlier CCI raised by Carl Offner >concerning the combination of INHERIT and DISTRIBUTE directives for >the same dummy array, and related to his current RANGE rewording >proposal. > >When a dummy argument is used in an INHERIT directive, then, as long >as the actual argument is either a whole array or a regular array >section, the template for the dummy argument is a copy of the template >with which the actual argument or its parent array is ultimately >aligned. (In any other case, nothing can be predicted about the shape >or distribution of the template for the dummy argument, and no >explicit DISTRIBUTE attribute is allowed, and such cases will be >ignored in the following discussion.) > >A problem of either interpretation or rank arises when a dummy >argument has both an INHERIT attribute and an explicit DISTRIBUTE >attribute. In this case the dummy argument D must > > a) Have the same alignment as the actual argument, but with a copy of the >template with which the actual argument (or its parent array) is aligned, and > > b) Have a default transcriptive distribution of the form > > !hpf$ distribute D * onto *. > >that may be wholly or partially overridden by the explicit DISTRIBUTE >(descriptive, prescriptive, or transcriptive). > >***************************** >The first question raised is: > > "Does an explicit DISTRIBUTION of an inherited dummy logically apply > to the (newly copied) template rather than to the dummy itself?" >***************************** > >Suppose the answer is "No, explicit distributions are meant to describe the >mapping of the dummy argument itself." This is presumably the answer if the >DISTRIBUTE axis info must match the rank of the dummy argument given as the >distributee. Then what precisely is the sense of the inherited alignment, >when the dummy argument itself is explicitly distributed? This would >logically contradict the rule that no variable may have both a DISTRIBUTE >and an INHERIT attribute simultaneously and that only ultimate align >targets can be explicitly distributed. > >Since the dummy argument itself is stated to be aligned with its >freshly copied template, consistency with all the mapping principles >for all other variables implies that it is the nameless template which >is actually being mapped, so the answer should be "Yes, it's really >the template that is logically being distributed." > >This creates an awkwardness, since the object actually named in a >DISTRIBUTE directive can only be the dummy argument, not the unnamed >template, while the rank of the mapping must agree with that of the >template, not necessarily with the declared rank of the dummy argument >itself. The rules for DISTRIBUTE require the "rank of the distributee" >to equal the number of axes for which mapping information is given. >When the actual argument is an array section of lower rank than the >whole array, or when the actual argument is a whole array aligned with >an template of a different rank from itself, this would force the >DISTRIBUTE directive to appear to contradict that rule. This conflict >between declared and implied rank is highly non-intuitive for users. >Moreover, the correctness of such a DISTRIBUTE directive cannot be >verified during separate compilation of the subprogram, and the compiler >would be hard-pressed to find any advantage in the information it attempts >to convey. > >For example: > >***************************** >subroutine sub(x,y,z) >real, dimension(100,200) :: x,y,z >!hpf$ inherit :: x,y,z >!hpf$ distribute$ x(block,block,cyclic) >!hpf$ distribute$ y(cyclic) >!hpf$ distribute$ z(block,cyclic) >***************************** > >could perhaps be correctly called by a program like the following, > >***************************** >program main >real, dimension(100,200) :: a,b,c >!hpf$ template, dimension(100,200,300) :: t1 >!hpf$ distribute t1(block,block,cyclic) >!hpf$ template, dimension(100) :: t2 >!hpf$ distribute t2(cyclic) >!hpf$ template, dimension(200,300) :: t3 >!hpf$ distribute t3(block,cyclic) >!hpf$ align a(:,:) with t1(:,:,*) >!hpf$ align b(*,:) with t2(:) >!hpf$ align c(*,:) with t3(:,*) >call sub(a,b,c) >end >***************************** > >but directives like these are ugly to write and to maintain, as they fly in >the face of the Fortran principle that array rank is always determined at >compile time. Furthermore, the distribution directives contain almost no >information that could be used at compile time. For example, the compiler >could not tell whether x's 1st axis in the above example is to be >distributed BLOCK, CYCLIC, or collapsed, or whether z is itself distributed >(block,cyclic), or, as in this case, has its 1st axis collapsed, its second >axis block-distributed, and is replicated over a cyclic-distributed axis. >Included in an interface block, such information could be compared with the >actual subroutine calls and used to remap arguments, but they seem useless >in the routine itself. > >******************************** >The question that now arises is: > > "Why allow INHERIT + DISTRIBUTE in the first place?" >******************************** > >We should consider whether the advantages of being able to redistribute an >align target of a dummy argument outweigh the disadvantages of of >permitting such unreadable and uncheckable syntax. One might argue that it >would suffice to prohibit INHERIT + DISTRIBUTE in cases where the dummy >argument and its inherited template are of different rank, but the example >of the third argument C to the subroutine above shows that even when the >ranks are the same, the alignment can involve permutation of axes or >collapsing plus replicating, so that mapping information for the axes of >the dummy's template do not predict much about specific axes of the dummy. > >One of the most likely reasons appears to have been to support Subset >HPF 1.0, which included the INHERIT directive but not the >transcriptive forms of the DISTRIBUTE directive, so users of INHERIT >were obliged to have prescriptive or descriptive DISTRIBUTE directives >to accompany every INHERIT (presumably to avoid implying a >transcriptive mapping that could not be indicated explicitly). > >However, the changes to Subset HPF since version 1.1 invalidate this >argument, since HPF 1.1 removed INHERIT from Subset HPF entirely, while >including the transcriptive forms (and all forms) of DISTRIBUTE. > >What else is INHERIT + DISTRIBUTE good for? INHERIT is most valuable for >allowing objects to be passed in place, with no remapping, allowing both >any alignment and any distribution, the so-called "transcriptive INHERIT". >It is essential for implementing library code that must accept arguments >with a wide variety of mappings. The allowed types of the mappings can be >detailed if the RANGE extension is implemented. If either the axis mapping >types or the "ONTO" processor arrangement is indicated explicitly, then it >becomes essentially either a "descriptive" or "prescriptive INHERIT". > >The old "descriptive INHERIT" allows one to specify mapping attributes >for a nameless template copied from the calling program. But since >neither the shape of the template nor the pattern of alignment of the >dummy is described, this is fairly useless information as described >above, and cannot reasonably be expected to generate more efficient >code than the "transcriptive" INHERIT with a default * ONTO * >distribution. Either a new ALIGN directive to an explicitly declared >template, itself with an explicit distribution would convey much more >useful information to the system. Similarly, useful information could >also be conveyed to the compiler via the optional RANGE directive, >which (according to Carl Offner's latest proposal) can give >an axis by axis description of the mapping or possible range of >mappings of a dummy argument with the INHERIT attribute. Such >information is probably more useful to the compiler than a descriptive >distribution of the unnamed, copied template, particularly if it is >required to correspond axis-by-axis with the dummy argument itself, >thus avoiding another mixed rank problem. > >The "prescriptive INHERIT", which in HPF 2.0 is equivalent to having >both the INHERIT and DISTRIBUTE attributes for an argument in an >explicit interface, does offer some additional functionality by >allowing an arbitrary pattern of alignment to be inherited from an >actual argument, while also choosing to remap the ultimate align >target. But it is hard to imagine an example that could not be handled >in another more efficient fashion. Inheriting an alignment while >remapping data might seem to offer some advantage if multiple actual >arguments are to maintain an unknown but preexisting alignment with a >template that gets remapped for the duration of the subprogram. >However, it is difficult to see how a system could take any advantage >of this information, since no relation between the arguments would be >indicated in the code. Each of the arguments would have a separate >copy of the old template, and each could have an INHERIT + DISTRIBUTE >mapping preserving the original type of alignment although to an >individually remapped template, but the compiler would have no hint >of their relationship, and dummy arguments would not share a common >template. Certainly no optimization could be done at compile time. > >In particular, if multiple actual arguments had an identical alignment >with the same template, it would be far more useful for one argument >to be chosen for redistribution (or aligned with a dynamically >redistributed template, declared in a module) and for the other >arguments to be aligned explicitly with the designated one. Then the >compiler could benefit from knowledge that the arguments were aligned >with each other. > >More generally, an arbitrary pattern of alignment can be described via >a list of scalar arguments, which could be passed to a subprogram >along with the aligned array or array section. Such data would permit >the alignment to be described in an ALIGN directive, with the target >TEMPLATE redeclared locally and given any desired explicit mapping. >Thus a more explicit alignment would achieve the same mapping, and its >presence in the subprogram could provide useful information that the >compiler could use. > >********************** > Conclusion >********************** > >I hereby propose that the combination of INHERIT + DISTRIBUTE be >eliminated from HPF completely, letting the other rules for INHERIT >stand. Thus each instance of INHERIT would be both a transcriptive >type of alignment plus a transcriptive distribution, with no remapping >desired, and would take the place of the nonexistent syntax ALIGN X * >WITH * (by rough analogy with DISTRIBUTE), plus an implied DISTRIBUTE >* ONTO * for its template. Just as ALIGN and DISTRIBUTE attributes >cannot be combined for the same object, INHERIT and DISTRIBUTE >attributes could not be combined explicitly for the same object. The >result will be a simplification of the language that preserves its >useful functionality as well as the principle of constancy of rank for >data objects in HPF directives as in Fortran expressions. > >Implementation note: In the interest of supporting any existing codes >that might now use INHERIT + DISTRIBUTE in combination, I would >suggest that HPF 2.0 implementations simply provide warnings that >DISTRIBUTE attributes of INHERITed dummy arguments are replaced by a >default DISTRIBUTE * ONTO * in effect, but not making such a >combination an error that prevents compilation. --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Jul 16 16:57:38 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id QAA22060 for hpff-interpret-out; Tue, 16 Jul 1996 16:57:38 -0500 (CDT) Received: from hplms26.hpl.hp.com (hplms26.hpl.hp.com [15.255.168.31]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id QAA22052 for ; Tue, 16 Jul 1996 16:57:27 -0500 (CDT) Received: from hplrss.hpl.hp.com by hplms26.hpl.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA045224246; Tue, 16 Jul 1996 14:57:26 -0700 Received: by hplrss.hpl.hp.com (1.37.109.16/15.5+ECS 3.3+HPL1.1) id AA114754292; Tue, 16 Jul 1996 14:58:12 -0700 Date: Tue, 16 Jul 1996 14:58:12 -0700 From: Rob Schreiber Message-Id: <199607162158.AA114754292@hplrss.hpl.hp.com> To: hpff-interpret@cs.rice.edu Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Should the results LB and UB of HPF_ALIGNMENT be one-based? Note that the declared lower bounds of a template are accessible from HPF_TEMPLATE(LB = x, UB = y) Thus, a user can convert from one-based to LB based with no difficulty. The previous standard was, well, ambiguous? Rob --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Wed Jul 17 08:30:58 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id IAA04666 for hpff-interpret-out; Wed, 17 Jul 1996 08:30:58 -0500 (CDT) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id IAA04661 for ; Wed, 17 Jul 1996 08:30:54 -0500 (CDT) From: munroe@think.com Received: from gandalf.think.com (Gandalf.Think.COM [131.239.146.104]) by mail.think.com (8.7.5/m2) with SMTP id JAA06383; Wed, 17 Jul 1996 09:30:48 -0400 (EDT) Received: by gandalf.think.com (4.1/Think-1.3) id AA16345; Wed, 17 Jul 96 09:30:48 EDT Date: Wed, 17 Jul 96 09:30:48 EDT Message-Id: <9607171330.AA16345@gandalf.think.com> To: schreibr@hplrss.hpl.hp.com Cc: hpff-interpret@cs.rice.edu In-Reply-To: Rob Schreiber's message of Tue, 16 Jul 1996 14:58:12 -0700 <199607162158.AA114754292@hplrss.hpl.hp.com> Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Date: Tue, 16 Jul 1996 14:58:12 -0700 From: Rob Schreiber --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Should the results LB and UB of HPF_ALIGNMENT be one-based? Note that the declared lower bounds of a template are accessible from HPF_TEMPLATE(LB = x, UB = y) Thus, a user can convert from one-based to LB based with no difficulty. The previous standard was, well, ambiguous? Rob My reading of this has been that HPF_ALIGNMENT, which "returns information from the variable's point of view" (as opposed to HPF_TEMPLATE, taking the template's point of view and declared subscripts) should return one-based values for the LB and UB arguments: "the first element of the ith axis of ALIGNEE is ultimately aligned to the LB(i)th align-target element along the axis of the align-target associated with the ith axis of ALIGNEE." I.e., where LB returns "1", the beginning of the alignee axis is aligned with the beginning of the target axis, regardless of actual subscripts. Carol --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------