[MPI3 Fortran] MPI non-blocking transfers
longb at cray.com
Wed Jan 21 12:48:23 CST 2009
Aleksandar Donev wrote:
> Hi Bill,
>> Having the buffer automatically acquire this new attribute is
>> necessary if we want to avoid requiring changes to existing codes.
> This is raising red flags for me. Existing codes are *buggy*, and trying
> to somehow make them conforming and well-behaved seems doomed to me.
Well, that's a point for discussion. Is it a goal to avoid requiring
user source code changes? How important is this issue? This is
something for MPI folks to decide. (This is a pretty basic question
that probably should have been in the original list.)
>>> 2) Most people seem to agree that a data attribute is essential,
>>> and a purely procedure-based solution will not work.
>>> Do you agree with this and, if not, why not?
>> The question hints at a common confusion.
> Please answer the actual question.
I would have if the question were well-formed. It was not. I was just
trying to explain the situation as clearly as possible. I'm looking at
this from a vendor perspective. There are two issues that have separate
solutions. Failing to understand this resulted in some
bandwidth-wasting email recently, and I'm trying to head off more of the
>> Various solutions to
>> this problem have been discussed, most centering on an attribute for
>> dummy arguments
> If so, your answer to question 2 is yes?
>> or coding versions of the MPI routines that accept
>> pass-by-descriptor rather than
>> pass-by-address for the buffer argument.
> Answer to question 2 is no---something new is proposed. Are you
> proposing something new or do you prefer an ASYNCH_EXTERNAL attribute?
I'm open to either approach. This is something the MPI folks need to
decide. Are they willing to have a completely different library
interface for Fortran?
> Or maybe you prefer not to do anything at all (i.e., ignore the issue).
Considering that people have been using MPI with considerable success
for a very long time, that is one option. However, the discussion
presupposes that facilities to reduce possible user problems are
desired, so either you accept the premise or drop out of the discussion.
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the mpiwg-fortran