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

Re: [mpiwg-rma] Draft agenda for MPI RMA WG discussions next week
by Jim Dinan 29 May '15

29 May '15

I'll also do the same. Unfortunately, I won't be able to attend this Forum meeting because of family obligations, but I'll do my best to organize my tickets so they can be discussed in my absence. ~Jim. On Wed, May 27, 2015 at 12:42 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Thanks. I will update all of my RMA tickets by the end of the week, > if necessary. > > Jeff > > On Tue, May 26, 2015 at 3:30 PM, William Gropp <wgropp(a)illinois.edu> > wrote: > > I’ve updated the agenda items for the MPI RMA Working group discussions > next > > week on the usual page, > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi3-rma-agenda . > Let me > > know, or directly edit the page, if you have any changes. > > > > Bill > > > > > > _______________________________________________ > > 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

Re: [mpiwg-rma] Draft agenda for MPI RMA WG discussions next week
by Jeff Hammond 27 May '15

27 May '15

Thanks. I will update all of my RMA tickets by the end of the week, if necessary. Jeff On Tue, May 26, 2015 at 3:30 PM, William Gropp <wgropp(a)illinois.edu> wrote: > I’ve updated the agenda items for the MPI RMA Working group discussions next > week on the usual page, > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi3-rma-agenda . Let me > know, or directly edit the page, if you have any changes. > > Bill > > > _______________________________________________ > 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

Draft agenda for MPI RMA WG discussions next week
by William Gropp 26 May '15

26 May '15

I’ve updated the agenda items for the MPI RMA Working group discussions next week on the usual page, https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi3-rma-agenda . Let me know, or directly edit the page, if you have any changes. Bill

1 0

Re: [mpiwg-rma] Draft MPI RMA chapter update
by William Gropp 07 May '15

07 May '15

Correct. Thanks. Bill On May 7, 2015, at 9:36 AM, Kawashima, Takahiro <t-kawashima(a)jp.fujitsu.com> wrote: > On page 46 line 16 (cited below), 'MPI_Win_lock' should be upper-case 'MPI_WIN_LOCK'. > > Starts an RMA access epoch. The window at the process with rank rank can be accessed > by RMA operations on win during that epoch. Multiple RMA access epochs (with calls > to MPI_Win_lock) can occur simultaneously; however, each access epoch much target a > different process. > > Takahiro Kawashima, > Fujitsu > >> Attached is an update to the RMA chapter. This does not introduce or change any features; it simply corrects some language and appearance (spacing) and removes a few errors in the text. New text is in red; deletions are not shown. Also attached is the svn diff for these items. The chapter authors reached consensus on these; we have a list of things that the RMA group should discuss at the next meeting. Also note, because of the short time left, the other chapter authors have not had a chance to review these - any errors are mine. >> >> If you find a problem with these updates (not just awkward wording, or a new problem), respond to the whole group so that we can discuss it as quickly as possible. >> >> 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] Draft MPI RMA chapter update
by Kawashima, Takahiro 07 May '15

07 May '15

On page 46 line 16 (cited below), 'MPI_Win_lock' should be upper-case 'MPI_WIN_LOCK'. Starts an RMA access epoch. The window at the process with rank rank can be accessed by RMA operations on win during that epoch. Multiple RMA access epochs (with calls to MPI_Win_lock) can occur simultaneously; however, each access epoch much target a different process. Takahiro Kawashima, Fujitsu > Attached is an update to the RMA chapter. This does not introduce or change any features; it simply corrects some language and appearance (spacing) and removes a few errors in the text. New text is in red; deletions are not shown. Also attached is the svn diff for these items. The chapter authors reached consensus on these; we have a list of things that the RMA group should discuss at the next meeting. Also note, because of the short time left, the other chapter authors have not had a chance to review these - any errors are mine. > > If you find a problem with these updates (not just awkward wording, or a new problem), respond to the whole group so that we can discuss it as quickly as possible. > > Bill

1 0

Re: [mpiwg-rma] Draft MPI RMA chapter update
by William Gropp 04 May '15

04 May '15

