[MPI3 Fortran] Proposing changes to Fortran 2008

[Aleksandar Donev]

Hi,

Craig wrote:
> 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 
issues.

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