<div dir="ltr">Does same_op_no_op_replace allow MPI_NO_OP, MPI_REPLACE, MPI_SUM, *and* MPI_Compare_and_swap (i.e. to support shmem_*_cswap)?  I don't recall if CAS is semantically a different op, or if it's considered to be a "replace".  I had thought it was considered to be a different op.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 10:11 AM, Jeff Hammond <span dir="ltr"><<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In that case impls can add new info key for same_op_no_op_replace_hardware or something.<br>
<br>
SHMEM only needs same_op_no_op_replace as default but UPC appears to need SUM and XOR to be permitted at the same time to be efficient at the UPC runtime level.<br>
<div class="im HOEnZb"><br>
Jeff<br>
<br>
Sent from my iPhone<br>
<br>
</div><div class="HOEnZb"><div class="h5">> On Mar 14, 2014, at 8:37 AM, "Underwood, Keith D" <<a href="mailto:keith.d.underwood@intel.com">keith.d.underwood@intel.com</a>> wrote:<br>
><br>
> The problem here is that some existing hardware supports some atomic operations.  Multiply is frequently not on that list.  Doing an atomic add on a non-coherent NIC and a multiply somewhere else can be challenging to make correct, much less atomic.  Now, if "all bets are off" in the definition of not atomic (i.e. any interleaving of the two implied load-op-store sequencings is legal), then I would argue that the description you attribute to 2.2 is the better one.<br>