Thanks. I’ve fixed the “much”. As Rajeev notes, the only changes are the text in red, and this was just fixing typos and made no semantic changes. Bill On May 4, 2015, at 12:24 AM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: >> If we are going to fix "It is often useful in a put operation to >> combine the data moved to the target process with the data that >> resides at that process, rather than replacing it." > > The only change made was > "rather then (typo) replacing the data" => "rather than replacing it" > >> page 46 line 10-11: "each access epoch much target a different >> process." s/much/must/ > > Good catch. That is a new error introduced in the editing. > >> The text added on page 47 "Completes an RMA access epoch started by a >> call to MPI_WIN_LOCK on window win." and "Completes a shared RMA >> access epoch started by a call to MPI_WIN_LOCK_ALL on window win." >> appear to add a semantic restriction not present in MPI 3.0, > > The only change made was that the parameters to Win_lock(...) and lock_all(...) were omitted. They were present earlier. > > Rajeev > > On May 3, 2015, at 4:53 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >> (1) >> >> If we are going to fix "It is often useful in a put operation to >> combine the data moved to the target process with the data that >> resides at that process, rather than replacing it." in 11.3.4, we >> should go all the way to >> >> "It is often useful in a remote update operation to combine the data >> moved to the target process with the data that resides at that >> process, rather than replacing it." >> >> because "put" is not a superset of MPI_Put and MPI_Accumulate. >> >> (2) >> >> page 46 line 10-11: "each access epoch much target a different >> process." s/much/must/ >> >> (3) >> >> The text added on page 47 "Completes an RMA access epoch started by a >> call to MPI_WIN_LOCK on window win." and "Completes a shared RMA >> access epoch started by a call to MPI_WIN_LOCK_ALL on window win." >> appear to add a semantic restriction not present in MPI 3.0, unless it >> says somewhere else that LOCK_ALL must be matched by UNLOCK_ALL and >> not by the appropriate number of UNLOCK calls, and vice versa. If it >> says this, I can't remember where it is. >> >> And if one wants to add this text, it would seem symmetric to specify >> that FLUSH_ALL and FLUSH_LOCAL_ALL should be associated with LOCK_ALL >> epochs and not N*LOCK epochs. However, I do not think this is >> something we should do, and thus I infer we want to be less specific >> in the previous instance, meaning, we should use >> >> "Completes an RMA access epoch started by a call to MPI_WIN_LOCK or >> MPI_WIN_LOCK_ALL on window win." >> >> for both cases on page 47. >> >> >> >> Jeff >> >> On Sun, May 3, 2015 at 8:33 AM, William Gropp <wgropp(a)illinois.edu> wrote: >>> Attached is an update to the RMA chapter. This does not introduce or change any features; it simply corrects some language and appearance (spacing) and removes a few errors in the text. New text is in red; deletions are not shown. Also attached is the svn diff for these items. The chapter authors reached consensus on these; we have a list of things that the RMA group should discuss at the next meeting. Also note, because of the short time left, the other chapter authors have not had a chance to review these - any errors are mine. >>> >>> If you find a problem with these updates (not just awkward wording, or a new problem), respond to the whole group so that we can discuss it as quickly as possible. >>> >>> Bill >>> >>> >>> _______________________________________________ >>> 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] Draft MPI RMA chapter update
by Thakur, Rajeev 03 May '15

03 May '15

