- mpiwg-rma - mailman3.cels.anl.gov

Re: [Mpi3-rma] MPI3 RMA Design Goals
by Vinod tipparaju 01 Sep '09

01 Sep '09

You are correct in trying to look at the best possible case and estimating cache-misses/performance-bottlenecks. However, personally don't see any difference between this and shmem. When you cannot really allocate symmetric memory underneath, the amount of bookkeeping is same in both cases. When there is no heterogeneity, the check for this can be disabled at MPI startup. When there is heterogeneity we cannot compare with shmem. I cannot imagine not having symmetric/collective memory object creation to support these RMA interfaces, I think it is a must-have. Sorry I have only been saying we should have these interfaces but haven't given any example for this yet. Given how many times this same issue is coming up, I will do it now. Consider the creation interfaces:Create_memobj(IN user_ptr, IN size, OUT mem_obj)Create_memobj_collective(user_ptr, size, OUT mem_obj)Assign_memobj(IN/OUT mem_obj, IN user_address, IN size) There will be more details on how a mem object which is a result of create_memobj on process A will be exchanged with process B. When it is exchanged explicitly, the heterogeneity information can be created at process B. Now take the example with symmetric object: Process A myptr = allocate(mysize);Create_memobj_collective(myptr,mysize, all_obj); Do all kinds of RMA_Xfers and an example without symmetric object: myptr = allocate(mysize);Create_memobj(myptr,mysize,my_obj); ----exchange objects here----do all kinds of RAM_Xfers In both cases, I can see being able to communicate without any cache misses for mem_obj. Vinod Tipparaju ^ http://ft.ornl.gov/~vinod ^ 1-865-241-1802 From: keith.d.underwood(a)intel.com To: mpi3-rma(a)lists.mpi-forum.org Date: Tue, 1 Sep 2009 09:07:41 -0600 Subject: Re: [Mpi3-rma] MPI3 RMA Design Goals If we take the SINGLE_RMA_INTERFACE_DRAFT_PROPOSAL as an example, and combine it with the draft design goal #1: In order to support RMA to arbitrary locations, no constraints on memory, such as symmetric allocation or collective window creation, can be required We get an interesting view on how difficult it can be to get “close to the metal”. So, for MPI_RMA_xfer, we have to assume that the user has some array of target_mem data items. That means the sequence of steps in user space is: target_mem = ranks[dest]; MPI_RMA_xfer(… target_mem, dest…); If we assume that the message sizes are small and the destinations randomly selected and the machine is large… every access to ranks is a cache miss, and we cannot prevent that by providing fancy hardware. This actually leads me to believe that we may need to reconsider design goal #1, or at least clarify what it means in a way that makes the access more efficient. MPI_RMA_xfer itself is no picnic either. If we take the draft design goal #5: The RMA model must support non-cache-coherent and heterogeneous environments, then MPI is required to maintain a data structure for every rank (ok, it has to do this anyway, but we are trying to get close to the metal) and do a lookup into that data structure with every MPI_RMA_xfer to find out if the target is heterogeneous relative to the target rank – another cache miss. Now, nominally, since this is inside MPI, a lower layer could absorb that check… or, a given MPI could refuse to support heterogeneity or… but, you get the idea. So, we’ve got two cache line loads for every transfer. One in the application and one in the MPI library. One is impossible to move to the hardware and the other is simply very difficult to move. For a contrast, look at SHMEM. Assume homogeneous, only one communicator context, and hardware mapping of ranks to physical locations. A shmem_put() of a short item could literally be turned into a few instructions and a processor store (on machines that supported such things). Personally, I think we will have done well if we can get to the point that a reasonable hardware implementation can get MPI RMA to within 2x of a reasonable SHMEM implementation. I think we have a long way to go to get there. Keith From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Vinod tipparaju Sent: Tuesday, September 01, 2009 5:23 AM To: MPI 3.0 Remote Memory Access working group Subject: Re: [Mpi3-rma] MPI3 RMA Design Goals Good points! RMA interfaces should do nothing to prevent utilizing a high message rate (or low overhead communication) that the underlying hardware may offer. To ensure this happens, there should always be a unrestricted path (lets call it this for now, people have called it a "thin layer", "direct access") to the network. This means, despite the fact the the RMA interface has features that abstract out complexity by providing useful characteristics such as ordering and atomicity, it (the RMA interface) should always have this unrestricted, close to the heart of the hardware, path. To achieve this, the unrestricted path should not require any book keeping (from implementation perspective) in relation to the feature-rich path or vice-versa. I believe this is what we have demonstrated with the example interfaces hence the null set isn't the case here :-). I will distribute an example implementation very soon so people can get a feel. --- Vinod Tipparaju ^ http://ft.ornl.gov/~vinod ^ 1-865-241-1802 > From: keith.d.underwood(a)intel.com > To: mpi3-rma(a)lists.mpi-forum.org > Date: Mon, 31 Aug 2009 16:17:28 -0600 > Subject: Re: [Mpi3-rma] MPI3 RMA Design Goals > > There has been stunning silence since this email, so I will go ahead and toss out a thought... > > In the draft design goals, I don't see two issues that I see as key. The first is "support for high message rate/low overhead communications to random targets". As best I can tell, this is one of the key places were the existing one-sided operations are perceived as falling down for existing customers of SHMEM/PGAS. The second is "elimination of the access epoch requirement". This one may be, um, more controversial, but I believe it is part and parcel with the first one. That is, the first one is not that valuable if the programming model requires an excessive amount of access epoch opens and closes just to force the global visibility of the operations. Unfortunately, the intersection of this solution space with the solution space for the current draft design goal #5 (support non-cache-coherent and heterogeneous environments) may be the null set... I will hold out hope that this isn't the case ;-) > > Keith > > > -----Original Message----- > > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > > bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp > > Sent: Wednesday, August 05, 2009 12:37 PM > > To: mpi3-rma(a)lists.mpi-forum.org > > Subject: [Mpi3-rma] MPI3 RMA Design Goals > > > > I've added versions of the RMA design goals that we discussed at the > > Forum meeting last week to the wiki page for our group ( > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage > > ). This is a draft; lets discuss these. Also, feel free to add to > > the discussion, particularly in the background section. > > > > Bill > > > > William Gropp > > Deputy Director for Research > > Institute for Advanced Computing Applications and Technologies > > Paul and Cynthia Saylor Professor of Computer Science > > University of Illinois Urbana-Champaign > > > > > > > > > > _______________________________________________ > > mpi3-rma mailing list > > mpi3-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] MPI3 RMA Design Goals
by Underwood, Keith D 01 Sep '09

01 Sep '09

If we take the SINGLE_RMA_INTERFACE_DRAFT_PROPOSAL as an example, and combine it with the draft design goal #1: In order to support RMA to arbitrary locations, no constraints on memory, such as symmetric allocation or collective window creation, can be required We get an interesting view on how difficult it can be to get "close to the metal". So, for MPI_RMA_xfer, we have to assume that the user has some array of target_mem data items. That means the sequence of steps in user space is: target_mem = ranks[dest]; MPI_RMA_xfer(... target_mem, dest...); If we assume that the message sizes are small and the destinations randomly selected and the machine is large... every access to ranks is a cache miss, and we cannot prevent that by providing fancy hardware. This actually leads me to believe that we may need to reconsider design goal #1, or at least clarify what it means in a way that makes the access more efficient. MPI_RMA_xfer itself is no picnic either. If we take the draft design goal #5: The RMA model must support non-cache-coherent and heterogeneous environments, then MPI is required to maintain a data structure for every rank (ok, it has to do this anyway, but we are trying to get close to the metal) and do a lookup into that data structure with every MPI_RMA_xfer to find out if the target is heterogeneous relative to the target rank - another cache miss. Now, nominally, since this is inside MPI, a lower layer could absorb that check... or, a given MPI could refuse to support heterogeneity or... but, you get the idea. So, we've got two cache line loads for every transfer. One in the application and one in the MPI library. One is impossible to move to the hardware and the other is simply very difficult to move. For a contrast, look at SHMEM. Assume homogeneous, only one communicator context, and hardware mapping of ranks to physical locations. A shmem_put() of a short item could literally be turned into a few instructions and a processor store (on machines that supported such things). Personally, I think we will have done well if we can get to the point that a reasonable hardware implementation can get MPI RMA to within 2x of a reasonable SHMEM implementation. I think we have a long way to go to get there. Keith From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Vinod tipparaju Sent: Tuesday, September 01, 2009 5:23 AM To: MPI 3.0 Remote Memory Access working group Subject: Re: [Mpi3-rma] MPI3 RMA Design Goals Good points! RMA interfaces should do nothing to prevent utilizing a high message rate (or low overhead communication) that the underlying hardware may offer. To ensure this happens, there should always be a unrestricted path (lets call it this for now, people have called it a "thin layer", "direct access") to the network. This means, despite the fact the the RMA interface has features that abstract out complexity by providing useful characteristics such as ordering and atomicity, it (the RMA interface) should always have this unrestricted, close to the heart of the hardware, path. To achieve this, the unrestricted path should not require any book keeping (from implementation perspective) in relation to the feature-rich path or vice-versa. I believe this is what we have demonstrated with the example interfaces hence the null set isn't the case here :-). I will distribute an example implementation very soon so people can get a feel. --- Vinod Tipparaju ^ http://ft.ornl.gov/~vinod ^ 1-865-241-1802 > From: keith.d.underwood(a)intel.com > To: mpi3-rma(a)lists.mpi-forum.org > Date: Mon, 31 Aug 2009 16:17:28 -0600 > Subject: Re: [Mpi3-rma] MPI3 RMA Design Goals > > There has been stunning silence since this email, so I will go ahead and toss out a thought... > > In the draft design goals, I don't see two issues that I see as key. The first is "support for high message rate/low overhead communications to random targets". As best I can tell, this is one of the key places were the existing one-sided operations are perceived as falling down for existing customers of SHMEM/PGAS. The second is "elimination of the access epoch requirement". This one may be, um, more controversial, but I believe it is part and parcel with the first one. That is, the first one is not that valuable if the programming model requires an excessive amount of access epoch opens and closes just to force the global visibility of the operations. Unfortunately, the intersection of this solution space with the solution space for the current draft design goal #5 (support non-cache-coherent and heterogeneous environments) may be the null set... I will hold out hope that this isn't the case ;-) > > Keith > > > -----Original Message----- > > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > > bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp > > Sent: Wednesday, August 05, 2009 12:37 PM > > To: mpi3-rma(a)lists.mpi-forum.org > > Subject: [Mpi3-rma] MPI3 RMA Design Goals > > > > I've added versions of the RMA design goals that we discussed at the > > Forum meeting last week to the wiki page for our group ( > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage > > ). This is a draft; lets discuss these. Also, feel free to add to > > the discussion, particularly in the background section. > > > > Bill > > > > William Gropp > > Deputy Director for Research > > Institute for Advanced Computing Applications and Technologies > > Paul and Cynthia Saylor Professor of Computer Science > > University of Illinois Urbana-Champaign > > > > > > > > > > _______________________________________________ > > mpi3-rma mailing list > > mpi3-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] MPI3 RMA Design Goals
by Vinod tipparaju 01 Sep '09

