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: [email protected] To: [email protected] 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: [email protected] To: [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Vinod tipparaju Sent: Thursday, September 04, 2008 1:50 AM To: [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
------------------------------------------------------------------------
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
--
Howard Pritchard Cray Inc.
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma