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

Re: [Mpi3-rma] RMA chapter for quick review
by Bronis R. de Supinski 12 Mar '11

12 Mar '11

Bill: I like your wording below that use "The programmer". Bronis On Sat, 12 Mar 2011, William Gropp wrote: > > On Mar 11, 2011, at 11:43 AM, Bronis R. de Supinski wrote: > >> >> Rajeev: >> >> Re: >>> An updated version of the RMA chapter is attached to this mail and on >>> the wiki. We would like to make it available to the Forum by tomorrow >>> afternoon in order to meet the two-week window for the first >>> reading at >>> the March meeting. If you have a chance, please take a look at it and >>> let us know your comments before tomorrow afternoon. >> >> I went through section 11.1 and found ticket 0 type changes. >> I don't know when I will have time to finish so if I hit >> something more significant I will just have to apologize. >> >> Anyway, using [p#, l#] notation: >> >> [1, 20]: fix split infinitive: to access or update => to access or >> to update > Done >> >> [1, 21-23]: I would like to remove the personification of the >> processes in "However, processes may not know which data in their own >> memory need to be accessed or updated by remote processes, and may not >> even know the identity of these processes." Processes do not "know"; >> however, I have not thought of good alternative wording yet. Perhaps: >> "However, a process may not necessarily be able to compute what data >> in its local memory that remote processes need to access or even the >> identity of those processes." > > This really refers to the programmer, so I've proposed an alternative: > > However, the > programmer may not be able to easily determine which data in a process > may need to be accessed or to be updated by operations executed by a > different process, and may not even know which processes may perform > such updates. > >> >> [1, 26]: Clarify antecedent: This may => This distribution may > Done >> >> [1, 27]: Fix split infinitives and dangling preposition: >> >> to periodically poll for potential communication requests to receive >> and >> act upon. => >> >> to poll for potential communication requests to receive and upon which >> to act periodically. > Torsten already fixed >> >> >> [1, 35-38]: In the list: "MPI_PUT (remote write), MPI_GET (remote >> read), >> [and] MPI_ACCUMULATE (remote update), MPI_GET_ACCUMULATE, >> MPI_FETCH_AND_OP >> (remote read and update), MPI_COMPARE_AND_SWAP (remote atomic swap >> operations), MPI_RPUT, MPI_RGET, MPI_RACCUMULATE and >> MPI_RGET_ACCUMULATE"; >> it is odd that a subset of the operations have parenthetical >> expressions >> that indicate the nature of the functionality. Either all operations >> should be followed with a parenthetical explanation or none of them. >> The right solution is probably to reformat into a list with each >> item being the group of operations that provide functionality of the >> same nature (e.g., I am guessing that MPI_GET and MPI_RGET are both >> remote read operations). Initially I thought the ones that are not >> followed by a parenthetical expression were being grouped with the >> following one that has the parenthetical expression (so >> MPI_GET_ACCUMULATE >> is a remote read and update operation). However, the list ends with >> several operations with no following parenthetical expression. Anyway, >> the implicit grouping is unclear. Making it explicit would be better. >> It would also simplify how the following sentence ("When a reference >> is >> made to ï¿½accumulateï¿½ operations in this chapter, it refers to the >> following operations: MPI_ACCUMULATE, MPI_GET_ACCUMULATE, >> MPI_FETCH_AND_OP, >> MPI_COMPARE_AND_SWAP, MPI_RACCUMULATE and MPI_RGET_ACCUMULATE.") >> simpler. >> >> [1, 44-45] Use active voice: correct ordering of memory accesses has >> to >> be imposed by the user, using synchronization calls; => the user must >> impose correct ordering of memory accesses through synchronization >> calls; > > Done by Torsten >> >> [2, 8] Change: "operations, communication coprocessors, etc." to >> "operations, and communication coprocessors." The clause begins >> with "such as" so the "etc." is redundant (not to mention caused >> the omission of the period that should end the sentence). > > Done >> >> [2, 12] Use active voice: "However, support for asynchronous >> communication >> agents in software (handlers, threads, etc.) might be needed, for >> certain >> RMA functions, in a distributed memory environment." => "However, >> certain >> RMA functions might need support for asynchronous communication >> agents in >> software (handlers, threads, etc.) in a distributed memory >> environment." >> >> > Done > >> Bronis >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> In particular: >>> - We fixed some issues with the rules on pg 47 and 48. Please take >>> a look at those rules in their entirety. >>> - pg 3, ln 43, has been updated to specify that default value for >>> the accumulate_ops key is same_op_no_op. >>> >>> Thanks, >>> Rajeev >>> >> <ATT00001.txt> > > 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] RMA chapter for quick review
by William Gropp 12 Mar '11

