[mpiwg-rma] pirate RMA revisited
Pavan Balaji
balaji at mcs.anl.gov
Thu Oct 31 14:50:20 CDT 2013
Read my email. It didn’t say "I’ll fix it". It said, “don’t screw it up further”.
On Oct 31, 2013, at 1:53 PM, Jeff Hammond <jeff.science at gmail.com> wrote:
> Okay, I have no problem with adding all the pirate RMA functions -
> Rrput, Rraccumulate and Rrrget_accumulate - but I wanted to throw this
> out for discussion. I will create a ticket for this now for tracking
> purposes.
>
> I look forward to your ticket proposing {Scatter,Gather,Allgather}w
> (and the nonblocking and neighborhood variants) to give the MPI
> standard the symmetry it deserves :-)
>
> Jeff
>
> On Thu, Oct 31, 2013 at 1:46 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:
>>
>> I’d be opposed to making the standard more assymetric than what it already is. If you are adding a concept, it should be orthogonal to other functionality. Number of functions is not the criteria; number of concepts is.
>>
>> —- Pavan
>>
>> On Oct 31, 2013, at 1:40 PM, Jeff Hammond <jeff.science at gmail.com> wrote:
>>
>>> We've discussed this at MCS coffee hour but I wanted to post to the WG
>>> regarding the interface issue.
>>>
>>> I understand that the addition of Rrput, Rraccumulate, and
>>> Rrrget_accumulate (Rget is already fully pirated-out) may be
>>> unpalatable to some people.
>>>
>>> I propose that we add _only_ Rrrget_accumulate and tell users to
>>> implement Rrput and Rraccumulate in terms of it using MPI_NO_OP and -
>>> in the first case - MPI_REPLACE. The reasoning is by analogy with
>>> MPI_Alltoallw, which is sufficient to implement MPI_Scatterw, etc.,
>>> albeit inefficiently.
>>>
>>> If we add only Rrrget_accumulate, the loss of efficiency will be
>>> comparatively quite small compared to W-collectives (and certainly not
>>> order-N buffer copies) and should only be due to a few unnecessary
>>> arguments and a couple of branches, which I argue is not sufficient to
>>> motivate the addition of two more functions to the standard. I don't
>>> believe that users want pirate RMA to optimize for latency...
>>>
>>> Is this reasonable? I'm hoping to present this at the Chicago Forum
>>> meeting if the WG believes we are sufficiently converged in our
>>> thinking.
>>>
>>> Thanks,
>>>
>>> Jeff
>>>
>>> On Sat, Jun 15, 2013 at 9:47 AM, Jim Dinan <james.dinan at gmail.com> wrote:
>>>> I think the pirate RMA (separate per operation local/remote completion) idea
>>>> is good. I'm not sure I'm sold on the interface; I'd rather not add so many
>>>> new functions, if there's some other way we could do it. I think we should
>>>> explore the different design options so that we can verify for the Forum
>>>> that we've chosen the best one.
>>>
>>> --
>>> Jeff Hammond
>>> jeff.science at gmail.com
>>> _______________________________________________
>>> mpiwg-rma mailing list
>>> mpiwg-rma at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>>
>> --
>> Pavan Balaji
>> http://www.mcs.anl.gov/~balaji
>>
>> _______________________________________________
>> 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
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
--
Pavan Balaji
http://www.mcs.anl.gov/~balaji
More information about the mpiwg-rma
mailing list