April 2011 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Van Snyder 19 Apr '11

19 Apr '11

On Tue, 2011-04-19 at 14:53 -0700, Jeff Squyres wrote: > > 1. The signature of MPI_WAIT (and friends) has been around for 18 > years and there's lots of codes using it. It would be fairly > disruptive to change it. > > This may be a weak argument; the other 2 are stronger. > > 2. The request passed to MPI_WAIT may not have a buffer associated > with it. MPI has lots of types of requests, not just non-blocking > point-to-point communication requests. > > 3. Other flavors of MPI_WAIT take arrays of requests (e.g., > MPI_WAITALL). We'd have to pass an array of buffers corresponding to > the array of requests, which would just be plain icky (would you have > to have an array of fortran pointers to refer to all the requisite > buffers?). This is what Fortran generic interfaces, or optional arguments, are for.

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Jeff Squyres 19 Apr '11

19 Apr '11

There's a few reasons we shouldn't add the buffer argument to MPI_WAIT (and friends) -- this has been discussed and discarded many times already. 1. The signature of MPI_WAIT (and friends) has been around for 18 years and there's lots of codes using it. It would be fairly disruptive to change it. This may be a weak argument; the other 2 are stronger. 2. The request passed to MPI_WAIT may not have a buffer associated with it. MPI has lots of types of requests, not just non-blocking point-to-point communication requests. 3. Other flavors of MPI_WAIT take arrays of requests (e.g., MPI_WAITALL). We'd have to pass an array of buffers corresponding to the array of requests, which would just be plain icky (would you have to have an array of fortran pointers to refer to all the requisite buffers?). On Apr 19, 2011, at 5:40 PM, Rasmussen, Craig E wrote: > I know we didn't want to change the API of MPI_Wait because scope of the call to MPI_Wait may not have access to buf. However, your example does have access to buf so why not just overload MPI_Wait to take an additional argument: > > > CALL MPI_Wait(rq, buf1) > CALL MPI_Wait(rq, buf2) ! from an MPI perspective this has no effect as the request has already been satisfied > > Although this could be a little slower than a call to MPI_F_SYNC_REG as the library has to look at the rq argument. > > -craig > > > On Apr 19, 2011, at 2:35 PM, Van Snyder wrote: > >> >> On Thu, 2011-04-14 at 13:03 -0700, Rolf Rabenseifner wrote: >>> With >>> CALL MPI_Irecv(buf, rq) >>> CALL MPI_Wait(rq) >>> CALL MPI_F_SYNC_REG(buf) >>> xnew=buf >>> >>> >>> The content of MPI_F_SYNC_REG is outside the scope of the >>> Fortran optimization. >>> I do not see that the compiler is allowed to move >>> "xnew=buf" before the MPI_Wait statement because >>> "MPI_F_SYNC_REG(buf)" may have modified the content of buf. >>> >>> Therefore the problem is solved. >>> >>> Correct? >>> >>> If not, please can you show a detailed code, how >>> such a compiled code could work and in xnew is at the end >>> ***not*** the value that was stored in buf by MPI_Wait. >> >> If this works, why not change the Fortran -> MPI interface for MPI_Wait >> to include "buf" instead of attaching the TARGET attribute to "buf" and >> hoping the processor will guess that implies that a pointer to "buf" >> might be hiding in "rq"? After all, the processor can see "rq" and its >> type (which might actually be TYPE(*)?), so it might (reasonably) >> conclude from its analysis that "rq" doesn't contain any pointers to >> "buf". >> >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Rasmussen, Craig E 19 Apr '11

19 Apr '11

