[MPI3 Fortran] MPI buffer arguments - void and call-by-reference
N.M. Maclaren
nmm1 at cam.ac.uk
Mon Feb 16 15:30:42 CST 2009
On Feb 16 2009, Aleksandar Donev wrote:
>
>> Um. While that is true, to a first approximation, it isn't really. The
>> reason is that all three of those have subtly different constraints on
>> when a compiler must not use copy-in/copy-out and other optimisations.
>
>While this is true, I am really not sure what your message was meant to
>illustrate or clarify...it was confusing even to me (and I am at least
>familiar with the subtleties).
Sorry!
>> The only one of those that ABSOLUTELY blocks copy-in/copy-out and the
>> more-or-less equivalent optimisations is VOLATILE. ASYNCHRONOUS does
>> the least blocking, and is therefore the most efficient.
>
>As far as copy in/out is concerned, VOLATILE and ASYNCHRONOUS are
>identical as far as the standard is concerned. Specifically, a situation
>where copy in/out may be required to be performed is prohibited by
>compile-time constraints. This is not quite identical to saying "though
>shall not perform copy in/out", but the reason the compile-time
>constraints are there is so as to ensure that the argument passing can
>be done by pass-by-reference.
Everything you say is correct, except for the first sentence! The
restrictions on ASYNCHRONOUS make a MAJOR difference. Consider the
following common paradigm:
REAL, ASYNCHRONOUS :: buffer(1000)
CALL Remote_transfer_1(buffer, ...)
CALL Manipulate(buffer)
CALL Remote_transfer_2(buffer, ...)
Where the source of Manipulate is visible to the compiler, and it can
see that there are no external calls or Fortran asynchronous I/O
statements. It can then optimise the call to Manipulate exactly as
if it had no attribute, because the pending state cannot change during
that call. I.e. if there is I/O pending, then the call is illegal;
if there isn't, it needn't worry.
That is NOT true for VOLATILE, where an object may change at any time,
WITHOUT invoking defined behaviour.
>I never objected to using ASYNCHRONOUS to handle non-blocking data
>transfers, as you know well. However, I want to (partially) agree with
>Bill that to truly properly integrate non-blocking operations with the
>Fortran standard *both* the TARGET and the ASYNCHRONOUS attribute are
>required for the buffer, both the dummy *and* the actual. The
>ASYNCHRONOUS attribute does not have guarantees about pointer
>association persisting across argument passing (this is equivalent to
>guarantees against copy in/out)...only TARGET does and it is the
>intended way to allow routines to save pointers to the actual inside a
>routine (which MPI does). At the same time, TARGET does not allow you to
>asynchronously change the value of the target. So both are needed.
I am lost. What do Fortran pointers have to do with MPI?
And, no, the guarantees about pointer association are NOT equivalent
to guarantees against copy in/out - not even remotely. You are assuming
a particular implementation.
>That said, the ASYNCHRONOUS attribute, or a new attribute with similar
>semantics, can be extended to include the effects of pointer association
>argument passing semantics of TARGET.
True.
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
More information about the mpiwg-fortran
mailing list