[Mpi3-rma] draft of a proposal for RMA interfaces
Vinod tipparaju
tipparajuv at hotmail.com
Thu Oct 30 08:57:04 CDT 2008
Hello Howard,
Thanks for the corrections. Req_set_attr and get_attr are _alternatives_ proposed if a new request type were to be used for RMA and RMW operations (only for discussion, in addition to existing MPI request) instead of passing the attributes as a parameter to the MPI call. This new request type is passed to MPI call as a parameter. In this case, the attributes can be set on this new RMA/W Request and this can be used in the RMA/RMW MPI call instead of passing the attributes as a parameter. As you know, the example interfaces are included in the document only to initiate discussions.
I will start two separate discussions from your questions
1)signaling / remote notification of one-sided call
2)proposing interfaces/semantics that can potentially be implemented with point-to-point communication protocols
Thanks,
vinod.
----------------------------------------
> Date: Thu, 16 Oct 2008 14:34:07 -0600
> From: howardp at cray.com
> To: mpi3-rma at lists.mpi-forum.org
> Subject: Re: [Mpi3-rma] draft of a proposal for RMA interfaces
>
> Hello Folks,
>
> Try again with the correction:
>
> original -
>
> the GET transfers from the caller memory(origin) to the target memory;
> PUT transfer data from the target memory to the caller memory
>
> what was probably meant -
>
> the PUT transfers from the caller memory(origin) to the target memory;
> GET transfer data from the target memory to the caller memory
>
> Sorry about that,
>
> Howard
>
> Howard Pritchard wrote:
>
>> 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
>> introduce
>> other problems - like how to 'emulate' this functionality using
>> point-to-point
>> protocols. I believe that any new rma proposal needs to have semantics
>> such that
>> one could base a correct, if low performance, implementation using
>> point-to-point
>> communication protocols.
>>
>> Howard
>>
>> 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" 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
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>>
>>>
>>
>>
>
>
> --
>
> Howard Pritchard
> Cray Inc.
>
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
More information about the mpiwg-rma
mailing list