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

Re: [mpiwg-rma] Questions about multiple overlapped windows
by Rajeev Thakur 08 Dec '14

08 Dec '14

See the text on lines 38-43 on pg 454 if it helps. See also ln 19-21 on pg 406. Rajeev On Dec 7, 2014, at 6:57 PM, Tatsuya Abe <abetatsuya(a)gmail.com> wrote: > Dear all, > > I am interested in memory consistency models, and studying program > verification with memory consistency models. I started to read MPI > 3.0 document (and Dr. Torsten Hoefler's tutorial slides). > http://www.eurompi2014.org/tutorials/hoefler-advanced-mpi-eurompi14.pdf > > I am wondering if you could give replys to my questions. > I have two questions about multiple overlapped windows: > > 1. (Assume that I create two overlapped windows.) What happens if I > do MPI_Put through one window and MPI_Get through the other window? > > 2. I am wondering what are multiple overlapped windows for. > > > > 1. I can find no description about the first question in MPI 3.0 > document. > > I found Torsten's slides (credit by RMA Working Group, MPI Forum), > which explicitly showed relations between operations (Load, Store, > Get, Put, and Acc) on pp.82--84. But, it seems an explaination > when exactly one window is created, > > For example, page 83 of the slide seems to claim that Put and > Get are allowed when they are not NOVL (non-overlapped) > through one window in separate semantics. > > One of my questions is ``are Put and Get allowed when they are > not NOVL (non-overlapped) through *two* *overlapped* windows > in separate semantics?'' I would like to get such table about > multiple windows. > > > 2. I can find no example about multiple overlapped windows except > Figure 11.1 in MPI 3.0 document. Also, I suspect that Put and Get > are allowed when they are not NOVL (non-overlapped) through two > overlapped windows in separate semantics. > > I cannot come up with any useful example code. Why are multiple > *and* overlapped windows allowed to be active? > > Tatsuya > _______________________________________________ > 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] Questions about multiple overlapped windows
by Jeff Hammond 08 Dec '14

08 Dec '14

