[MPI3 Fortran] Proposing changes to Fortran 2008
donev1 at llnl.gov
Thu Apr 17 14:51:32 CDT 2008
> 2. However, given the performance penalty of the target attribute, it would
> be appropriate for the MPI Forum to request that the Fortran committee try
> to fix this performance problem by changing the standard.
Yes, yes, but with one or more specific proposals on what exactly to do. Just
complaining will not achieve much.
> 3. Regarding the ASYNCHRONOUS extension Hubert suggests.
I like the idea too (I am not sure if we need a new attribute or just an
extension of the existing). But, as I pointed out, we need to exactly specify
what it means. Notably, I think we need some equivalent to WAIT, that
actually poses a barrier to code motion.
Copy in/out is only *part* of the issue with non-blocking communication. What
is needed is:
1) Any pointers that the routine keeps internally should be valid (this
implies no copy in/out should happen). Presently this requires TARGET, one of
the reasons being that pointers can only be pointed to TARGETs to begin with.
Changing this to include ASYNCHRONOUS objects is a possibility but will
require convincing of the J3 committee. I can help with writing the words.
2) Certain optimizations should be disabled, and certain restrictions on the
user imposed to ensure that the compiler is not surprised when something
changes asynchronously. In Fortran 2003, this is accomplished by WAIT, which
poses a barrier to code motion. Also, the restrictions on the user mean that
all other standard optimizations (but not code motion across WAIT) can be
used (including no-aliasing assumptions).
This however does not solve an important problem Craig has complained about:
That of users not remembering to put the ASYNC attribute on their actuals. It
is no different than TARGET, though perhaps with less impact on
optimizations. If we want some kind of compile-time checking, we need to add
it. This would point toward introducing a new attribute rather than adding to
the existing one.
I will also note that the problem of blocking MPI_Send, and in fact all MPI
routines, notably the issues of TKR matching etc., still remain. I believe
they are more important and also much harder to solve than the asynchronous
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
More information about the mpiwg-fortran