Dear Craig, Thanks. Re 1, how far this "no motion" area will spread? Or more specifically, what kind of code motion will it block? Best regards. Alexander -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Craig Rasmussen Sent: Wednesday, February 11, 2009 1:55 AM To: MPI-3 Fortran working group Cc: William Gropp Subject: Re: [MPI3 Fortran] MPI non-blocking transfer More guidance from J3 Fortran: MPI 2.1 and MPI 2.1+ solution: 1. Put the transfer buffer, buf in a module (or a common block). The compiler must assume that MPI_Wait (or any other procedure) may use the module and write to buf. So code motion is inhibited and buf can't be stored in registers. 2. Declare buf to be volatile. Potential solution(s) for MPI 3.0: Provide a new attribute to the MPI_Wait procedure, let's call it the MPI_NONBLOCKING_ATTRIBUTE. The question is, what should the semantics be? I believe they are: 1. Inhibit code motion around the procedure. 2. Flush all registers before the call. 3. Reload registers after the call. The MPI_NONBLOCKING_ATTRIBUTE will only be in affect at the call site of MPI_Wait. The advantage of an attribute on the procedure is that it can occur in the interface declaration only and users code won't have to change. The is an advantage over BLOCK VOLATILE :: buf call MPI_Wait() END BLOCK In addition Nick believes that VOLATILE can't be used within a block construct in this way. If a new procedure attribute is acceptable, please let me know and I'll submit a J3 paper for consideration this week. Cheers, Craig On Feb 10, 2009, at 3:40 PM, Craig Rasmussen wrote:

On Feb 9, 2009, at 4:06 PM, Aleksandar Donev wrote:

...

On Monday 09 February 2009 14:57, Rolf Rabenseifner wrote:

...

2.3 The existing solution must continue to work, i.e., all existing and correct MPI applications must continue to work. There is no "existing solution", unless you count VOLATILE, which is only standard as of Fortran 2003. As you say,

I would like to reiterate, the MPI Forum has already received guidance from the J3 Fortran committee regarding this issue. The guidance is to use the volatile attribute. I can dig up and resend the official J3 document if you want. I'll also discuss it further this afternoon and tomorrow. But I'm not sure the guidance will change. Somehow the user must give the compiler specific instruction about the usage of the buffer within the Fortran language.

You don't really want Fortran to treat buffers like C does as that will slow down all of your Fortran program.

Cheers, Craig

...

...

2.4 It is not my goal to automatically correct existing wrong MPI applications, i.e., applications without the DD trick the DD thing is a trick (I call them hacks), and actually does not solve the full problem, e.g., Nick has pointed out that problems can occur at the site of the call to MPI_Isend, *not* just the site of the wait (but the cases when it fails are marginal and likely do not happen often enough to notice). Best, Aleks -- Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory High Performance Computational Materials Science and Chemistry E-mail: [email protected] Phone: (925) 424-6816 Fax: (925) 423-0785 Address: P.O.Box 808, L-367, Livermore, CA 94551-9900 Web: http://cherrypit.princeton.edu/donev

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.