On Mon, Dec 8, 2014 at 12:00 AM, Tatsuya Abe <abetatsuya(a)gmail.com> wrote: > Hi Jeff, > > Thank you so much for the reply. > >>A good example is using WIN_ALLOCATE_SHARED to create a shared memory >>window, then passing the resulting buffer into WIN_CREATE. This >>enables a window to support both intranode+interprocess load-store and >>internode RMA. > > Doesn't MPI_Win_allocate_shared support internode RMA, i.e., when I > create a window by using MPI_Win_allocate_shared, cannot I call > MPI_Put/MPI_Get for the window? I haven't found any description about > it in MPI 3.0 yet. WIN_ALLOCATE_SHARED is only valid on an MPI communicator corresponding to a shared memory domain, so no, it does not enable internode RMA unless you can do load-store between nodes. And yes, you can still use RMA function calls to access data in a shared memory window. This is essential, for example, if you want to use atomics, since some languages (e.g. C99) do not have a portable abstraction for these. > I am a little confused. Could you let me ask you more details? > > 1. Do you mean that another window must be created by MPI_Win_create, > in order to use MPI_Put/MPI_Get for a window created by > MPI_Win_allocate_shared? Is this why multiple windows are allowed > to be overlapped? Yes, but only for internode access, as noted above. > 2. Do you mean that the multiple overlapped windows (from > MPI_Win_allocate_shared and MPI_Win_create) become unnecessary in > this example if your ticket #397 passes? My ticket would allow one to use MPI_WIN_ALLOCATE to get both intranode shared memory and internode RMA access. Jeff > Tatsuya > > > > Jeff Hammond <jeff.science(a)gmail.com> wrote: >>On Sun, Dec 7, 2014 at 4:57 PM, Tatsuya Abe <abetatsuya(a)gmail.com> wrote: >>> Dear all, >>> >>> I am interested in memory consistency models, and studying program >>> verification with memory consistency models. I started to read MPI >>> 3.0 document (and Dr. Torsten Hoefler's tutorial slides). >>> http://www.eurompi2014.org/tutorials/hoefler-advanced-mpi-eurompi14.pdf >>> >>> I am wondering if you could give replies to my questions. >>> I have two questions about multiple overlapped windows: >>> >>> 1. (Assume that I create two overlapped windows.) What happens if I >>> do MPI_Put through one window and MPI_Get through the other window? >> >>It depends entirely on the synchronization epochs you use and whether >>the memory model provided is UNIFIED or SEPARATE. >> >>> 2. I am wondering what are multiple overlapped windows for. >> >>To work around obnoxious shortcomings of MPI RMA. >> >>> 1. I can find no description about the first question in MPI 3.0 >>> document. >>> >>> I found Torsten's slides (credit by RMA Working Group, MPI Forum), >>> which explicitly showed relations between operations (Load, Store, >>> Get, Put, and Acc) on pp.82--84. But, it seems an explanation >>> when exactly one window is created, >>> >>> For example, page 83 of the slide seems to claim that Put and >>> Get are allowed when they are not NOVL (non-overlapped) >>> through one window in separate semantics. >>> >>> One of my questions is ``are Put and Get allowed when they are >>> not NOVL (non-overlapped) through *two* *overlapped* windows >>> in separate semantics?'' I would like to get such table about >>> multiple windows. >> >>Within the unified model, one can reason about overlapping windows by >>recognizing that the private windows of the overlapping windows are >>all the same and thus when one synchronizes the public and private >>windows of each window with WIN_SYNC, then all of the public windows >>are the same as well. >> >>> 2. I can find no example about multiple overlapped windows except >>> Figure 11.1 in MPI 3.0 document. Also, I suspect that Put and Get >>> are allowed when they are not NOVL (non-overlapped) through two >>> overlapped windows in separate semantics. >>> >>> I cannot come up with any useful example code. Why are multiple >>> *and* overlapped windows allowed to be active? >> >>A good example is using WIN_ALLOCATE_SHARED to create a shared memory >>window, then passing the resulting buffer into WIN_CREATE. This >>enables a window to support both intranode+interprocess load-store and >>internode RMA. It is useful if one wants to reproduce the behavior of >>e.g. ARMCI in implementing Global Arrays. >> >>The aforementioned motivation will disappear if my ticket >>https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/397 is passed and >>part of MPI-4. >> >>Another reason is to allow ordered and unordered semantics. The >>option to control this happens during window construction and cannot >>be changed. If one wants one semantic (unordered) for performance and >>another (ordered) for correctness, then one needs two windows, one for >>each. >> >>Jeff >> >>-- >>Jeff Hammond >>jeff.science(a)gmail.com >>http://jeffhammond.github.io/ -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] Questions about multiple overlapped windows
by Tatsuya Abe 08 Dec '14

08 Dec '14

