[MPI3 Fortran] (j3.2006) (SC22WG5.3921) (SC22WG5.3917) (SC22WG5.3909) [ukfortran] [MPI3 Fortran] MPI non-blocking transfers
nmm1 at cam.ac.uk
Sat Jan 24 06:07:01 CST 2009
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.
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
More information about the mpiwg-fortran