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

Re: [mpiwg-rma] RMA Errata
by William Gropp 25 Jan '15

25 Jan '15

I think this is simply more evidence that the shared memory access should entirely be through the valid language-specified mechanisms, including interaction with other routines and threads that may access the same memory. I most definitely do not think that the load/store access to shared memory is intended to be associated only with memory that was somehow “allocated” by a particular process. I’m not even sure how I’d define that without referring to a particular implementation. Bill On Jan 22, 2015, at 2:30 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> #1 -- The effective target rank of load/store operations is currently not >> defined on shared memory windows. That statement may seem like nonsense. >> However, it is important for situations where load/store operations interact >> with RMA operations that do have an explicit target rank (e.g. >> lock/unlock). I believe this was an oversight, and we intended that the >> load/store operations target the rank that allocated the memory.

1 0

Re: [mpiwg-rma] RMA Errata
by Rolf Rabenseifner 22 Jan '15

22 Jan '15

> #1 -- ... > lock/unlock). I believe this was an oversight, and we intended that the > load/store operations target the rank that allocated the memory. I expect that this is a restriction that is not needed and that does not fit to the idea and reality of shared memory. There should be no difference on p processes between a program that A) allocates with MPI_Win_allocate_shared on each process n bytes, and then all process call MPI_Win_shared_query to get the baseptr of process rank 0 and they use this baseptr for all loads and stores. and B) that allocates on all processes zero Bytes, except on one process where n*p bytes are allocated, and then /as in A) all process call MPI_Win_shared_query to get the baseptr of process rank 0 and they use this baseptr for all loads and stores. Therefore, a better solution is needed. Rolf ----- Original Message ----- > From: "Jim Dinan" <james.dinan(a)gmail.com> > To: "MPI WG Remote Memory Access working group" <mpiwg-rma(a)lists.mpi-forum.org> > Sent: Wednesday, January 21, 2015 6:34:16 PM > Subject: Re: [mpiwg-rma] RMA Errata > > #1 -- The effective target rank of load/store operations is currently not > defined on shared memory windows. That statement may seem like nonsense. > However, it is important for situations where load/store operations interact > with RMA operations that do have an explicit target rank (e.g. > lock/unlock). I believe this was an oversight, and we intended that the > load/store operations target the rank that allocated the memory. > > #2 -- Yes, sounds like we are in agreement > > ~Jim. > > On Mon, Jan 19, 2015 at 2:44 PM, William Gropp < wgropp(a)illinois.edu > wrote: > > > > My preference is that load/store access follows the language rules for shared > memory (I think that is what #1 means). I don’t think anything else is > viable. > > For #2, I think so - again, the issue here is that while Unified promises > “eventually”, real programs usually need some certainty, and for that, an > explicit RMA synchronization is required. > > Bill > > On Jan 19, 2015, at 8:42 AM, Jim Dinan < james.dinan(a)gmail.com > wrote: > > > > > Bumping this thread for progress. Please take a look a the two errata > suggestions that I captured from the December meeting. If folks feel that > this is a good direction, I can convert the informal text below into proper > errata proposals. > > ~Jim. > > On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan < james.dinan(a)gmail.com > wrote: > > > > Hi All, > > Reviewing my notes from the WG meeting, it appears that the following errata > would clarify many misunderstandings of the MPI-3 RMA spec: > > 1) Clarify the target process rank for load/store operations on shared memory > windows. This is needed so that synchronization operations (e.g. > lock/unlock and PSCW) are well defined on shared memory windows. > > 2) Clarify that that while there is one copy of the window data in memory in > the unified memory model, there are still public and private views that must > be synchronized according to the RMA semantics. > > Is there enough support for these that they should be captured for future > discussion? > > Cheers, > ~Jim. > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [mpiwg-rma] RMA Errata
by Jim Dinan 21 Jan '15

21 Jan '15