12 Mar '11

On Mar 11, 2011, at 11:43 AM, Bronis R. de Supinski wrote: > > Rajeev: > > Re: >> An updated version of the RMA chapter is attached to this mail and on >> the wiki. We would like to make it available to the Forum by tomorrow >> afternoon in order to meet the two-week window for the first >> reading at >> the March meeting. If you have a chance, please take a look at it and >> let us know your comments before tomorrow afternoon. > > I went through section 11.1 and found ticket 0 type changes. > I don't know when I will have time to finish so if I hit > something more significant I will just have to apologize. > > Anyway, using [p#, l#] notation: > > [1, 20]: fix split infinitive: to access or update => to access or > to update Done > > [1, 21-23]: I would like to remove the personification of the > processes in "However, processes may not know which data in their own > memory need to be accessed or updated by remote processes, and may not > even know the identity of these processes." Processes do not "know"; > however, I have not thought of good alternative wording yet. Perhaps: > "However, a process may not necessarily be able to compute what data > in its local memory that remote processes need to access or even the > identity of those processes." This really refers to the programmer, so I've proposed an alternative: However, the programmer may not be able to easily determine which data in a process may need to be accessed or to be updated by operations executed by a different process, and may not even know which processes may perform such updates. > > [1, 26]: Clarify antecedent: This may => This distribution may Done > > [1, 27]: Fix split infinitives and dangling preposition: > > to periodically poll for potential communication requests to receive > and > act upon. => > > to poll for potential communication requests to receive and upon which > to act periodically. Torsten already fixed > > > [1, 35-38]: In the list: "MPI_PUT (remote write), MPI_GET (remote > read), > [and] MPI_ACCUMULATE (remote update), MPI_GET_ACCUMULATE, > MPI_FETCH_AND_OP > (remote read and update), MPI_COMPARE_AND_SWAP (remote atomic swap > operations), MPI_RPUT, MPI_RGET, MPI_RACCUMULATE and > MPI_RGET_ACCUMULATE"; > it is odd that a subset of the operations have parenthetical > expressions > that indicate the nature of the functionality. Either all operations > should be followed with a parenthetical explanation or none of them. > The right solution is probably to reformat into a list with each > item being the group of operations that provide functionality of the > same nature (e.g., I am guessing that MPI_GET and MPI_RGET are both > remote read operations). Initially I thought the ones that are not > followed by a parenthetical expression were being grouped with the > following one that has the parenthetical expression (so > MPI_GET_ACCUMULATE > is a remote read and update operation). However, the list ends with > several operations with no following parenthetical expression. Anyway, > the implicit grouping is unclear. Making it explicit would be better. > It would also simplify how the following sentence ("When a reference > is > made to ï¿½accumulateï¿½ operations in this chapter, it refers to the > following operations: MPI_ACCUMULATE, MPI_GET_ACCUMULATE, > MPI_FETCH_AND_OP, > MPI_COMPARE_AND_SWAP, MPI_RACCUMULATE and MPI_RGET_ACCUMULATE.") > simpler. > > [1, 44-45] Use active voice: correct ordering of memory accesses has > to > be imposed by the user, using synchronization calls; => the user must > impose correct ordering of memory accesses through synchronization > calls; Done by Torsten > > [2, 8] Change: "operations, communication coprocessors, etc." to > "operations, and communication coprocessors." The clause begins > with "such as" so the "etc." is redundant (not to mention caused > the omission of the period that should end the sentence). Done > > [2, 12] Use active voice: "However, support for asynchronous > communication > agents in software (handlers, threads, etc.) might be needed, for > certain > RMA functions, in a distributed memory environment." => "However, > certain > RMA functions might need support for asynchronous communication > agents in > software (handlers, threads, etc.) in a distributed memory > environment." > > Done > Bronis > > > > > > > > > > > > > > >> In particular: >> - We fixed some issues with the rules on pg 47 and 48. Please take >> a look at those rules in their entirety. >> - pg 3, ln 43, has been updated to specify that default value for >> the accumulate_ops key is same_op_no_op. >> >> Thanks, >> Rajeev >> > <ATT00001.txt> 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] RMA chapter for quick review
by William Gropp 12 Mar '11

