[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