[MPI3 Fortran] (j3.2006) (SC22WG5.3921) (SC22WG5.3917) (SC22WG5.3909) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers

[N.M. Maclaren]

On Jan 24 2009, Aleksandar Donev wrote:
>
>> The real question is whether "keep rewriting your code until the 
>> compiler accepts it" is a "solution" to the MPI group.  Realistically, I 
>> think it is the where we'll end up.
>
>As Nick said, no one can fix broken code. If code passes a non-contigous 
>array to an MPI routine that cannot handle that, and copy happens, 
>nothing can fix that but changes to either the code or making a run-time 
>error in an MPI wrapper (since the routine cannot handle it---and a 
>compile-time error is much better than a runtime one). Likely the code 
>would never work correctly to begin with, so it does not sound like a 
>good reason to change MPI to me.

Agreed.  All competent MPI/Fortran courses teach their attendees not to do
that, already, because it doesn't work and can't be made to.

>Remember that ANY of the actually technically-feasible solutions 
>includes adding some attribute on the buffer array. These are not there 
>in existing codes. The codes will need to be changed. Bill has mentioned 
>some sort of implicit acquisition of said attribute but that still 
>smells fishy to me.

Nobody has proposed any way that any of the other 'solutions' would 
percolate up multiple levels of call; a 'solution' that works only for one 
or two levels is no solution at all. If you look at real MPI codes, a large 
proportion have multiple levels between the MPI_Isend and the MPI_Wait.

>The only actual problem is that existing constraints for asynchronous, 
>for a good reason, require that the actual be "simply contiguous". This 
>is more restrictive than "contiguous". There may be codes that rely on 
>"oh it will work cause it is contiguous", but to make it simply 
>contiguous that may require code changes (e.g., adding the CONTIGUOUS 
>attribute here and there). All of these are nontrivial especially for 
>people that do not really understand the meaning of these attributes.

Yes :-(  However, if there are improvements possible, they could and should
also be applied to Fortran asynchronous I/O.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679