12 Mar '11

I disagree. The proposed RMA chapter is significantly different. What I do suggest is that these changes be marked with the ticket 0 model - \MPIreplace{3.0}{0}{old}{new}. We should try to get the full chapter passed. If that fails, the working group can decide what to do next, and the MPIreplace fixes can be preserved. Bill On Mar 11, 2011, at 10:12 PM, Underwood, Keith D wrote: >>> Hmm. I will need to read through the whole chapter in order >>> to vote on the changes. In that process, I will hit these >>> types of corrections. How would you prefer that we handle them? >> Yes, please record them for now. I think we need to make a decision >> in >> the working group how to deal with them. They will be massive (I >> found >> many of those while reading the chapter). > > These changes should go in a separate ticket. We should vote on the > RMA proposal and then vote on the vast minutiae as a separate ticket > and then vote on the complete chapter. We should not burden any > proposal with "fix everything else in your chapter while you are at > it". > > Keith > > _______________________________________________ > 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] RMA chapter for quick review
by Bronis R. de Supinski 12 Mar '11

12 Mar '11

Torsten: Re: > Just a quick note: the proposal on the wiki is now updated to the newest > version! > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi3-rma-proposal1 OK, I will use it as I evaluate the proposal. I expect to try to separate my feedback between major issues that need to be addressed and minor ticket 0 changes. I will plan on you collecting the latter for eventual application. Bronis

1 0

Re: [Mpi3-rma] RMA chapter for quick review
by Torsten Hoefler 11 Mar '11

11 Mar '11

Hello all, Just a quick note: the proposal on the wiki is now updated to the newest version! https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi3-rma-proposal1 Thanks & All the Best, Torsten PS: I removed the clean version because it is very time-consuming to update both versions every time and all comments were relative to the marked up version. If anybody needs it urgently, please let me know! -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi3-rma] RMA chapter for quick review
by Rajeev Thakur 11 Mar '11

11 Mar '11

>> Hmm. I will need to read through the whole chapter in order >> to vote on the changes. In that process, I will hit these >> types of corrections. How would you prefer that we handle them? > Yes, please record them for now. I think we need to make a decision in > the working group how to deal with them. They will be massive (I found > many of those while reading the chapter). There will likely be hundreds of changes of the type you fixed in the EI chapter if we try to do them. Rajeev

1 0

Re: [Mpi3-rma] RMA chapter for quick review
by Underwood, Keith D 11 Mar '11

11 Mar '11

> > Hmm. I will need to read through the whole chapter in order > > to vote on the changes. In that process, I will hit these > > types of corrections. How would you prefer that we handle them? > Yes, please record them for now. I think we need to make a decision in > the working group how to deal with them. They will be massive (I found > many of those while reading the chapter). These changes should go in a separate ticket. We should vote on the RMA proposal and then vote on the vast minutiae as a separate ticket and then vote on the complete chapter. We should not burden any proposal with "fix everything else in your chapter while you are at it". Keith

1 0

Re: [Mpi3-rma] RMA chapter for quick review
by Torsten Hoefler 11 Mar '11

11 Mar '11

Hi Jim, > I'd like to get a copy of the linked list example in there too before we > circulate it. Could we try with the current version that I sent to the > list a couple days ago and see how well it fits? The comment at the top > should be readily convertible into a caption for the example. Ok, I added it to the latest draft. I also moved the examples section to the very end. For this, I did not mark the complete old section green, I just added a comment at the top that it was moved. Will be uploaded soon. Thanks & All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi3-rma] RMA chapter for quick review
by Torsten Hoefler 11 Mar '11

11 Mar '11