I know we didn't want to change the API of MPI_Wait because scope of the call to MPI_Wait may not have access to buf. However, your example does have access to buf so why not just overload MPI_Wait to take an additional argument: CALL MPI_Wait(rq, buf1) CALL MPI_Wait(rq, buf2) ! from an MPI perspective this has no effect as the request has already been satisfied Although this could be a little slower than a call to MPI_F_SYNC_REG as the library has to look at the rq argument. -craig On Apr 19, 2011, at 2:35 PM, Van Snyder wrote: > > On Thu, 2011-04-14 at 13:03 -0700, Rolf Rabenseifner wrote: >> With >> CALL MPI_Irecv(buf, rq) >> CALL MPI_Wait(rq) >> CALL MPI_F_SYNC_REG(buf) >> xnew=buf >> >> >> The content of MPI_F_SYNC_REG is outside the scope of the >> Fortran optimization. >> I do not see that the compiler is allowed to move >> "xnew=buf" before the MPI_Wait statement because >> "MPI_F_SYNC_REG(buf)" may have modified the content of buf. >> >> Therefore the problem is solved. >> >> Correct? >> >> If not, please can you show a detailed code, how >> such a compiled code could work and in xnew is at the end >> ***not*** the value that was stored in buf by MPI_Wait. > > If this works, why not change the Fortran -> MPI interface for MPI_Wait > to include "buf" instead of attaching the TARGET attribute to "buf" and > hoping the processor will guess that implies that a pointer to "buf" > might be hiding in "rq"? After all, the processor can see "rq" and its > type (which might actually be TYPE(*)?), so it might (reasonably) > conclude from its analysis that "rq" doesn't contain any pointers to > "buf". > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Van Snyder 19 Apr '11

19 Apr '11

On Thu, 2011-04-14 at 13:03 -0700, Rolf Rabenseifner wrote: > With > CALL MPI_Irecv(buf, rq) > CALL MPI_Wait(rq) > CALL MPI_F_SYNC_REG(buf) > xnew=buf > > > The content of MPI_F_SYNC_REG is outside the scope of the > Fortran optimization. > I do not see that the compiler is allowed to move > "xnew=buf" before the MPI_Wait statement because > "MPI_F_SYNC_REG(buf)" may have modified the content of buf. > > Therefore the problem is solved. > > Correct? > > If not, please can you show a detailed code, how > such a compiled code could work and in xnew is at the end > ***not*** the value that was stored in buf by MPI_Wait. If this works, why not change the Fortran -> MPI interface for MPI_Wait to include "buf" instead of attaching the TARGET attribute to "buf" and hoping the processor will guess that implies that a pointer to "buf" might be hiding in "rq"? After all, the processor can see "rq" and its type (which might actually be TYPE(*)?), so it might (reasonably) conclude from its analysis that "rq" doesn't contain any pointers to "buf".

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by N.M. Maclaren 15 Apr '11

15 Apr '11

On Apr 15 2011, Rolf Rabenseifner wrote: > >Okay, I expect that I now understand: > - You talk about permanent data movements (including > automatic correction of all Fortran pointers to such data, > e.g., for a garbage collection) > and that this is a problem with C based MPI and > C-pointers pointing to buffers of nonblocking MPI > operations. > This problem seems to be unsovled at all. > > How can it really solved? I have no idea whether any compiler currently does it, but that's not the point. What I am saying is that forbidding is is a serious change in the Fortran standard and should not be done in this TR. It can be solved by ensuring that the ASYNCHRONOUS attribute applies to MPI buffers used for non-blocking transfers. Or by inventing another attribute REALLY_ASYNCHRONOUS that does that. > What is the VILE attribute. I did found it anything about it. It was an imaginary attribute, invented by Bill only for the purpose of discussion. Like REALLY_ASYNCHRONOUS above. > - In the past we talked about temporary data movement > (e.g., into a GPU) while nonblocking MPI operations > are pending; this was solved by not using the > buffers (of such nonblocking MPI operations) > in some numerical code. Yes. That is essentially what the ASYNCHRONOUS attribute forbids, subject to the processor-dependent issue we have discussed. > - And I talked in my previous email about > code movements (not data movements) across MPI_Wait calls. > This and only this problem seems to be solved > with the methods I showed. Sort of. I could produce more complicated examples to show that they don't completely solve that problem, either, but I would rather not. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Rolf Rabenseifner 15 Apr '11