Hi Jeff, Thank you so much for the reply. >A good example is using WIN_ALLOCATE_SHARED to create a shared memory >window, then passing the resulting buffer into WIN_CREATE. This >enables a window to support both intranode+interprocess load-store and >internode RMA. Doesn't MPI_Win_allocate_shared support internode RMA, i.e., when I create a window by using MPI_Win_allocate_shared, cannot I call MPI_Put/MPI_Get for the window? I haven't found any description about it in MPI 3.0 yet. I am a little confused. Could you let me ask you more details? 1. Do you mean that another window must be created by MPI_Win_create, in order to use MPI_Put/MPI_Get for a window created by MPI_Win_allocate_shared? Is this why multiple windows are allowed to be overlapped? 2. Do you mean that the multiple overlapped windows (from MPI_Win_allocate_shared and MPI_Win_create) become unnecessary in this exapmple if your ticket #397 passes? Tatsuya Jeff Hammond <jeff.science(a)gmail.com> wrote: >On Sun, Dec 7, 2014 at 4:57 PM, Tatsuya Abe <abetatsuya(a)gmail.com> wrote: >> Dear all, >> >> I am interested in memory consistency models, and studying program >> verification with memory consistency models. I started to read MPI >> 3.0 document (and Dr. Torsten Hoefler's tutorial slides). >> http://www.eurompi2014.org/tutorials/hoefler-advanced-mpi-eurompi14.pdf >> >> I am wondering if you could give replies to my questions. >> I have two questions about multiple overlapped windows: >> >> 1. (Assume that I create two overlapped windows.) What happens if I >> do MPI_Put through one window and MPI_Get through the other window? > >It depends entirely on the synchronization epochs you use and whether >the memory model provided is UNIFIED or SEPARATE. > >> 2. I am wondering what are multiple overlapped windows for. > >To work around obnoxious shortcomings of MPI RMA. > >> 1. I can find no description about the first question in MPI 3.0 >> document. >> >> I found Torsten's slides (credit by RMA Working Group, MPI Forum), >> which explicitly showed relations between operations (Load, Store, >> Get, Put, and Acc) on pp.82--84. But, it seems an explanation >> when exactly one window is created, >> >> For example, page 83 of the slide seems to claim that Put and >> Get are allowed when they are not NOVL (non-overlapped) >> through one window in separate semantics. >> >> One of my questions is ``are Put and Get allowed when they are >> not NOVL (non-overlapped) through *two* *overlapped* windows >> in separate semantics?'' I would like to get such table about >> multiple windows. > >Within the unified model, one can reason about overlapping windows by >recognizing that the private windows of the overlapping windows are >all the same and thus when one synchronizes the public and private >windows of each window with WIN_SYNC, then all of the public windows >are the same as well. > >> 2. I can find no example about multiple overlapped windows except >> Figure 11.1 in MPI 3.0 document. Also, I suspect that Put and Get >> are allowed when they are not NOVL (non-overlapped) through two >> overlapped windows in separate semantics. >> >> I cannot come up with any useful example code. Why are multiple >> *and* overlapped windows allowed to be active? > >A good example is using WIN_ALLOCATE_SHARED to create a shared memory >window, then passing the resulting buffer into WIN_CREATE. This >enables a window to support both intranode+interprocess load-store and >internode RMA. It is useful if one wants to reproduce the behavior of >e.g. ARMCI in implementing Global Arrays. > >The aforementioned motivation will disappear if my ticket >https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/397 is passed and >part of MPI-4. > >Another reason is to allow ordered and unordered semantics. The >option to control this happens during window construction and cannot >be changed. If one wants one semantic (unordered) for performance and >another (ordered) for correctness, then one needs two windows, one for >each. > >Jeff > >-- >Jeff Hammond >jeff.science(a)gmail.com >http://jeffhammond.github.io/

1 0

Re: [mpiwg-rma] Questions about multiple overlapped windows
by Jeff Hammond 07 Dec '14

07 Dec '14