><br>
>> -----Original Message-----<br>
>> From: mpiwg-rma [mailto:<a href="mailto:mpiwg-rma-bounces@lists.mpi-forum.org">mpiwg-rma-bounces@lists.mpi-forum.org</a>] On<br>
>> Behalf Of Balaji, Pavan<br>
>> Sent: Thursday, March 13, 2014 1:02 PM<br>
>> To: MPI WG Remote Memory Access working group<br>
>> Subject: Re: [mpiwg-rma] same_op_no_op<br>
>><br>
>><br>
>> MPI-2.2 says that accumulate with different ops are not atomic.<br>
>><br>
>> MPI-3 says that accumulate with different ops are not allowed (since<br>
>> same_op_no_op is default).<br>
>><br>
>> I think we screwed that up?<br>
>><br>
>>  - Pavan<br>
>><br>
>> On Mar 13, 2014, at 11:48 AM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>> It is extremely difficult to see that this is what the MPI-3 standard says.<br>
>>><br>
>>> First we have this:<br>
>>><br>
>>> "The outcome of concurrent accumulate operations to the same location<br>
>>> with the same predefined datatype is as if the accumulates were done<br>
>>> at that location in some serial order. Additional restrictions on the<br>
>>> operation apply; see the info key accumulate_ops in Section 11.2.1.<br>
>>> Concurrent accumulate operations with different origin and target<br>
>>> pairs are not ordered. Thus, there is no guarantee that the entire<br>
>>> call to an accumulate operation is executed atomically. The effect of<br>
>>> this lack of atomicity is limited: The previous correctness conditions<br>
>>> imply that a location updated by a call to an accumulate operation<br>
>>> cannot be accessed by a load or an RMA call other than accumulate<br>
>>> until the accumulate operation has completed (at the target).<br>
>>> Different interleavings can lead to different results only to the<br>
>>> extent that computer arithmetics are not truly associative or<br>
>>> commutative. The outcome of accumulate operations with overlapping<br>
>>> types of different sizes or target displacements is undefined."<br>
>>> [11.7.1 Atomicity]<br>
>>><br>
>>> Then we have this:<br>
>>><br>
>>> "accumulate_ops - if set to same_op, the implementation will assume<br>
>>> that all concurrent accumulate calls to the same target address will<br>
>>> use the same operation. If set to same_op_no_op, then the<br>
>>> implementation will assume that all concurrent accumulate calls to the<br>
>>> same target address will use the same operation or MPI_NO_OP. This can<br>
>>> eliminate the need to protect access for certain operation types where<br>
>>> the hardware can guarantee atomicity. The default is same_op_no_op."<br>
>>> [11.2.1 Window Creation]<br>
>>><br>
>>> I was not aware that the definition of info keys was normative, given<br>
>>> that implementations are free to ignore them.  Even if info key text<br>
>>> is normative, one has to infer from the fact that same_op_no_op is the<br>
>>> default info behavior - and thus RMA semantic - that accumulate<br>
>>> atomicity is restricted to the case where one uses the same op or noop<br>
>>> but not replace.<br>
>>><br>
>>> The MPI-2.2 spec is unambiguous because it explicitly requires the<br>
>>> same operation in 11.7.1 Atomicity.  This text was removed in MPI-3.0<br>
>>> in favor of the info key text.<br>
>>><br>
>>> Best,<br>
>>><br>
>>> Jeff<br>
>>><br>
>>>> On Tue, Mar 11, 2014 at 12:04 AM, Balaji, Pavan <<a href="mailto:balaji@anl.gov">balaji@anl.gov</a>> wrote:<br>
>>>><br>
>>>> MPI-2 defines atomicity only for the same operation, not any operation<br>
>> for MPI_ACCUMULATE.<br>
>>>><br>
>>>> - Pavan<br>
>>>><br>
>>>> On Mar 10, 2014, at 11:22 PM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>><br>
>> wrote:<br>
>>>><br>
>>>>> So MPI-2 denied compatibility between replace and not-replace?<br>
>>>>><br>
>>>>> Jeff<br>
>>>>><br>
>>>>> Sent from my iPhone<br>
>>>>><br>
>>>>>> On Mar 11, 2014, at 12:06 AM, "Balaji, Pavan" <<a href="mailto:balaji@anl.gov">balaji@anl.gov</a>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> It doesn't break backward compatibility.  The info argument is still<br>
>> useful when you don't want to use replace.  I don't see anything wrong with<br>
>> it.<br>
>>>>>><br>
>>>>>>> On Mar 10, 2014, at 11:01 PM, Jeff Hammond<br>
>> <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> Does this or does this not break BW compatibility w.r.t. MPI-2.2<br>
>>>>>>> and did we do it intentionally?  Unless we did so intentionally<br>
>>>>>>> and explicitly, I will argue that the WG screwed up and the info<br>
>>>>>>> key+val is invalid.<br>
>>>>>>><br>
>>>>>>> Jeff<br>
>>>>>>><br>
>>>>>>>> On Mon, Mar 10, 2014 at 11:03 PM, Balaji, Pavan <<a href="mailto:balaji@anl.gov">balaji@anl.gov</a>><br>
>> wrote:<br>
>>>>>>>><br>
>>>>>>>> If a hardware can implement MPI_SUM, it should be able to<br>
>> implement MPI_SUM with 0 as well.<br>
>>>>>>>><br>
>>>>>>>> But that's not a generic solution.<br>
>>>>>>>><br>
>>>>>>>> Jeff: at some point you were planning to bring in a ticket which does<br>
>> more combinations of operations than just same_op and no_op.  Maybe it's<br>
>> worthwhile bringing that up again?<br>
>>>>>>>><br>
>>>>>>>> - Pavan<br>
>>>>>>>><br>
>>>>>>>>> On Mar 10, 2014, at 9:26 PM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>><br>
>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Maybe there's a loophole that I'm forgetting?<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> On Mon, Mar 10, 2014 at 9:43 PM, Jeff Hammond<br>
>> <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
>>>>>>>>> How the hell can I do GA or SHMEM then? Roll my own mutexes<br>
>> and commit perf-suicide?<br>
>>>>>>>>><br>
>>>>>>>>> Jeff<br>
>>>>>>>>><br>
>>>>>>>>> Sent from my iPhone<br>
>>>>>>>>><br>
>>>>>>>>>> On Mar 10, 2014, at 8:32 PM, Jim Dinan <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>><br>
>> wrote:<br>
>>>>>>>>>><br>
>>>>>>>>>> You can't use replace and sum concurrently at a given target<br>
>> address.<br>
>>>>>>>>>><br>
>>>>>>>>>> ~Jim.<br>
>>>>>>>>>><br>
>>>>>>>>>> On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond<br>
>> <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
>>>>>>>>>> Given the following, how do I use MPI_NO_OP, MPI_REPLACE<br>
>> and<br>
>>>>>>>>>> MPI_SUM in accumulate/atomic operations in a standard-<br>
>> compliant way?<br>
>>>>>>>>>><br>
>>>>>>>>>> accumulate_ops - if set to same_op, the implementation will<br>
>>>>>>>>>> assume that all concurrent accumulate calls to the same target<br>
>>>>>>>>>> address will use the same operation. If set to same_op_no_op,<br>
>>>>>>>>>> then the implementation will assume that all concurrent<br>
>>>>>>>>>> accumulate calls to the same target address will use the same<br>
>>>>>>>>>> operation or MPI_NO_OP. This can eliminate the need to protect<br>
>>>>>>>>>> access for certain operation types where the hardware can<br>
>> guarantee atomicity. The default is same_op_no_op.<br>
>>>>>>>>>><br>
>>>>>>>>>> We discuss this before and the resolution was not satisfying to<br>
>> me.<br>
>>>>>>>>>><br>
>>>>>>>>>> Thanks,<br>
>>>>>>>>>><br>
>>>>>>>>>> Jeff<br>
>>>>>>>>>><br>
>>>>>>>>>> --<br>
>>>>>>>>>> Jeff Hammond<br>
>>>>>>>>>> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>> mpiwg-rma mailing list<br>
>>>>>>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>>>>>>>><br>
>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>> mpiwg-rma mailing list<br>
>>>>>>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>>>>>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> mpiwg-rma mailing list<br>
>>>>>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>>>>>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> mpiwg-rma mailing list<br>
>>>>>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> mpiwg-rma mailing list<br>
>>>>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> Jeff Hammond<br>
>>>>>>> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
>>>>>>> _______________________________________________<br>
>>>>>>> mpiwg-rma mailing list<br>
>>>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> mpiwg-rma mailing list<br>
>>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>>> _______________________________________________<br>
>>>>> mpiwg-rma mailing list<br>
>>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> mpiwg-rma mailing list<br>
>>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Jeff Hammond<br>
>>> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
>>> _______________________________________________<br>
>>> mpiwg-rma mailing list<br>
>>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
>><br>
>> _______________________________________________<br>
>> mpiwg-rma mailing list<br>
>> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
> _______________________________________________<br>
> mpiwg-rma mailing list<br>
> <a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
_______________________________________________<br>
mpiwg-rma mailing list<br>
<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br>
</div></div></blockquote></div><br></div>