[Mpi3-rma] draft of a proposal for RMA interfaces

Howard Pritchard howardp at cray.com
Thu Oct 16 15:28:30 CDT 2008

Hello Rich,

I meant to respond earlier to Vinod's proposal, sorry for the delay.

First a minor correction in section 5.1. I think the prhase:

/the GET transfers from the caller memory(origin) to the target memory;
PUT transfer data from the target memory to the caller memory/

near the beginning of section.

I think overall the proposal looks interesting. I am somewhat confused
by the MPI_Req_set_attr and MPI_Req_get_attr and how they are suppose
to be used.

The main item that is missing seems to be a method for signaling completion
of an rma operation at a remote process. Is the assumption that if this 
was required,
the remote process would spin wait on a volatile? This would seem to 
other problems - like how to 'emulate' this functionality using 
protocols. I believe that any new rma proposal needs to have semantics 
such that
one could base a correct, if low performance, implementation using 
communication protocols.


Richard Graham wrote:

> Just to get discussion going again. Talking with several folks I have 
> heard several concerns expressed about the proposal. I think it would 
> be good if these (and others) could be raised on the list, so we can 
> start discussion. We can continue this next week in Chicago, but Vinod 
> will not be able to make this meeting, so an e-mail discussion will help.
> Here are the issues I have hear of so far:
> - May not work well on current h/w that is not cache coherent, as it 
> requires a remote thread in this case. I believe this is for the SX 
> series of machines, but Jesper please correct me if I am wrong here. 
> What would be an alternative approach that could provide expected 
> performance on platforms that may require work on the remote end for 
> RMA for correctness, and work well on platforms that do require very 
> specific remote cache management (or other actions) for correctness ?
> - Concern about future high-end platforms, under that assumption that 
> these will not be cache coherent (and will actually have caches – if 
> they don’t this is not a concern), and therefore this proposal is 
> aimed at a short-lived technical capability.
> - What is missing ?
> Rich
> On 9/6/08 6:06 PM, "Vinod tipparaju" <tipparajuv at hotmail.com> wrote:
>     Rajeev,
>     Excellent questions.
>     Technically, yes. However, ARMCI does more thinking about Global
>     Arrays. Particularly because of stride data transfers (multiple
>     stride levels). However, I don't see why we cannot have an
>     alternative port. The only way to know is to prototype the
>     interfaces, implement Global Arrays on top of them and see how the
>     interfaces fare. From superficial thinking, I think they will do
>     just fine ;-). We however cannot say this about all potential
>     implementations.
>     I am not sure if Dan Bonachea is a member of this list. I will
>     write him a message if he isn't.
>     Thanks,
>     Vinod.
>     ----------------------------------------
>> From: thakur at mcs.anl.gov
>> To: mpi3-rma at lists.mpi-forum.org
>> Date: Sat, 6 Sep 2008 16:24:35 -0500
>> Subject: Re: [Mpi3-rma] draft of a proposal for RMA interfaces
>> Vinod,
>> Thanks for the proposal and the nice presentation. A question I had
>> was does it meet the needs of the Global Arrays library? That is,
>     if this
>> were available in MPI today, would you implement Global Arrays
>     with MPI and
>> nothing else (not ARMCI). Similarly, it would be good to run it
>     by Dan
>> Bonachea and see what he has to say regarding implementing UPC.
>> Regards,
>> Rajeev
>>> -----Original Message-----
>>> From: mpi3-rma-bounces at lists.mpi-forum.org
>>> [mailto:mpi3-rma-bounces at lists.mpi-forum.org] On Behalf Of
>>> Vinod tipparaju
>>> Sent: Thursday, September 04, 2008 1:50 AM
>>> To: mpi3-rma at lists.mpi-forum.org
>>> Subject: [Mpi3-rma] draft of a proposal for RMA interfaces
>>> Folks,
>>> Attached is a draft of a new proposal for MPI3-RMA interfaces
>>> for your perusal.
>>> Thanks,
>>> Vinod Tipparaju, ORNL.
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>     _______________________________________________
>     mpi3-rma mailing list
>     mpi3-rma at lists.mpi-forum.org
>     http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>mpi3-rma mailing list
>mpi3-rma at lists.mpi-forum.org


Howard Pritchard 
Cray Inc.

More information about the mpiwg-rma mailing list