On Sun, Dec 7, 2014 at 4:57 PM, Tatsuya Abe <abetatsuya(a)gmail.com> wrote: > Dear all, > > I am interested in memory consistency models, and studying program > verification with memory consistency models. I started to read MPI > 3.0 document (and Dr. Torsten Hoefler's tutorial slides). > http://www.eurompi2014.org/tutorials/hoefler-advanced-mpi-eurompi14.pdf > > I am wondering if you could give replies to my questions. > I have two questions about multiple overlapped windows: > > 1. (Assume that I create two overlapped windows.) What happens if I > do MPI_Put through one window and MPI_Get through the other window? It depends entirely on the synchronization epochs you use and whether the memory model provided is UNIFIED or SEPARATE. > 2. I am wondering what are multiple overlapped windows for. To work around obnoxious shortcomings of MPI RMA. > 1. I can find no description about the first question in MPI 3.0 > document. > > I found Torsten's slides (credit by RMA Working Group, MPI Forum), > which explicitly showed relations between operations (Load, Store, > Get, Put, and Acc) on pp.82--84. But, it seems an explanation > when exactly one window is created, > > For example, page 83 of the slide seems to claim that Put and > Get are allowed when they are not NOVL (non-overlapped) > through one window in separate semantics. > > One of my questions is ``are Put and Get allowed when they are > not NOVL (non-overlapped) through *two* *overlapped* windows > in separate semantics?'' I would like to get such table about > multiple windows. Within the unified model, one can reason about overlapping windows by recognizing that the private windows of the overlapping windows are all the same and thus when one synchronizes the public and private windows of each window with WIN_SYNC, then all of the public windows are the same as well. > 2. I can find no example about multiple overlapped windows except > Figure 11.1 in MPI 3.0 document. Also, I suspect that Put and Get > are allowed when they are not NOVL (non-overlapped) through two > overlapped windows in separate semantics. > > I cannot come up with any useful example code. Why are multiple > *and* overlapped windows allowed to be active? A good example is using WIN_ALLOCATE_SHARED to create a shared memory window, then passing the resulting buffer into WIN_CREATE. This enables a window to support both intranode+interprocess load-store and internode RMA. It is useful if one wants to reproduce the behavior of e.g. ARMCI in implementing Global Arrays. The aforementioned motivation will disappear if my ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/397 is passed and part of MPI-4. Another reason is to allow ordered and unordered semantics. The option to control this happens during window construction and cannot be changed. If one wants one semantic (unordered) for performance and another (ordered) for correctness, then one needs two windows, one for each. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Questions about multiple overlapped windows
by Tatsuya Abe 07 Dec '14

07 Dec '14

Dear all, I am interested in memory consistency models, and studying program verification with memory consistency models. I started to read MPI 3.0 document (and Dr. Torsten Hoefler's tutorial slides). http://www.eurompi2014.org/tutorials/hoefler-advanced-mpi-eurompi14.pdf I am wondering if you could give replys to my questions. I have two questions about multiple overlapped windows: 1. (Assume that I create two overlapped windows.) What happens if I do MPI_Put through one window and MPI_Get through the other window? 2. I am wondering what are multiple overlapped windows for. 1. I can find no description about the first question in MPI 3.0 document. I found Torsten's slides (credit by RMA Working Group, MPI Forum), which explicitly showed relations between operations (Load, Store, Get, Put, and Acc) on pp.82--84. But, it seems an explaination when exactly one window is created, For example, page 83 of the slide seems to claim that Put and Get are allowed when they are not NOVL (non-overlapped) through one window in separate semantics. One of my questions is ``are Put and Get allowed when they are not NOVL (non-overlapped) through *two* *overlapped* windows in separate semantics?'' I would like to get such table about multiple windows. 2. I can find no example about multiple overlapped windows except Figure 11.1 in MPI 3.0 document. Also, I suspect that Put and Get are allowed when they are not NOVL (non-overlapped) through two overlapped windows in separate semantics. I cannot come up with any useful example code. Why are multiple *and* overlapped windows allowed to be active? Tatsuya

1 0

Ticket #456 - set of slides for the discussion in San Jose on #456 on shared memory synchronization
by Rolf Rabenseifner 07 Dec '14

07 Dec '14

> For ticket 456, the probability is small that it can be put into the > reading/voting process, but it should be mentioned in the agenda for that > case. Dear all, for the RMA WG discussion, I prepared a set of slides with the current status of background on #456 on shared memory synchronization. Best regards Rolf ----- Original Message ----- > From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, November 24, 2014 12:46:48 PM > Subject: Re: [Mpi-forum] Don't forget to register > > Dear Martin, > > please take from the kobe Agenda all errata tickets > to the December agenda: ... > For ticket 456, the probability is small that it can be put into the > reading/voting process, but it should be mentioned in the agenda for that > case. > > Best regards > Rolf -- 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] MPI RMA status summary
by William Gropp 13 Nov '14

13 Nov '14

Thanks. I (and someone else apparently - thanks!) have updated the agenda. Bill On Nov 13, 2014, at 9:38 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi Bill, > > #363 - Closed as withdrawn > #366 - Closed as withdrawn > > #401 - It would be nice to add this as errata in MPI 3.1, if the WG can reach agreement on text in time > #439 - Queued up for WG discussion as an MPI 4.0 proposal. Torsten has a competing proposal that does not have a ticket registered in Trac. I added a link to his slides on #439. > > #460 - Not on your list. This is a proposal for a new info key that was suggested by a user. Should be queued up for WG discussion. > > ~Jim. > > > On Thu, Sep 25, 2014 at 10:19 AM, William Gropp <wgropp(a)illinois.edu> wrote: > I looked through all of the tickets and wrote a summary of the open issues, which I’ve attached. I propose the following: > > Determine which of these issues can be resolved by email. A significant number can probably be closed with no further action. > > For those requiring rework, determine if there is still interest in them, and if not, close them as well. > > For the ones requiring discussion, assign someone to organize a position and discussion. We can schedule telecons to go over those issues. The first item in the list is certainly in this class. > > Comments? > > Bill > > _______________________________________________ > 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] MPI RMA status summary
by Jim Dinan 13 Nov '14

13 Nov '14

Hi Bill, #363 - Closed as withdrawn #366 - Closed as withdrawn #401 - It would be nice to add this as errata in MPI 3.1, if the WG can reach agreement on text in time #439 - Queued up for WG discussion as an MPI 4.0 proposal. Torsten has a competing proposal that does not have a ticket registered in Trac. I added a link to his slides on #439. #460 - Not on your list. This is a proposal for a new info key that was suggested by a user. Should be queued up for WG discussion. ~Jim. On Thu, Sep 25, 2014 at 10:19 AM, William Gropp <wgropp(a)illinois.edu> wrote: > I looked through all of the tickets and wrote a summary of the open > issues, which I’ve attached. I propose the following: > > Determine which of these issues can be resolved by email. A significant > number can probably be closed with no further action. > > For those requiring rework, determine if there is still interest in them, > and if not, close them as well. > > For the ones requiring discussion, assign someone to organize a position > and discussion. We can schedule telecons to go over those issues. The > first item in the list is certainly in this class. > > Comments? > > Bill > > _______________________________________________ > 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 WG discussion 12/2014
by Jeff Hammond 12 Nov '14

12 Nov '14

I don't know what RMA users other than I will expect. But advice to users might be useful to, you know, advise users as to what reasonable expectations are :-) Jeff Sent from my iPhone > On Nov 12, 2014, at 12:59 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > So, users won't expect that the interface can remotely complete a small RMA operation such that it overtakes a previously issued large RMA operation? > >> On Tue, Nov 11, 2014 at 2:02 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> It seems only obvious that remote request completion only makes sense >> for large messages where individual completion makes sense. I can >> think of numerous contexts where it does, especially in the limit of >> not being able to register an infinity of pages. >> >> Jeff >> >> On Tue, Nov 11, 2014 at 5:49 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: >> > I think the argument against was that can be hard to get fine-grain, >> > per-operation remote completion, and harder still to do it efficiently. So, >> > we could end up with an interface that builds a false expectation where >> > users expect overlap that many implementations can't provide. >> > >> > ~Jim. >> > >> > On Thu, Nov 6, 2014 at 2:38 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> >> >> Barrett didn't have a good argument against these functions except >> >> argument count, as I recall. There was some debate as to whether nonblocking >> >> flush was better, albeit in an apples-to-oranges way. >> >> >> >> I think most people are just frustrated with the grossness of the corner >> >> we are painted into with RMA API. Pirate RMA is the natural consequence of >> >> past decisions. The other solution to the application's problem is >> >> overlapping windows, which would be only mildly awful if not for our >> >> inability to support just one memory model. >> >> >> >> Jeff >> >> >> >> Sent from my iPhone >> >> >> >> > On Nov 6, 2014, at 6:47 AM, "Underwood, Keith D" >> >> > <keith.d.underwood(a)intel.com> wrote: >> >> > >> >> > So, what, you're telling me I have to start attending again to give you >> >> > an appropriate amount of difficulty for some of these proposals? >> >> > >> >> >> -----Original Message----- >> >> >> From: mpiwg-rma [mailto:[email protected]] On >> >> >> Behalf Of Jeff Hammond >> >> >> Sent: Tuesday, November 04, 2014 12:39 PM >> >> >> To: MPI WG Remote Memory Access working group >> >> >> Subject: Re: [mpiwg-rma] RMA WG discussion 12/2014 >> >> >> >> >> >> Pirate RMA (remote request completion - cannot remember ticket number) >> >> >> needs to be retired if WG is still not in favor. But then again, >> >> >> Barrett is gone :- >> >> >> ) >> >> >> >> >> >> Nonblocking RMA epochs in your SC14 paper should be discussed. That >> >> >> looks >> >> >> promising. Can you create a ticket for it? >> >> >> >> >> >> Jeff >> >> >> >> >> >> Sent from my iPhone >> >> >> >> >> >>> On Nov 4, 2014, at 5:48 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> >> >>> >> >> >>> The wiki page already has 397 and I added 460. Note also that there >> >> >>> is a list >> >> >> of open tickets on that page; we should try to either adopt or retire >> >> >> the open >> >> >> ones. >> >> >>> >> >> >>> Bill >> >> >>> >> >> >>>> On Nov 4, 2014, at 10:32 AM, Jeff Hammond <jeff.science(a)gmail.com> >> >> >> wrote: >> >> >>>> >> >> >>>> I would like to discuss >> >> >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/397 and the >> >> >>>> closely related >> >> >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/460 in San Jose. >> >> >>>> >> >> >>>> Can we collect the other tickets of interest to people and ask Martin >> >> >>>> for the appropriate allocation of time? >> >> >>>> >> >> >>>> Thanks, >> >> >>>> >> >> >>>> Jeff >> >> >>>> >> >> >>>> -- >> >> >>>> Jeff Hammond >> >> >>>> jeff.science(a)gmail.com >> >> >>>> http://jeffhammond.github.io/ >> >> >>>> _______________________________________________ >> >> >>>> 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 >> >> > _______________________________________________ >> >> > 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 >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> 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 WG discussion 12/2014
by Jim Dinan 12 Nov '14

12 Nov '14

So, users won't expect that the interface can remotely complete a small RMA operation such that it overtakes a previously issued large RMA operation? On Tue, Nov 11, 2014 at 2:02 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > It seems only obvious that remote request completion only makes sense > for large messages where individual completion makes sense. I can > think of numerous contexts where it does, especially in the limit of > not being able to register an infinity of pages. > > Jeff > > On Tue, Nov 11, 2014 at 5:49 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > I think the argument against was that can be hard to get fine-grain, > > per-operation remote completion, and harder still to do it efficiently. > So, > > we could end up with an interface that builds a false expectation where > > users expect overlap that many implementations can't provide. > > > > ~Jim. > > > > On Thu, Nov 6, 2014 at 2:38 AM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > >> > >> Barrett didn't have a good argument against these functions except > >> argument count, as I recall. There was some debate as to whether > nonblocking > >> flush was better, albeit in an apples-to-oranges way. > >> > >> I think most people are just frustrated with the grossness of the corner > >> we are painted into with RMA API. Pirate RMA is the natural consequence > of > >> past decisions. The other solution to the application's problem is > >> overlapping windows, which would be only mildly awful if not for our > >> inability to support just one memory model. > >> > >> Jeff > >> > >> Sent from my iPhone > >> > >> > On Nov 6, 2014, at 6:47 AM, "Underwood, Keith D" > >> > <keith.d.underwood(a)intel.com> wrote: > >> > > >> > So, what, you're telling me I have to start attending again to give > you > >> > an appropriate amount of difficulty for some of these proposals? > >> > > >> >> -----Original Message----- > >> >> From: mpiwg-rma [mailto:[email protected]] On > >> >> Behalf Of Jeff Hammond > >> >> Sent: Tuesday, November 04, 2014 12:39 PM > >> >> To: MPI WG Remote Memory Access working group > >> >> Subject: Re: [mpiwg-rma] RMA WG discussion 12/2014 > >> >> > >> >> Pirate RMA (remote request completion - cannot remember ticket > number) > >> >> needs to be retired if WG is still not in favor. But then again, > >> >> Barrett is gone :- > >> >> ) > >> >> > >> >> Nonblocking RMA epochs in your SC14 paper should be discussed. That > >> >> looks > >> >> promising. Can you create a ticket for it? > >> >> > >> >> Jeff > >> >> > >> >> Sent from my iPhone > >> >> > >> >>> On Nov 4, 2014, at 5:48 PM, William Gropp <wgropp(a)illinois.edu> > wrote: > >> >>> > >> >>> The wiki page already has 397 and I added 460. Note also that there > >> >>> is a list > >> >> of open tickets on that page; we should try to either adopt or retire > >> >> the open > >> >> ones. > >> >>> > >> >>> Bill > >> >>> > >> >>>> On Nov 4, 2014, at 10:32 AM, Jeff Hammond <jeff.science(a)gmail.com> > >> >> wrote: > >> >>>> > >> >>>> I would like to discuss > >> >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/397 and the > >> >>>> closely related > >> >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/460 in San > Jose. > >> >>>> > >> >>>> Can we collect the other tickets of interest to people and ask > Martin > >> >>>> for the appropriate allocation of time? > >> >>>> > >> >>>> Thanks, > >> >>>> > >> >>>> Jeff > >> >>>> > >> >>>> -- > >> >>>> Jeff Hammond > >> >>>> jeff.science(a)gmail.com > >> >>>> http://jeffhammond.github.io/ > >> >>>> _______________________________________________ > >> >>>> 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 > >> > _______________________________________________ > >> > 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 > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >

1 0