#1 -- The effective target rank of load/store operations is currently not defined on shared memory windows. That statement may seem like nonsense. However, it is important for situations where load/store operations interact with RMA operations that do have an explicit target rank (e.g. lock/unlock). I believe this was an oversight, and we intended that the load/store operations target the rank that allocated the memory. #2 -- Yes, sounds like we are in agreement ~Jim. On Mon, Jan 19, 2015 at 2:44 PM, William Gropp <wgropp(a)illinois.edu> wrote: > My preference is that load/store access follows the language rules for > shared memory (I think that is what #1 means). I don’t think anything else > is viable. > > For #2, I think so - again, the issue here is that while Unified promises > “eventually”, real programs usually need some certainty, and for that, an > explicit RMA synchronization is required. > > Bill > > On Jan 19, 2015, at 8:42 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > Bumping this thread for progress. Please take a look a the two errata > suggestions that I captured from the December meeting. If folks feel that > this is a good direction, I can convert the informal text below into proper > errata proposals. > > ~Jim. > > On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > >> Hi All, >> >> Reviewing my notes from the WG meeting, it appears that the following >> errata would clarify many misunderstandings of the MPI-3 RMA spec: >> >> 1) Clarify the target process rank for load/store operations on shared >> memory windows. This is needed so that synchronization operations (e.g. >> lock/unlock and PSCW) are well defined on shared memory windows. >> >> 2) Clarify that that while there is one copy of the window data in memory >> in the unified memory model, there are still public and private views that >> must be synchronized according to the RMA semantics. >> >> Is there enough support for these that they should be captured for future >> discussion? >> >> Cheers, >> ~Jim. >> > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >

1 0

Re: [mpiwg-rma] RMA Errata
by William Gropp 19 Jan '15

19 Jan '15

My preference is that load/store access follows the language rules for shared memory (I think that is what #1 means). I don’t think anything else is viable. For #2, I think so - again, the issue here is that while Unified promises “eventually”, real programs usually need some certainty, and for that, an explicit RMA synchronization is required. Bill On Jan 19, 2015, at 8:42 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Bumping this thread for progress. Please take a look a the two errata suggestions that I captured from the December meeting. If folks feel that this is a good direction, I can convert the informal text below into proper errata proposals. > > ~Jim. > > On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi All, > > Reviewing my notes from the WG meeting, it appears that the following errata would clarify many misunderstandings of the MPI-3 RMA spec: > > 1) Clarify the target process rank for load/store operations on shared memory windows. This is needed so that synchronization operations (e.g. lock/unlock and PSCW) are well defined on shared memory windows. > > 2) Clarify that that while there is one copy of the window data in memory in the unified memory model, there are still public and private views that must be synchronized according to the RMA semantics. > > Is there enough support for these that they should be captured for future discussion? > > Cheers, > ~Jim. > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] RMA Errata
by Jeff Hammond 19 Jan '15

19 Jan '15

My parents took the same lazy approach as the MPI Forum regarding asynchronous progress in RMA, so I can only work on the RMA chapter when I am communicating with Forum members via email or telecon. This makes me totally useless but I still tell my friends that I am a high-quality implementation. I fully support #2. I'm sure that #1 makes sense but since PSCW makes my brain hurt and I stopped using point-wise Lock/Unlock as soon as MPI-3 dropped, I haven't thought about it much. Best, Jeff On Mon, Jan 19, 2015 at 6:42 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Bumping this thread for progress. Please take a look a the two errata > suggestions that I captured from the December meeting. If folks feel that > this is a good direction, I can convert the informal text below into proper > errata proposals. > > ~Jim. > > On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: >> >> Hi All, >> >> Reviewing my notes from the WG meeting, it appears that the following >> errata would clarify many misunderstandings of the MPI-3 RMA spec: >> >> 1) Clarify the target process rank for load/store operations on shared >> memory windows. This is needed so that synchronization operations (e.g. >> lock/unlock and PSCW) are well defined on shared memory windows. >> >> 2) Clarify that that while there is one copy of the window data in memory >> in the unified memory model, there are still public and private views that >> must be synchronized according to the RMA semantics. >> >> Is there enough support for these that they should be captured for future >> discussion? >> >> Cheers, >> ~Jim. > > > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] RMA Errata
by Jim Dinan 19 Jan '15

19 Jan '15

Bumping this thread for progress. Please take a look a the two errata suggestions that I captured from the December meeting. If folks feel that this is a good direction, I can convert the informal text below into proper errata proposals. ~Jim. On Wed, Dec 17, 2014 at 6:39 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi All, > > Reviewing my notes from the WG meeting, it appears that the following > errata would clarify many misunderstandings of the MPI-3 RMA spec: > > 1) Clarify the target process rank for load/store operations on shared > memory windows. This is needed so that synchronization operations (e.g. > lock/unlock and PSCW) are well defined on shared memory windows. > > 2) Clarify that that while there is one copy of the window data in memory > in the unified memory model, there are still public and private views that > must be synchronized according to the RMA semantics. > > Is there enough support for these that they should be captured for future > discussion? > > Cheers, > ~Jim. >

1 0