[Mpi3-rma] RMA WG discussion

[Jim Dinan]

Ah, ok -- yes, you are correct.  Sorry for the misunderstanding on my 
end.  The output buffer must be greater or equal to the size of the 
input buffer in RMA calls (same semantic as send/recv); thus in 
accumulate calls, the basic datatype count in the result buffer can be 
larger than in the input buffer.

Coming back to Hubert's original question, I don't think this is 
adequately covered by the spec.  The target buffer parameters should 
dictate the data that will be placed into the result buffer.  And this 
datatype is allowed to be larger than the origin datatype.

I created a ticket for this issue with suggested text to correct it:

https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355

Thanks,

  ~Jim.

On 12/7/12 1:40 PM, Jeff Hammond wrote:
> Are we talking about the same thing?  I am asserting that it is not
> required that the size of the input and output buffers - regardless of
> how they are represented with datatypes - do not have to be the same
> size, but only need to satisfy the requirement that no buffer overrun
> occurs on either end.
>
> Are you disagreeing with this or are you saying something else?
>
> Jeff
>
> On Fri, Dec 7, 2012 at 1:29 PM, Jim Dinan <dinan at mcs.anl.gov> wrote:
>> This restriction on derived datatypes does not apply to get or put.  It only
>> applies to accumulate operations, and is stated in the 3.0 spec in the first
>> paragraph of page 426 for accumulate, and again in the second paragraph on
>> page 428 for get_accumulate:
>>
>> "Each datatype argument must be a prede fined datatype or a derived
>> datatype, where all basic components are of the same predefined datatype.
>> Both datatype arguments must be constructed from the same predefined
>> datatype."
>>
>>   ~Jim.
>>
>>
>> On 12/7/12 1:13 PM, Jeff Hammond wrote:
>>>>>>
>>>>>> Which count variable defines the number of basic elements to be
>>>>>> returned?
>>>>>>      (result_count, result_type) or (target_count, target_type) ?
>>>>>
>>>>>
>>>>> result_addr is the buffer that is written at the origin so I believe
>>>>> the answer is (result_count, result_type).
>>>>
>>>>
>>>> The number of basic elements needs to be the same across all <count,
>>>> dtype>
>>>> pairs.  The count and datatype for the result buffer determine where
>>>> these
>>>> elements will be in the origin process' memory.
>>>
>>>
>>> This is not what the MPI standard says for MPI_GET and MPI_ACCUMULATE,
>>> as I previously noted, or MPI_PUT, as noted here.  If we're going to
>>> change the semantics in this respect, it needs to be considered
>>> carefully, as it will break backwards compatibility with codes that
>>> assume the same behavior as MPI_RECV, as is stipulated in 11.3.1
>>> (MPI_PUT):
>>>
>>> "The communication must satisfy the same constraints as for a similar
>>> message-passing communication. The target_datatype may not specify
>>> overlapping entries in the target buffer. The message sent must fit,
>>> without truncation, in the target buffer. Furthermore, the target
>>> buffer must fit in the target window or in attached memory in a
>>> dynamic window."
>>>
>>> "Fitting without truncation" is weaker than "needs to be the same".
>>>
>>> Best,
>>>
>>> Jeff
>>>
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
>
>