Bronis, > Re: >>> [1, 35-38]: In the list: "MPI_PUT (remote write), MPI_GET (remote read), >>> [and] MPI_ACCUMULATE (remote update), MPI_GET_ACCUMULATE, >>> MPI_FETCH_AND_OP >>> (remote read and update), MPI_COMPARE_AND_SWAP (remote atomic swap >>> operations), MPI_RPUT, MPI_RGET, MPI_RACCUMULATE and >>> MPI_RGET_ACCUMULATE"; >>> it is odd that a subset of the operations have parenthetical expressions >>> that indicate the nature of the functionality. Either all operations >>> should be followed with a parenthetical explanation or none of them. >>> The right solution is probably to reformat into a list with each >>> item being the group of operations that provide functionality of the >>> same nature (e.g., I am guessing that MPI_GET and MPI_RGET are both >>> remote read operations). Initially I thought the ones that are not >>> followed by a parenthetical expression were being grouped with the >>> following one that has the parenthetical expression (so MPI_GET_ACCUMULATE >>> is a remote read and update operation). However, the list ends with >>> several operations with no following parenthetical expression. Anyway, >>> the implicit grouping is unclear. Making it explicit would be better. >>> It would also simplify how the following sentence ("When a reference is >>> made to “accumulate” operations in this chapter, it refers to the >>> following operations: MPI_ACCUMULATE, MPI_GET_ACCUMULATE, >>> MPI_FETCH_AND_OP, >>> MPI_COMPARE_AND_SWAP, MPI_RACCUMULATE and MPI_RGET_ACCUMULATE.") simpler. >> Ok, I added the descriptions to the R-operations. > > Hmm. the more I thought about the more I though this would > be better as a bulleted list, like the one about the types > of collective operations. I think that instead of "The > following communication calls are provided:" (etc.) something > like this would be best: > > ---------------------------------------------------------------- > > One-sided operations can be classified as follows: > > * Remote read: MPI_GET, MPI_RGET; > > * Remote write: MPI_PUT, MPI_RPUT; > > * Remote update: MPI_ACCUMULATE, MPI_RACCUMULATE; > > * Remote read and update: MPI_GET_ACCUMULATE, MPI_FETCH_AND_OP, > MPI_RGET_ACCUMULATE; > > * Remote atomic swap operations: MPI_COMPARE_AND_SWAP. > > This chapter refers to operations set that includes all remote > update, remote read and update, and remote atomic swap operations > as “accumulate” operations. Ok, this is now in the style of the collectives chapter (slightly different than you propose but the same gist). > ------------------------------------------------------------------- > > This version makes it much clearer that grouping is intended > and makes the definition of accumulate operations simpler. > It also makes it clearer that the ommission of an MPI_RCOMPARE_AND_SWAP > operation is intentional. Yes > [snip] > >>> [2, 12] Use active voice: "However, support for asynchronous communication >>> agents in software (handlers, threads, etc.) might be needed, for certain >>> RMA functions, in a distributed memory environment." => "However, certain >>> RMA functions might need support for asynchronous communication agents in >>> software (handlers, threads, etc.) in a distributed memory environment." >> I'll defer this one for now because it doesn't seem essential and it's a >> macro-mess :). > > I'm not sure that I understand. The cost/benefit of this change killed it from my perspective ;). >> Generally, I fear that it will be a lot of work if we're trying to fix >> all the little wording things in the OS chapter. Many of them (most of >> the ones you found) have been there since MPI-2 and are in the places >> that we didn't want to touch. It might be better to not apply such >> changes at this point so that reviewers can focus on the semantic >> changes (and not have colored sections all over the document). > > Hmm. I will need to read through the whole chapter in order > to vote on the changes. In that process, I will hit these > types of corrections. How would you prefer that we handle them? Yes, please record them for now. I think we need to make a decision in the working group how to deal with them. They will be massive (I found many of those while reading the chapter). Thanks & All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi3-rma] RMA chapter for quick review
by Torsten Hoefler 11 Mar '11

11 Mar '11

On Fri, Mar 11, 2011 at 02:50:30PM -0600, Rajeev Thakur wrote: > On Mar 11, 2011, at 2:41 PM, James Dinan wrote: > > > MPI supports two fundamentally dierent memory models: unified and > > separate > > Good point. We should at least change the order in that sentence to > "separate and unified" That's fixed now. Good catch, it was in there since the first edit. I also marked the two statements as removed as suggested by Brian. I used the change macro for this, please don't complain that there is now green text which was red ;-). This is just to remind us that we removed this part. We can erase it later. This change will be in the next upload. All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0