[MPI3 Fortran] Request for a straw vote.

[Bill Long]

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.

Cheers,
Bill




> 
> 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?
> 
> -craig
> 
> 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.
>>
>> Cheers,
>> Bill
>>
>>
>>
>> -- 
>> 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
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
> 

-- 
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