01 Sep '09

Thanks, it helps to know daxpy like operations suffices for your use case. I hope to get more input in regards to what operations people are already using with Accumulate. Regarding using target_mem for both local and remote, first let me say that the object has another purpose -- to encapsulate different address spaces (for example your target may be an accelerator of some sort and address space might not mean much on that device). For networks that do require registration, many on-the-fly registration strategies have been proposed. In this case, the MPI keeps track of what has been registered and what has not been registered. Clearly, if the user were to register this memory (and indicate to the implementation that the memory has been registered), implementation can optimize data transfers (this has been discussed in literature too). Using an object such as origin_mem will alleviate this problem. However, requiring doing this for every operation may be an unnecessary programming burden. We can discuss the pros and cons of either in detail. I think what you are asking for is another version of these interfaces that take memory_object+offset as inputs for both target and origin. The reason you are asking for this is that you believe implementations can guarantee zero-copy data transfers (I don't think this can be guaranteed across many systems) and enforce access restrictions you may impose on these memory objects. But first, for that, the memory object will need to encapsulate the access information as well. Correct me if I am missing your intent. Lets discuss this further and let us also not forget networks/systems that didn't need memory to be registered for communication. Vinod Tipparaju ^ http://ft.ornl.gov/~vinod ^ 1-865-241-1802 > Date: Mon, 31 Aug 2009 18:01:08 -0500 > From: jeff.science(a)gmail.com > To: mpi3-rma(a)lists.mpi-forum.org > Subject: Re: [Mpi3-rma] MPI3 RMA Design Goals > > Regarding: "We are still investigating with the input from the user > community to get an idea on if this is necessary or a smaller sub-set > of Reduce Operations are suﬃcient > to be used as OP TYPE values (e.g. RMA ACC SUM, RMA ACC PROD, RMA ACC > LXOR, etc.)." > > What is supported by ARMCI - Put, Get, Acc with multiplicative factor > ala AXPY or min/max-like operations - is sufficient for everything I > can imagine doing with MPI RMA, but perhaps that is because my use of > ARMCI has limited my imagination. > > Regarding "target_mem": > > It appears that there is a special (read: restricted?) interface for > the remote memory segment but nothing locally? Will it be possible to > implement no-copy one-sided on all platforms if the local access is > done not on memory encapsulated by such a special structure but a > plain pointer ("origin_addr")? The DCMF_Put call > <http://dcmf.anl-external.org/docs/api/dcmf/group__PUT.html>, for > example, requires the use of DCMF_Memregion on both the source and the > receiver, so it would appear that either the local registration is > implicit in the "xfer" call or the operation cannot be no-copy. If > local registration is implicit, and this process is non-trivial, then > the latency on "xfer" will be substantial since registered malloc can > take a while on some platforms. It will probably be easier on > implementers to use a more restrictive form of the "xfer" operation > which uses "target_mem"-like restricted memory regions for both the > local and remote processes. It may also be of practical value when > RMA operations are used in a multi-threaded context since the > programmer could impose restrictions upon the local memory region so > that it was accessible by only one thread (e.g. during Acc RMA)or > accessible by all threads (read-only i.e. Put RMA) and unsafe usage > would throw an error rather. > > I am not a computer scientist and apologize for any stupidity > contained in this email. > > Best, > > Jeff > > -- > Jeff Hammond > Argonne Leadership Computing Facility > jhammond(a)mcs.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > http://home.uchicago.edu/~jhammond/ > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] MPI3 RMA Design Goals
by Vinod tipparaju 01 Sep '09

01 Sep '09

Good points! RMA interfaces should do nothing to prevent utilizing a high message rate (or low overhead communication) that the underlying hardware may offer. To ensure this happens, there should always be a unrestricted path (lets call it this for now, people have called it a "thin layer", "direct access") to the network. This means, despite the fact the the RMA interface has features that abstract out complexity by providing useful characteristics such as ordering and atomicity, it (the RMA interface) should always have this unrestricted, close to the heart of the hardware, path. To achieve this, the unrestricted path should not require any book keeping (from implementation perspective) in relation to the feature-rich path or vice-versa. I believe this is what we have demonstrated with the example interfaces hence the null set isn't the case here :-). I will distribute an example implementation very soon so people can get a feel. ---Vinod Tipparaju ^ http://ft.ornl.gov/~vinod ^ 1-865-241-1802 > From: keith.d.underwood(a)intel.com > To: mpi3-rma(a)lists.mpi-forum.org > Date: Mon, 31 Aug 2009 16:17:28 -0600 > Subject: Re: [Mpi3-rma] MPI3 RMA Design Goals > > There has been stunning silence since this email, so I will go ahead and toss out a thought... > > In the draft design goals, I don't see two issues that I see as key. The first is "support for high message rate/low overhead communications to random targets". As best I can tell, this is one of the key places were the existing one-sided operations are perceived as falling down for existing customers of SHMEM/PGAS. The second is "elimination of the access epoch requirement". This one may be, um, more controversial, but I believe it is part and parcel with the first one. That is, the first one is not that valuable if the programming model requires an excessive amount of access epoch opens and closes just to force the global visibility of the operations. Unfortunately, the intersection of this solution space with the solution space for the current draft design goal #5 (support non-cache-coherent and heterogeneous environments) may be the null set... I will hold out hope that this isn't the case ;-) > > Keith > > > -----Original Message----- > > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > > bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp > > Sent: Wednesday, August 05, 2009 12:37 PM > > To: mpi3-rma(a)lists.mpi-forum.org > > Subject: [Mpi3-rma] MPI3 RMA Design Goals > > > > I've added versions of the RMA design goals that we discussed at the > > Forum meeting last week to the wiki page for our group ( > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage > > ). This is a draft; lets discuss these. Also, feel free to add to > > the discussion, particularly in the background section. > > > > Bill > > > > William Gropp > > Deputy Director for Research > > Institute for Advanced Computing Applications and Technologies > > Paul and Cynthia Saylor Professor of Computer Science > > University of Illinois Urbana-Champaign > > > > > > > > > > _______________________________________________ > > mpi3-rma mailing list > > mpi3-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] MPI3 RMA Design Goals
by Jeff Hammond 31 Aug '09

31 Aug '09

Regarding: "We are still investigating with the input from the user community to get an idea on if this is necessary or a smaller sub-set of Reduce Operations are suﬃcient to be used as OP TYPE values (e.g. RMA ACC SUM, RMA ACC PROD, RMA ACC LXOR, etc.)." What is supported by ARMCI - Put, Get, Acc with multiplicative factor ala AXPY or min/max-like operations - is sufficient for everything I can imagine doing with MPI RMA, but perhaps that is because my use of ARMCI has limited my imagination. Regarding "target_mem": It appears that there is a special (read: restricted?) interface for the remote memory segment but nothing locally? Will it be possible to implement no-copy one-sided on all platforms if the local access is done not on memory encapsulated by such a special structure but a plain pointer ("origin_addr")? The DCMF_Put call <http://dcmf.anl-external.org/docs/api/dcmf/group__PUT.html>, for example, requires the use of DCMF_Memregion on both the source and the receiver, so it would appear that either the local registration is implicit in the "xfer" call or the operation cannot be no-copy. If local registration is implicit, and this process is non-trivial, then the latency on "xfer" will be substantial since registered malloc can take a while on some platforms. It will probably be easier on implementers to use a more restrictive form of the "xfer" operation which uses "target_mem"-like restricted memory regions for both the local and remote processes. It may also be of practical value when RMA operations are used in a multi-threaded context since the programmer could impose restrictions upon the local memory region so that it was accessible by only one thread (e.g. during Acc RMA)or accessible by all threads (read-only i.e. Put RMA) and unsafe usage would throw an error rather. I am not a computer scientist and apologize for any stupidity contained in this email. Best, Jeff -- Jeff Hammond Argonne Leadership Computing Facility jhammond(a)mcs.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond http://home.uchicago.edu/~jhammond/

1 0

Re: [Mpi3-rma] MPI3 RMA Design Goals
by Underwood, Keith D 31 Aug '09

31 Aug '09

There has been stunning silence since this email, so I will go ahead and toss out a thought... In the draft design goals, I don't see two issues that I see as key. The first is "support for high message rate/low overhead communications to random targets". As best I can tell, this is one of the key places were the existing one-sided operations are perceived as falling down for existing customers of SHMEM/PGAS. The second is "elimination of the access epoch requirement". This one may be, um, more controversial, but I believe it is part and parcel with the first one. That is, the first one is not that valuable if the programming model requires an excessive amount of access epoch opens and closes just to force the global visibility of the operations. Unfortunately, the intersection of this solution space with the solution space for the current draft design goal #5 (support non-cache-coherent and heterogeneous environments) may be the null set... I will hold out hope that this isn't the case ;-) Keith > -----Original Message----- > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp > Sent: Wednesday, August 05, 2009 12:37 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: [Mpi3-rma] MPI3 RMA Design Goals > > I've added versions of the RMA design goals that we discussed at the > Forum meeting last week to the wiki page for our group ( > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage > ). This is a draft; lets discuss these. Also, feel free to add to > the discussion, particularly in the background section. > > Bill > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] MPI3 RMA Design Goals
by William Gropp 05 Aug '09

