<div dir="ltr">do you really believe users are reading specs ? noone cares...</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-13 17:48 GMT+01:00 Jeff Hammond <span dir="ltr"><<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 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>> 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 useful when you don’t want to use replace.  I don’t see anything wrong with it.<br>
>>><br>
>>>> On Mar 10, 2014, at 11:01 PM, Jeff Hammond <<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 and<br>
>>>> did we do it intentionally?  Unless we did so intentionally and<br>
>>>> explicitly, I will argue that the WG screwed up and the info key+val<br>
>>>> 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>> wrote:<br>
>>>>><br>
>>>>> If a hardware can implement MPI_SUM, it should be able to 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 more combinations of operations than just same_op and no_op.  Maybe it’s 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>> 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 <<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 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>> wrote:<br>
>>>>>>><br>
>>>>>>> You can't use replace and sum concurrently at a given target address.<br>
>>>>>>><br>
>>>>>>> ~Jim.<br>
>>>>>>><br>
>>>>>>> On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond <<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 and MPI_SUM<br>
>>>>>>> in accumulate/atomic operations in a standard-compliant way?<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>
>>>>>>><br>
>>>>>>> We discuss this before and the resolution was not satisfying to 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>
<span class="HOEnZb"><font color="#888888"><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></font></span></blockquote></div><br></div>