[mpiwg-rma] same_op_no_op

[Jeff Hammond]

Do you think a user can determine from MPI-3 that it is an erroneous
program to have accumulate to same loc with diff ops using
_reasonable_ effort?

I think the solution is to strike the "same_op_no_op is default"
sentence from the standard and add a key for same_op_no_op_replace.
The default is the general case where all accumulate operations are
atomic.  In some cases, this may make the best performance hard to
achieve.

I believe nearly all implementations can support same_op_no_op_replace
as efficiently as same_op_no_op.  Cray and IBM should be able to
support the general case just fine, as does the MPICH implementation
using active-messages.

Jeff

On Thu, Mar 13, 2014 at 1:49 PM, Balaji, Pavan <balaji at anl.gov> wrote:
>
> I’m not sure what “it is indirect to the user since the user needs to infer by themselves” means.
>
> As Dave suggested, the user is making an implicit promise that same_op_no_op is used, by default.  With this promise set (either explicitly or implicitly), it is an errorneous program to have accumulate with different ops on the same location.
>
> In MPI-2, it was not erroneous to do so, though the atomicity was not guaranteed so the data might be corrupted.
>
>   — Pavan
>
> On Mar 13, 2014, at 1:07 PM, Jeff Hammond <jeff.science at gmail.com> wrote:
>
>> Indeed Xin is capturing things well.
>>
>> My point is that the user promised nothing when not setting this info key and thus it cannot be erroneous to not abide by it.
>>
>> I've posted my question about whether or not info text is normative on the forum list...
>>
>> Jeff
>>
>> Sent from my iPhone
>>
>>> On Mar 13, 2014, at 1:00 PM, "Zhao, Xin" <xinzhao3 at illinois.edu> wrote:
>>>
>>> For my understanding, the difference between Pavan and Jeff is that, Pavan thinks the default behavior of an info value is actually a standard behavior ("same_op_no_op"), and user should follow that, whereas Jeff thinks it is indirect to the user since user needs to infer by themselves. It should be clearly defined in MPI-3 standard. Sorry if I understand wrongly.
>>>
>>> If I understand correctly, I agree with Jeff.
>>>
>>> Xin
>>> ________________________________________
>>> From: mpiwg-rma [mpiwg-rma-bounces at lists.mpi-forum.org] on behalf of Balaji, Pavan [balaji at anl.gov]
>>> Sent: Thursday, March 13, 2014 12:52 PM
>>> To: MPI WG Remote Memory Access working group
>>> Subject: Re: [mpiwg-rma] same_op_no_op
>>>
>>>> On Mar 13, 2014, at 12:37 PM, Jeff Hammond <jeff.science at gmail.com> wrote:
>>>> How does MPI-3 indicate even indirectly that they are not allowed?  I
>>>> do not believe the standard meets the minimum burden of telling the
>>>> user this and therefore it cannot be inferred.
>>>
>>> I’m still referring to the same sentence we have been discussing:
>>>
>>> "If set to same_op_no_op, then the
>>> implementation will assume that all concurrent accumulate calls to the
>>> same target address will use the same operation or MPI_NO_OP.”
>>>
>>> This means that the user promised that (s)he will only issue the same op or no_op.  If the user breaks this promise, that’s an erroneous program and the MPI implementation is allowed to set the machine room on fire.
>>>
>>> This is the same model we have been using for other info arguments, e.g.,
>>>
>>> "no_locks — if set to true, then the implementation may assume that passive target syn- chronization (i.e., MPI_WIN_LOCK, MPI_LOCK_ALL) will not be used on the given window."
>>>
>>> If the user sets no_locks and uses MPI_WIN_LOCK, it’s an error.
>>>
>>> — Pavan
>>> _______________________________________________
>>> mpiwg-rma mailing list
>>> mpiwg-rma at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>>> _______________________________________________
>>> mpiwg-rma mailing list
>>> mpiwg-rma at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>> _______________________________________________
>> mpiwg-rma mailing list
>> mpiwg-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma



-- 
Jeff Hammond
jeff.science at gmail.com