05 Aug '09

Good idea. I added a slightly edited version to the wiki. Bill On Aug 5, 2009, at 2:59 PM, Rajeev Thakur wrote: > How about also adding some high-level goals, such as the following. > > "The existing MPI-2 RMA API appears to not meet the needs of > application > programmers and library writers and hence is not widely used. RMA as a > programming paradigm, however, is still valued and needed. The goal of > this subgroup is to fix the existing MPI-2 RMA API or develop a new > API > that library writers (e.g., PGAS and Global Arrays) and application > programmers would actually want to use." > > Rajeev > > > > >> -----Original Message----- >> From: mpi3-rma-bounces(a)lists.mpi-forum.org >> [mailto:[email protected]] On Behalf Of >> William Gropp >> Sent: Wednesday, August 05, 2009 1:37 PM >> To: mpi3-rma(a)lists.mpi-forum.org >> Subject: [Mpi3-rma] MPI3 RMA Design Goals >> >> I've added versions of the RMA design goals that we discussed at the >> Forum meeting last week to the wiki page for our group ( >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage >> ). This is a draft; lets discuss these. Also, feel free >> to add to >> the discussion, particularly in the background section. >> >> Bill >> >> William Gropp >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi3-rma] MPI3 RMA Design Goals
by Rajeev Thakur 05 Aug '09

