From owner-hpff-interpret Thu Dec 21 21:13:11 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id VAA14762 for hpff-interpret-out; Thu, 21 Dec 1995 21:13:11 -0600 (CST) Received: from nrlmry.navy.mil (helium.nrlmry.navy.mil [192.138.87.243]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id VAA14757 for ; Thu, 21 Dec 1995 21:13:07 -0600 (CST) From: norton@nrlmry.navy.mil Received: from norton.nrlmry.navy.mil.nrlmry.navy.mil by nrlmry.navy.mil (4.1/SMI-4.1) id AA28189; Thu, 21 Dec 95 19:13:12 PST Received: by norton.nrlmry.navy.mil.nrlmry.navy.mil (SMI-8.6/SMI-SVR4) id TAA13159; Thu, 21 Dec 1995 19:11:48 -0800 Date: Thu, 21 Dec 1995 19:11:48 -0800 Message-Id: <199512220311.TAA13159@norton.nrlmry.navy.mil.nrlmry.navy.mil> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: INDEPENDENT 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. --------------------------------------------------------------------------- Given a data layout: real, dimension(25) :: a,b,c !HPF$ DISTRIBUTE a (*) !HPF$ DISTRIBUTE b (*) !HPF$ DISTRIBUTE c (*) Is the following legal syntax and could an implementor choose to compute this in parallel even though the arrays have been declared "serial"? !HPF$ INDEPENDENT do i=1,25 a(i) = b(i) + c(i) enddo [The motivation for the inquiry - it would be nice if the INDEPENDENT directive would be honored over the DISTRIBUTE directive to parallelize execution on an SMP type system if the cost of data motion on the bus is cheap, but the same code would honor the DISTRIBUTE directive over the INDEPENDENT directive to run code serially on a distributed memory system where the cost of data motion over the network may be expensive. Realizing that that is a bit much to ask of implementors, it would be nice to know if there are any thoughts on a defined behavior for this combination of directives.] thanks -dave --------------------------------------------------------------------------- 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 Fri Dec 22 10:57:44 1995 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id KAA26634 for hpff-interpret-out; Fri, 22 Dec 1995 10:57:44 -0600 (CST) Received: from [128.42.5.152] (pasyn-24.rice.edu [128.42.5.152]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id KAA26620; Fri, 22 Dec 1995 10:57:36 -0600 (CST) Date: Fri, 22 Dec 1995 10:57:36 -0600 (CST) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: norton@nrlmry.navy.mil, hpff-interpret From: chk@cs.rice.edu (Chuck Koelbel) Subject: Re: hpff-interpret: INDEPENDENT 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. --------------------------------------------------------------------------- >Given a data layout: > > real, dimension(25) :: a,b,c >!HPF$ DISTRIBUTE a (*) >!HPF$ DISTRIBUTE b (*) >!HPF$ DISTRIBUTE c (*) > > >Is the following legal syntax and could an implementor choose to >compute this in parallel even though the arrays have been declared >"serial"? > >!HPF$ INDEPENDENT > do i=1,25 > a(i) = b(i) + c(i) > enddo > >[The motivation for the inquiry - it would be nice if the INDEPENDENT >directive would be honored over the DISTRIBUTE directive to >parallelize execution on an SMP type system if the cost of data motion >on the bus is cheap, but the same code would honor the DISTRIBUTE >directive over the INDEPENDENT directive to run code serially on a >distributed memory system where the cost of data motion over the >network may be expensive. Realizing that that is a bit much to ask of >implementors, it would be nice to know if there are any thoughts on >a defined behavior for this combination of directives.] > >thanks >-dave The quick answer: Yes, the syntax is legal. Yes, this is a correct use of INDEPENDENT. Yes, a compiler could implement INDEPENDENT as you suggest. No, it is not written in stone that the compiler must implement INDEPENDENT this way. A bit of philosophy: INDEPENDENT makes a statement about side effects of loop iterations (i.e. it states that there aren't any side effects on other iterations). There is language in the specification to the effect that "The compiler can use this information in any way that it sees fit." With that in mind, I hope it's clear that INDEPENDENT and DISTRIBUTE are basically orthogonal constructs; you can mix and match them as needed. The implementation you suggest is (IMHO) an excellent compiler heuristic for handling INDEPENDENT. I hope that SMP vendors are listening to you. However, HPF bends over backwards to keep from requiring any particular implementation. (Similarly, you won't find many implementation hints in the F90 standard, or most other language definitions.) In part, this is because HPF is supposed to run on many platforms which may need different implementations. In part, this is because we don't want HPF to be locked into an old implementation technique if new research comes along. And, of course, it's hard enough to get agreement on a language without debating "should this be implemented the APR way or the PGI way?" So, HPF doesn't define a "behavior" for INDEPENDENT, in the sense that it is legal for a given compiler to ignore the directive (in some cases, or in all cases). Or the compiler can use the INDEPENDENT information in ways you haven't thought of (for example, INDEPENDENT implies you can turn off cache coherency protocols for data assigned in the loop, if you turn coherence back on at the right time). I argue this is what you want for portable programs, where each platform can treat INDEPENDENT the way that it needs to. If you really want/need to define a program's behavior, you may want to look at the ON HOME directive being discussed in HPF 2. (I promise, the revised proposal is coming!) Chuck --------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------