15 Apr '11

[John, it looks like that it may be helpful when putting me on the interop-tr(a)j3-fortran.org] Okay, I expect that I now understand: - You talk about permanent data movements (including automatic correction of all Fortran pointers to such data, e.g., for a garbage collection) and that this is a problem with C based MPI and C-pointers pointing to buffers of nonblocking MPI operations. This problem seems to be unsovled at all. How can it really solved? What is the VILE attribute. I did found it anything about it. Is there a combination of MPI+Fortran where the Fortran compiler makes garbage collection and how is it solved there? - In the past we talked about temporary data movement (e.g., into a GPU) while nonblocking MPI operations are pending; this was solved by not using the buffers (of such nonblocking MPI operations) in some numerical code. - And I talked in my previous email about code movements (not data movements) across MPI_Wait calls. This and only this problem seems to be solved with the methods I showed. Do I understand it correctly? Best regards Rolf ----- Original Message ----- > From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "John Reid" <John.Reid(a)stfc.ac.uk>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org>, > interop-tr(a)j3-fortran.org, "Reinhold Bader" <Reinhold.Bader(a)lrz-muenchen.de>, "Craig Rasmussen" <rasmussn(a)lanl.gov>, > "Bill Long" <longb(a)cray.com>, "Jeff Squyres" <jsquyres(a)cisco.com> > Sent: Friday, April 15, 2011 12:12:54 PM > Subject: Re: [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846 > On Apr 14 2011, Rolf Rabenseifner wrote: > > > >> > - TARGET buf > >> > >> Why should that work? Fortran compilers are required to take > >> notice of it only when also operating with POINTER variables. And > >> there is nothing stopping them from moving such data dynamically, > >> if they update all associated pointers. That's old technology, > >> after all. > > > >With > >TARGET buf > >CALL MPI_Irecv(buf, rq) > >CALL MPI_Wait(rq) > >xnew=buf > > I have omitted your discussion because it's separate from my point. > > TARGET will stop code movement as well as ASYNCHRONOUS in a C-like > implementation, but also implies a lot more, and so is a LOT less > efficient. That's not good, for a start. > > My main point was that, in a compiler with a compacting garbage > collector, it allows that to move targets at any time provided that it > also updates its pointers, and that is well-established technology. > C and C++ have implicitly stated that compacting garbage collectors > are not allowed in conforming implementations; Fortran has not and I, > for one, would oppose any move to do so. > > > >> > - Using a call to a dummy routine MPI_F_SYNC_REG(buf) > >> > immediately after MPI_Wait > > > >> > - Storing buf as a module variable or in a common block > > > >Therefore the problem is solved. > > > >Correct? > > > >If not, please can you show a detailed code, how > >such a compiled code could work and in xnew is at the end > >***not*** the value that was stored in buf by MPI_Wait. > > Both of the above fail as soon as those are passed through > intermediate subroutines, as is commonly coded: > > PROGRAM Main > REAL :: buffer(100) > CALL Fred(buffer) > CALL Joe(buffer) > END PROGRAM Main > SUBROUTINE Fred (arg) > REAL :: arg(:) > CALL MPI_Isend(arg,...) > END SUBROUTINE Fred > SUBROUTINE Joe (arg) > REAL :: arg(:) > CALL MPI_Wait(...) > CALL MPI_F_SYNC_REG(arg) > END SUBROUTINE Fred > > This example also addresses Bill's and Van's proposed hacks, which > won't work with this, either. > > > >> >> - (VOALTILE buf, not recommended) > >> > >> Why should that work any better than ASYNCHRONOUS? All it says (in > >> both > >> C and Fortran, incidentally) is "All bets are off - consult your > >> vendor > >> documentation for what might happen." ASYNCHRONOUS has the right > >> semantics. > > > >With > >VOLATILE buf > >CALL MPI_Irecv(buf, rq) > >CALL MPI_Wait(rq) > >xnew=buf > > > >By definition of volatile, the compiler has to guarantee > >that all accesses to buf are done through the memory > >and in the sequence of the application. > > Er, no. Sorry. That is a common myth, but is not so in any of C, C++ > or Fortran. Let's skip the ungodly mess that volatile is in C, and > consider just Fortran. > > > Or have I misunderstood the wording of VOLATILE: Fortran 2008, > > 5.3.19: > > "The VOLATILE attribute specifies that an object may be referenced, > > defined, or become undefined, by means not specified by the > > program." Our > > MPI_Wait is such a "by means not specified by the program." > > You have misunderstood. It is entirely up to the processor what > constitutes "by means not specified by the program". Regrettably, > unlike C (which does THIS aspect better than Fortran), it is not > processor-dependent and therefore need not be documented. > > Until such time as an interpretation decides otherwise, a compiler can > perfectly take the approach that interaction with asynchronous agents > using VOLATILE (and hence example C.2.3) does not take place in 'real > time' but only when an explicit synchronisation function is called. > POSIX and other designs use that model, after all. > > Indeed, some compilers on some systems cannot practically implement > example C.2.3, without turning every access to a VOLATILE object into > a > heavyweight, doubly synchronising subroutine call, and there is > nothing > in the normative wording that requires a compiler to do that. They > might decide not to do so, and would still conform. > > > Fortran 2008, NOTE 5.25: "The Fortran processor should use the most > > recent definition of a volatile object when a value is required. > > Likewise, it should make the most recent Fortran definition > > available. It > > is the programmer's responsibility to manage any interaction with > > non-Fortran processes." > > > >"recent" means, that the sequence must not be modified. > >Otherwise "xnew=buf" does not access the recent definition of buf. > > > >Correct? > > That is non-normative. But, even ignoring that, it says that the > programmer must get the constraints right, and doesn't say what they > are. All it says is that it's the programmer's responsibility to obey > them (which implies finding out what they are!) > > > >If I should be on the list, then it is okay for me. > > That would be good. > > > >On Apr 14 2011, Van Snyder wrote: > > > >Of course, if the actual argument BUF is already a TYPE(*) > >DIMENSION(..) > >dummy argument, or even an assumed-size array, the compiler can't use > >copy-in/copy-out. > > Don't bet on it :-) > > Caller-copying is a well-known compilation technique, for a start, > and there are other ways it can happen. > > >I don't quite understand how ASYNCHRONOUS knows when to stop > >preventing > >code motion. Does it prevent motion of variables with the attribute > >across all calls throughout a scoping unit where they have it, or > >does > >it just prevent code motion across calls in which the asynchronous > >variable is an actual argument? If the former, then the call to > >MPI_F_SYNC_REG isn't necessary. If you want to restrict the range > >where > >ASYNCHRONOUS applies, use a BLOCK construct. > > Basically, it says the compiler must allow for the array being > accessed > at any point, whether or not it is visible in the currently executing > procedure. How it does it is its business! > > I accept that the standard currently implies that is required only for > Fortran asynchronous I/O, but it IS the mechanism designed for this > purpose and VASTLY the simplest and cleanest solution is to use it for > MPI as well. Yes, we could have ASYNCHRONOUS, C_ASYNCHRONOUS, > THREAD_ASYNCHRONOUS and SIGNAL_ASYNCHRONOUS, but that would be getting > silly .... > > I am certainly not denying that clarification would be useful, and > will > try to think of a suitable proposal for the June WG5. While the > wording > is tricky, I doubt that it is extensive and might be solved by adding > a > new processor-dependency - i.e. whether the compiler supports > asynchronous I/O in a companion processor. Or in several other ways. > > > Regards, > Nick Maclaren. -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [MPI3 Fortran] Derived-data, a new/late comment on Fortran WG5 ballot N1846
by Bader, Reinhold 15 Apr '11

15 Apr '11

Hello all, with respect to "Problem A" I have the following (preliminary, given my state of knowledge) opinion: Given the standard's *present* provisions (which makes an explicit formal distinction between SEQUENCE and BIND(C)) an implementation wishing to provide C interop faces the following situation: (1) SEQUENCE types with interoperable ultimate components have the same storage layout as BIND(C) types of the same structure (2) SEQUENCE types do not have the same storage layout as said BIND(C) types In case (1), an implementation may be liberal and accept (like e.g., ifort does) non-conforming code. The latter may involve SEQUENCE actual arguments in BIND(C) calls, or BIND(C) type components in SEQUENCE types, or SEQUENCE components in BIND(C) types. In case (2), the implementation has no choice but to strictly follow the standard's provisions, and reject any attempt to intermix SEQUENCE with BIND(C). I don't know which implementations are of class (2), but any attempt to make use of SEQUENCE legal with BIND(C) via the TR would need to exclude such implementations. The only thing that could conceivably be done for such implementations is to allow SEQUENCE types as (non-VALUE) actual arguments in BIND(C) interfaces, and require that the corresponding C prototype is a void *. This would then on the C side force a programming style like typedef struct { ... } mytype; #ifdef CFI_SEQUENCE_MATCHES_C void foo(mytype *obj) { // reference obj via type components } #else void foo(void *obj) { // reference obj components via accessors which must be written in Fortran } #endif Regards Reinhold > -----Ursprüngliche Nachricht----- > Von: Rolf Rabenseifner [mailto:[email protected]] > Gesendet: Donnerstag, 14. April 2011 16:23 > An: John Reid; interop-tr(a)j3-fortran.org > Cc: Bader, Reinhold; Craig Rasmussen; Bill Long; N.M. Maclaren; Jeff Squyres; > MPI-3 Fortran working group > Betreff: Derived-data, a new/late comment on Fortran WG5 ballot N1846 > > Dear John, dear members of the WG5 and J3 Fortran committees, > > I'm sorry that with this additional comment on problems regarding derived > types, I missed the deadline of the N1846 ballot for the N1845 draft of the TR > 29113 on extensions on Fortran-C interoperability. > > It looks like that there are two problems with derived types and the Fortran- > MPI-compatibility with a background in the Fortran-C-interoperability. > > Problem A: Sequence derived types in the MPI routine > interfaces, which are declared with BIND(C); > this problem occurs with the new MPI handles > and MPI statuses. > > Problem B: Derived type, SEQUENCE derived type, and > BIND(C) derived type as actual user buffers > for TYPE(*),DIMENSION(..) dummy arguments > in BIND(C) MPI routine interfaces. > > Problem C: Based on problem B we have the question > whether the new TYPE(*),DIMENSION(..) dummy > arguments in BIND(C) MPI routine interfaces > really allow all actual arguments that were > possible with implicit interfaces or with > explicit interfaces in combination with > pragmas like > !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf > and > !$PRAGMA IGNORE_TKR buf >

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by N.M. Maclaren 15 Apr '11

15 Apr '11

On Apr 14 2011, Rolf Rabenseifner wrote: > >> > - TARGET buf >> >> Why should that work? Fortran compilers are required to take >> notice of it only when also operating with POINTER variables. And >> there is nothing stopping them from moving such data dynamically, >> if they update all associated pointers. That's old technology, >> after all. > >With >TARGET buf >CALL MPI_Irecv(buf, rq) >CALL MPI_Wait(rq) >xnew=buf I have omitted your discussion because it's separate from my point. TARGET will stop code movement as well as ASYNCHRONOUS in a C-like implementation, but also implies a lot more, and so is a LOT less efficient. That's not good, for a start. My main point was that, in a compiler with a compacting garbage collector, it allows that to move targets at any time provided that it also updates its pointers, and that is well-established technology. C and C++ have implicitly stated that compacting garbage collectors are not allowed in conforming implementations; Fortran has not and I, for one, would oppose any move to do so. >> > - Using a call to a dummy routine MPI_F_SYNC_REG(buf) >> > immediately after MPI_Wait > >> > - Storing buf as a module variable or in a common block > >Therefore the problem is solved. > >Correct? > >If not, please can you show a detailed code, how >such a compiled code could work and in xnew is at the end >***not*** the value that was stored in buf by MPI_Wait. Both of the above fail as soon as those are passed through intermediate subroutines, as is commonly coded: PROGRAM Main REAL :: buffer(100) CALL Fred(buffer) CALL Joe(buffer) END PROGRAM Main SUBROUTINE Fred (arg) REAL :: arg(:) CALL MPI_Isend(arg,...) END SUBROUTINE Fred SUBROUTINE Joe (arg) REAL :: arg(:) CALL MPI_Wait(...) CALL MPI_F_SYNC_REG(arg) END SUBROUTINE Fred This example also addresses Bill's and Van's proposed hacks, which won't work with this, either. >> >> - (VOALTILE buf, not recommended) >> >> Why should that work any better than ASYNCHRONOUS? All it says (in >> both >> C and Fortran, incidentally) is "All bets are off - consult your >> vendor >> documentation for what might happen." ASYNCHRONOUS has the right >> semantics. > >With >VOLATILE buf >CALL MPI_Irecv(buf, rq) >CALL MPI_Wait(rq) >xnew=buf > >By definition of volatile, the compiler has to guarantee >that all accesses to buf are done through the memory >and in the sequence of the application. Er, no. Sorry. That is a common myth, but is not so in any of C, C++ or Fortran. Let's skip the ungodly mess that volatile is in C, and consider just Fortran. > Or have I misunderstood the wording of VOLATILE: Fortran 2008, 5.3.19: > "The VOLATILE attribute specifies that an object may be referenced, > defined, or become undefined, by means not specified by the program." Our > MPI_Wait is such a "by means not specified by the program." You have misunderstood. It is entirely up to the processor what constitutes "by means not specified by the program". Regrettably, unlike C (which does THIS aspect better than Fortran), it is not processor-dependent and therefore need not be documented. Until such time as an interpretation decides otherwise, a compiler can perfectly take the approach that interaction with asynchronous agents using VOLATILE (and hence example C.2.3) does not take place in 'real time' but only when an explicit synchronisation function is called. POSIX and other designs use that model, after all. Indeed, some compilers on some systems cannot practically implement example C.2.3, without turning every access to a VOLATILE object into a heavyweight, doubly synchronising subroutine call, and there is nothing in the normative wording that requires a compiler to do that. They might decide not to do so, and would still conform. > Fortran 2008, NOTE 5.25: "The Fortran processor should use the most > recent definition of a volatile object when a value is required. > Likewise, it should make the most recent Fortran definition available. It > is the programmer's responsibility to manage any interaction with > non-Fortran processes." > >"recent" means, that the sequence must not be modified. >Otherwise "xnew=buf" does not access the recent definition of buf. > >Correct? That is non-normative. But, even ignoring that, it says that the programmer must get the constraints right, and doesn't say what they are. All it says is that it's the programmer's responsibility to obey them (which implies finding out what they are!) >If I should be on the list, then it is okay for me. That would be good. >On Apr 14 2011, Van Snyder wrote: > >Of course, if the actual argument BUF is already a TYPE(*) DIMENSION(..) >dummy argument, or even an assumed-size array, the compiler can't use >copy-in/copy-out. Don't bet on it :-) Caller-copying is a well-known compilation technique, for a start, and there are other ways it can happen. >I don't quite understand how ASYNCHRONOUS knows when to stop preventing >code motion. Does it prevent motion of variables with the attribute >across all calls throughout a scoping unit where they have it, or does >it just prevent code motion across calls in which the asynchronous >variable is an actual argument? If the former, then the call to >MPI_F_SYNC_REG isn't necessary. If you want to restrict the range where >ASYNCHRONOUS applies, use a BLOCK construct. Basically, it says the compiler must allow for the array being accessed at any point, whether or not it is visible in the currently executing procedure. How it does it is its business! I accept that the standard currently implies that is required only for Fortran asynchronous I/O, but it IS the mechanism designed for this purpose and VASTLY the simplest and cleanest solution is to use it for MPI as well. Yes, we could have ASYNCHRONOUS, C_ASYNCHRONOUS, THREAD_ASYNCHRONOUS and SIGNAL_ASYNCHRONOUS, but that would be getting silly .... I am certainly not denying that clarification would be useful, and will try to think of a suitable proposal for the June WG5. While the wording is tricky, I doubt that it is extensive and might be solved by adding a new processor-dependency - i.e. whether the compiler supports asynchronous I/O in a companion processor. Or in several other ways. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Dan Nagle 14 Apr '11

14 Apr '11

Hello, On Apr 14, 2011, at 18:36 , Bill Long wrote: > > An outside-the-standard solution is to have implementations just "know" about MPI_Wait and never move code across a call. Typically this would involve the processor inserting a hidden directive at the call site that suppresses all code motion and forces variables to memory. Equivalent to the MPI standard mandating this for an implementation that claims to support MPI 3.0. At the expense of appearing VILE, how would this work for an arbitrary, user-written asynchronous routine? >From the Fortran standard point of view, we're not designing for MPI only, but we're using MPI as the prime example for any asynchronous routine. This makes for a rather long list of names for the compiler to memorize. :-) And what's a name anyway? We've had dummy arguments forever, use renames for a long time, and now we have function pointers ... -- Cheers! Dan Nagle

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Bill Long 14 Apr '11