05 Aug '09

How about also adding some high-level goals, such as the following. "The existing MPI-2 RMA API appears to not meet the needs of application programmers and library writers and hence is not widely used. RMA as a programming paradigm, however, is still valued and needed. The goal of this subgroup is to fix the existing MPI-2 RMA API or develop a new API that library writers (e.g., PGAS and Global Arrays) and application programmers would actually want to use." Rajeev > -----Original Message----- > From: mpi3-rma-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of > William Gropp > Sent: Wednesday, August 05, 2009 1:37 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: [Mpi3-rma] MPI3 RMA Design Goals > > I've added versions of the RMA design goals that we discussed at the > Forum meeting last week to the wiki page for our group ( > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage > ). This is a draft; lets discuss these. Also, feel free > to add to > the discussion, particularly in the background section. > > Bill > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

[Mpi3-rma] MPI3 RMA Design Goals
by William Gropp 05 Aug '09

05 Aug '09

I've added versions of the RMA design goals that we discussed at the Forum meeting last week to the wiki page for our group ( https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/RmaWikiPage ). This is a draft; lets discuss these. Also, feel free to add to the discussion, particularly in the background section. Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

[Mpi3-rma] Ticket #139 on extending MPI 2.1 one-sided communication model
by Jesper Larsson Traeff 04 Mar '09

04 Mar '09

I have made a ticket (139) on some relatively concrete thoughts for mild extensions to the current one-sided model to make it more useful. This may be good to think about (improve/shoot down/get ready for reading) before the next Forum meeting best, Jesper

1 0