[MPI3 Fortran] Request for a straw vote.
longb at cray.com
Fri Jun 12 11:59:22 CDT 2009
Craig Rasmussen wrote:
> Bill, I'm not sure we are talking about the same thing. I'm assuming
> the choice buffers are represented by DIMENSION(..) so the MPI
> implementation must deal with dope vectors so the issue of
> copy-in/copy-out doesn't come up. This is for any MPI call with a
> "choice buffer" so it doesn't have anything to do MPI_Wait and
> MPI_Request, ...
The dimension(..) specification would be for the wrapper routine which
turns around and calls the lower level C routine currently in the
library. If the array is not contiguous, then either the transfer has
to be done in contiguous chunks, or a local (inside the wrapper)
contiguous copy is made before calling the lower level routine.
Depending on the network characteristics, the later might be more efficient.
The issue of deferred copy-out and temp deletion only affects the
non-blocking routines. All of this would be handled in the wrappers -
unseen by the Fortran user.
> However, there was an earlier discussion raised by Jim about how a
> compiler might want to copy-in/copy-out even if for assumed-shape
> arrays. I think Jim's example had to do with copying vector sized
> objects even though the user is only using a portion of a vector.
> So does DIMENSION(..) restrict copy-in/copy-out?
> On Jun 10, 2009, at 5:40 PM, Bill Long wrote:
>> Craig Rasmussen wrote:
>>> On Jun 10, 2009, at 11:08 AM, Hubert Ritzdorf wrote:
>>>> Craig Rasmussen wrote:
>>>>> 12. Q: Is it an error if the user gives a non-contiguous buffer to
>>>>> a choice argument as it is for C?
>>>>> A: Yes.
>>>>> Unresolved issue: Should the vendor be required to catch the
>>>>> error as always checking the argument is a performance issue
>>>> No; The MPI library has to support this and the MPI forum has to
>>>> define how the
>>>> non-contiguous buffer has to be interpreted.
>>> A note to everyone not at the MPI Forum meeting. There seems to be a
>>> consensus forming around having the MPI implementors doing the
>>> "right" thing with regards to noncontiguous memory.
>> Doing the "right" thing could be simpler if the request argument were
>> a small structure instead of a simple integer. Maybe TYPE MPI_Request.
>> The first component of the struct would be the same as the current
>> integer. That way the address of the struct could be passed to the C
>> routine as is now the case and still work. The other components would
>> be ignored by the lower level routine, and contain the information
>> used to control the copy-in and copy-out processes inside wrappers for
>> the non-blocking routines. The same information is available to the
>> WAIT routine later. There it can be used to decide if a temp copy was
>> allocated (non-NULL address in the temp component), and if a copy-out
>> is needed (non-NULL address for the descriptor for the original actual
>> argument). This allows deferring the copy-out and freeing of the temp
>> to the WAIT routine, solving the classic "copy-in/copy-out" problem
>> that can afflict the non-blocking routines now.
>> 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
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
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