14 Apr '11

On 4/14/11 3:03 PM, Rolf Rabenseifner wrote: > ----- Original Message ----- >> From: "N.M. Maclaren"<nmm1(a)cam.ac.uk> >>> From: "Rolf Rabenseifner" > > Nick, > > Let's look at > CALL MPI_Irecv(buf, rq) > CALL MPI_Wait(rq) > xnew=buf > and the new value for buf may be received within the MPI_Wait call. > >>> To summarize, there are several options: >>> - TARGET buf >> >> Why should that work? Fortran compilers are required to take >> notice of it only when also operating with POINTER variables. And >> there is nothing stopping them from moving such data dynamically, >> if they update all associated pointers. That's old technology, >> after all. The normal user mechanism to prevent the reference to buf from moving across the call to MPI_Wait is to put buf in a module. The compiler has to assume that MPI_Wait uses that module and hence could modify buf. The fftw library has similar problems (pointer to "buf" hidden inside "rq") and the normally recommended solution is module variables. In the case of MPI_Wait, I think that a solution that prevented ALL code motion across the call would be acceptable. Currently compiler directives (vendor-dependent) are employed for this. Perhaps a new <prefix> on the subroutine interface. We currently have PURE and IMPURE. We would need a third option that is stronger than IMPURE that would indicate that the subroutine can access and modify variables that are, or are associated with, variables that are not in common, not in a module, and not associated with arguments (i.e. violates the normal Fortran rules). Perhaps the VILE prefix would be appropriate. :) An outside-the-standard solution is to have implementations just "know" about MPI_Wait and never move code across a call. Typically this would involve the processor inserting a hidden directive at the call site that suppresses all code motion and forces variables to memory. Equivalent to the MPI standard mandating this for an implementation that claims to support MPI 3.0. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0