> If we are going to fix "It is often useful in a put operation to > combine the data moved to the target process with the data that > resides at that process, rather than replacing it." The only change made was "rather then (typo) replacing the data" => "rather than replacing it" > page 46 line 10-11: "each access epoch much target a different > process." s/much/must/ Good catch. That is a new error introduced in the editing. > The text added on page 47 "Completes an RMA access epoch started by a > call to MPI_WIN_LOCK on window win." and "Completes a shared RMA > access epoch started by a call to MPI_WIN_LOCK_ALL on window win." > appear to add a semantic restriction not present in MPI 3.0, The only change made was that the parameters to Win_lock(...) and lock_all(...) were omitted. They were present earlier. Rajeev On May 3, 2015, at 4:53 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > (1) > > If we are going to fix "It is often useful in a put operation to > combine the data moved to the target process with the data that > resides at that process, rather than replacing it." in 11.3.4, we > should go all the way to > > "It is often useful in a remote update operation to combine the data > moved to the target process with the data that resides at that > process, rather than replacing it." > > because "put" is not a superset of MPI_Put and MPI_Accumulate. > > (2) > > page 46 line 10-11: "each access epoch much target a different > process." s/much/must/ > > (3) > > The text added on page 47 "Completes an RMA access epoch started by a > call to MPI_WIN_LOCK on window win." and "Completes a shared RMA > access epoch started by a call to MPI_WIN_LOCK_ALL on window win." > appear to add a semantic restriction not present in MPI 3.0, unless it > says somewhere else that LOCK_ALL must be matched by UNLOCK_ALL and > not by the appropriate number of UNLOCK calls, and vice versa. If it > says this, I can't remember where it is. > > And if one wants to add this text, it would seem symmetric to specify > that FLUSH_ALL and FLUSH_LOCAL_ALL should be associated with LOCK_ALL > epochs and not N*LOCK epochs. However, I do not think this is > something we should do, and thus I infer we want to be less specific > in the previous instance, meaning, we should use > > "Completes an RMA access epoch started by a call to MPI_WIN_LOCK or > MPI_WIN_LOCK_ALL on window win." > > for both cases on page 47. > > > > Jeff > > On Sun, May 3, 2015 at 8:33 AM, William Gropp <wgropp(a)illinois.edu> wrote: >> Attached is an update to the RMA chapter. This does not introduce or change any features; it simply corrects some language and appearance (spacing) and removes a few errors in the text. New text is in red; deletions are not shown. Also attached is the svn diff for these items. The chapter authors reached consensus on these; we have a list of things that the RMA group should discuss at the next meeting. Also note, because of the short time left, the other chapter authors have not had a chance to review these - any errors are mine. >> >> If you find a problem with these updates (not just awkward wording, or a new problem), respond to the whole group so that we can discuss it as quickly as possible. >> >> Bill >> >> >> _______________________________________________ >> 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

Re: [mpiwg-rma] Draft MPI RMA chapter update
by Jeff Hammond 03 May '15

03 May '15

(1) If we are going to fix "It is often useful in a put operation to combine the data moved to the target process with the data that resides at that process, rather than replacing it." in 11.3.4, we should go all the way to "It is often useful in a remote update operation to combine the data moved to the target process with the data that resides at that process, rather than replacing it." because "put" is not a superset of MPI_Put and MPI_Accumulate. (2) page 46 line 10-11: "each access epoch much target a different process." s/much/must/ (3) The text added on page 47 "Completes an RMA access epoch started by a call to MPI_WIN_LOCK on window win." and "Completes a shared RMA access epoch started by a call to MPI_WIN_LOCK_ALL on window win." appear to add a semantic restriction not present in MPI 3.0, unless it says somewhere else that LOCK_ALL must be matched by UNLOCK_ALL and not by the appropriate number of UNLOCK calls, and vice versa. If it says this, I can't remember where it is. And if one wants to add this text, it would seem symmetric to specify that FLUSH_ALL and FLUSH_LOCAL_ALL should be associated with LOCK_ALL epochs and not N*LOCK epochs. However, I do not think this is something we should do, and thus I infer we want to be less specific in the previous instance, meaning, we should use "Completes an RMA access epoch started by a call to MPI_WIN_LOCK or MPI_WIN_LOCK_ALL on window win." for both cases on page 47. Jeff On Sun, May 3, 2015 at 8:33 AM, William Gropp <wgropp(a)illinois.edu> wrote: > Attached is an update to the RMA chapter. This does not introduce or change any features; it simply corrects some language and appearance (spacing) and removes a few errors in the text. New text is in red; deletions are not shown. Also attached is the svn diff for these items. The chapter authors reached consensus on these; we have a list of things that the RMA group should discuss at the next meeting. Also note, because of the short time left, the other chapter authors have not had a chance to review these - any errors are mine. > > If you find a problem with these updates (not just awkward wording, or a new problem), respond to the whole group so that we can discuss it as quickly as possible. > > Bill > > > _______________________________________________ > 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

Draft MPI RMA chapter update
by William Gropp 03 May '15

03 May '15

Attached is an update to the RMA chapter. This does not introduce or change any features; it simply corrects some language and appearance (spacing) and removes a few errors in the text. New text is in red; deletions are not shown. Also attached is the svn diff for these items. The chapter authors reached consensus on these; we have a list of things that the RMA group should discuss at the next meeting. Also note, because of the short time left, the other chapter authors have not had a chance to review these - any errors are mine. If you find a problem with these updates (not just awkward wording, or a new problem), respond to the whole group so that we can discuss it as quickly as possible. Bill

1 0