From owner-hpff-distribute Mon Jul 8 17:21:43 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id RAA14611 for hpff-distribute-out; Mon, 8 Jul 1996 17:21:43 -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: hpff-distribute: Re: hpff-interpret: Proposal to disallow INHERIT + DISTRIBUTE combination Cc: hpff-interpret@cs.rice.edu, munroe@think.com, hpff-distribute 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. --------------------------------------------------------------------------- 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-distribute-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------