[MPI3 Fortran] MPI non-blocking transfer

Supalov, Alexander alexander.supalov at intel.com
Wed Feb 11 09:54:58 CST 2009


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: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] 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: donev1 at llnl.gov
>> 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
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
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.





More information about the mpiwg-fortran mailing list