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

[Mpi3-rma] Linked List Example for RMA Chapter
by James Dinan 08 Mar '11

08 Mar '11

Hi All, I've been refining the linked list example we looked at several months ago for inclusion in the RMA chapter. Previously, we had two versions: one that did put/get under exclusive lock and another that did CAS under exclusive lock. This new version is lock free and demonstrates the following MPI-3 functionality: dynamic windows, lock all, flush, CAS, accumulate with replace, and get accumulate with no op. The code can be compiled to a .o using the attached mpi3.h (for OpenMPI you may get a warning from MPI_NO_OP, define it to NULL instead of 0). It's still a little on the long side; we're currently at roughly three pages and we were hoping for two. We can try to squeeze and remove non-essential parts (e.g. maintaining the allocation list) if we want to save space. If anybody can spare a few cycles, I would appreciate any feedback. Thanks, ~Jim.

1 0

Re: [Mpi3-rma] current version of proposal
by William Gropp 08 Mar '11

08 Mar '11

I believe that this has already been fixed in some version of the doc - I just downloaded the current version, and this has been fixed already. Bill On Mar 8, 2011, at 1:44 PM, James Dinan wrote: > Hi All, > > I think there's a bug in the prototype for MPI_Get_accumulate: > > int MPI_Get_accumulate(void *origin_addr, int origin_count, > MPI_Datatype origin_datatype, void *result_addr, > int result_count, MPI_Datatype result_datatype, > int target_rank, MPI_Aint target_disp, int *target_count, > MPI_Datatype target_datatype, MPI_Op op, MPI_Win win) > > I think that the target count should be 'int' rather than 'int*'. > MPI_Rget_accumulate has this same type problem for the origin, result, > and target counts: > > int MPI_Rget_accumulate(void *origin_addr, int *origin_count, > MPI_Datatype origin_datatype, void *result_addr, > int *result_count, MPI_Datatype result_datatype, > int target_rank, MPI_Aint target_disp, int *target_count, > MPI_Datatype target_datatype, MPI_Op op, MPI_Win win, > MPI_Request *req) > > Cheers, > ~Jim. > > On 3/5/11 4:45 PM, Torsten Hoefler wrote: >> On Fri, Mar 04, 2011 at 11:35:41PM -0600, Rajeev Thakur wrote: >>> Thanks. A few more comments: >>> >>>>> 5:28 - What discussion of alloc_mem in Section 8.2 also applies >>>>> here? Is it the Rationale on the next page after free_mem? That >>>>> should be mentioned here. It is important to mention here that >>>>> void* actually means void**. >>>> Yes, it's now referencing discussions and retionale. >>> >>> I don't think the current sentence "The discussion of and >>> rationales for MPI_ALLOC_MEM and MPI_FREE_MEM in Section 8.2 also >>> apply to MPI_WIN_ALLOCATE" >>> >>> is enough for the user to realize there is important information >>> back in Sec 8.2 that explains that void *baseptr is actually void >>> **baseptr. And it's a common mistake users make when passing this >>> parameter. How about adding this text "in particular... " at the >>> end: >>> >>> "The discussion of and rationales for MPI_ALLOC_MEM and >>> MPI_FREE_MEM in Section 8.2 also apply to MPI_WIN_ALLOCATE; in >>> particular, see the rationale in Section 8.2 for an explanation of >>> the type used for \mpiarg{baseptr}. >> done >> >>>>> 6:11 - Change "This is combined with local routines" to "It must >>>>> be used in combination with local routines (MPI_Win_attach and >>>>> MPI_Win_detach)" >>>> done >>> >>> Can you delete the parentheses around those functions (although they >>> were there in my mail). >> done - I also added a "the" >> >>>>> 7:19 - Awkward sentence. Change to "The memory region specified >>>>> must not contain any part that is already attached to the window >>>>> win." Delete the part starting from "that is" >>>> done >>> >>> Change "are erroneous" to "is erroneous" in 7:21. >> done >> >>>>> 19:37 - "datatype of" should be "origin_datatype from" >>>> done >>> >>> Bad line break now at 19:37. >> Hmm, that's a macro thing :-(. Not sure what to do. >> >>>>> 20:46 - awkward sentence. Change "and MPI_NO_OP or MPI_REPLACE" >>>>> to "as well as MPI_NO_OP and MPI_REPLACE," (add comma at the end) >>>> done >>> >>> There should be a comma after MPI_REDUCE as well (as was there >>> earlier). >> done >> >>>>> 29:43 - These two calls -> These four calls. Add sentence to >>>>> cover lock_all and unlock_all >>>> done >>>> >>>>> 31:35 - comma after "needed". Delete then >>>>> 31:36 - make it compare-and-swap >>>> done >>> >>> The last one is not done. I had suggested changing "compare and >>> swap and accumulates" to "compare-and-swap and accumulates" (i.e., >>> adding the hyphens) just to make the sentence read more clearly. >> this is gone now >> >>>>> 37:11 - Awkward sentence. Change to "During the epoch, the >>>>> calling process can access the window memory on all processes in >>>>> win by using RMA operations." >>>> done >>> >>> win should be \mpiarg{win} >> done >> >>>>> 40:1 - Sentence style is different from previous functions. >>>>> Change to "Locally completes at the origin all..." >>>> done >>> >>> Typo: origina -> origin >> done >> >>> I would prefer "Locally completes" instead of "Locally complete". >>> It is a short form of "This function locally completes..." >> done >> >>>>> 47:14 - I would say delete this advice to implementors. If we >>>>> keep it, I would like to fix the first sentence, which is awkward. >>>> I fixed it. >>> >>> "Overlapping accesses (and other operations that MPI-3 specifies) >>> are undefined." >>> It is not clear to the reader what "other operations" the text in >>> parenthesis refers to. >> right, I removed it. >> >>> "However, implementations may wish to provide a mode in which such >>> operations are erroneous to aid in debugging code." >>> >>> "are erroneous to aid in debugging code" at the end of the >>> sentence doesn't read well. I would change that sentence to >>> >>> "However, to assist users in debugging code, implementations may >>> wish to provide a mode in which such operations are erroneous." >> done >> >>>>> 47:28 - why is "that use the same operation" being removed. It >>>>> should be there. >>>> no, this is now in the new info key. I added a sentence >>>> clarifying this >>>> (and referencing back). >>> >>> OK. With that deletion, the chapter doesn't say anywhere whether >>> concurrent overlapping accumulates with different operators are >>> allowed or not. Or are they allowed only if one of the two >>> operations is a no_op? >>> >>> And what is the default if the user doesn't pass any info key >>> accumulate_ops? What should the implementation assume? >> Right, I believe Brian is working on a fix (we should put this on the >> list of open issues). >> >> A new version is uploaded. >> >> Thanks& All the Best, >> Torsten >> > > _______________________________________________ > 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] current version of proposal
by James Dinan 08 Mar '11

08 Mar '11

Hi All, I think there's a bug in the prototype for MPI_Get_accumulate: int MPI_Get_accumulate(void *origin_addr, int origin_count, MPI_Datatype origin_datatype, void *result_addr, int result_count, MPI_Datatype result_datatype, int target_rank, MPI_Aint target_disp, int *target_count, MPI_Datatype target_datatype, MPI_Op op, MPI_Win win) I think that the target count should be 'int' rather than 'int*'. MPI_Rget_accumulate has this same type problem for the origin, result, and target counts: int MPI_Rget_accumulate(void *origin_addr, int *origin_count, MPI_Datatype origin_datatype, void *result_addr, int *result_count, MPI_Datatype result_datatype, int target_rank, MPI_Aint target_disp, int *target_count, MPI_Datatype target_datatype, MPI_Op op, MPI_Win win, MPI_Request *req) Cheers, ~Jim. On 3/5/11 4:45 PM, Torsten Hoefler wrote: > On Fri, Mar 04, 2011 at 11:35:41PM -0600, Rajeev Thakur wrote: >> Thanks. A few more comments: >> >>>> 5:28 - What discussion of alloc_mem in Section 8.2 also applies here? Is it the Rationale on the next page after free_mem? That should be mentioned here. It is important to mention here that void* actually means void**. >>> Yes, it's now referencing discussions and retionale. >> >> I don't think the current sentence "The discussion of and rationales for MPI_ALLOC_MEM and MPI_FREE_MEM in Section 8.2 also apply to MPI_WIN_ALLOCATE" >> >> is enough for the user to realize there is important information back in Sec 8.2 that explains that void *baseptr is actually void **baseptr. And it's a common mistake users make when passing this parameter. How about adding this text "in particular... " at the end: >> >> "The discussion of and rationales for MPI_ALLOC_MEM and MPI_FREE_MEM in Section 8.2 also apply to MPI_WIN_ALLOCATE; in particular, see the rationale in Section 8.2 for an explanation of the type used for \mpiarg{baseptr}. > done > >>>> 6:11 - Change "This is combined with local routines" to "It must be used in combination with local routines (MPI_Win_attach and MPI_Win_detach)" >>> done >> >> Can you delete the parentheses around those functions (although they >> were there in my mail). > done - I also added a "the" > >>>> 7:19 - Awkward sentence. Change to "The memory region specified must not contain any part that is already attached to the window win." Delete the part starting from "that is" >>> done >> >> Change "are erroneous" to "is erroneous" in 7:21. > done > >>>> 19:37 - "datatype of" should be "origin_datatype from" >>> done >> >> Bad line break now at 19:37. > Hmm, that's a macro thing :-(. Not sure what to do. > >>>> 20:46 - awkward sentence. Change "and MPI_NO_OP or MPI_REPLACE" to "as well as MPI_NO_OP and MPI_REPLACE," (add comma at the end) >>> done >> >> There should be a comma after MPI_REDUCE as well (as was there earlier). > done > >>>> 29:43 - These two calls -> These four calls. Add sentence to cover lock_all and unlock_all >>> done >>> >>>> 31:35 - comma after "needed". Delete then >>>> 31:36 - make it compare-and-swap >>> done >> >> The last one is not done. I had suggested changing "compare and swap and accumulates" to "compare-and-swap and accumulates" (i.e., adding the hyphens) just to make the sentence read more clearly. > this is gone now > >>>> 37:11 - Awkward sentence. Change to "During the epoch, the calling process can access the window memory on all processes in win by using RMA operations." >>> done >> >> win should be \mpiarg{win} > done > >>>> 40:1 - Sentence style is different from previous functions. Change to "Locally completes at the origin all..." >>> done >> >> Typo: origina -> origin > done > >> I would prefer "Locally completes" instead of "Locally complete". It is a short form of "This function locally completes..." > done > >>>> 47:14 - I would say delete this advice to implementors. If we keep it, I would like to fix the first sentence, which is awkward. >>> I fixed it. >> >> "Overlapping accesses (and other operations that MPI-3 specifies) are undefined." >> It is not clear to the reader what "other operations" the text in parenthesis refers to. > right, I removed it. > >> "However, implementations may wish to provide a mode in which such operations are erroneous to aid in debugging code." >> >> "are erroneous to aid in debugging code" at the end of the sentence doesn't read well. I would change that sentence to >> >> "However, to assist users in debugging code, implementations may wish to provide a mode in which such operations are erroneous." > done > >>>> 47:28 - why is "that use the same operation" being removed. It should be there. >>> no, this is now in the new info key. I added a sentence clarifying this >>> (and referencing back). >> >> OK. With that deletion, the chapter doesn't say anywhere whether concurrent overlapping accumulates with different operators are allowed or not. Or are they allowed only if one of the two operations is a no_op? >> >> And what is the default if the user doesn't pass any info key accumulate_ops? What should the implementation assume? > Right, I believe Brian is working on a fix (we should put this on the > list of open issues). > > A new version is uploaded. > > Thanks& All the Best, > Torsten >

1 0

Re: [Mpi3-rma] current version of proposal
by Torsten Hoefler 05 Mar '11

05 Mar '11

On Fri, Mar 04, 2011 at 11:35:41PM -0600, Rajeev Thakur wrote: > Thanks. A few more comments: > > >> 5:28 - What discussion of alloc_mem in Section 8.2 also applies here? Is it the Rationale on the next page after free_mem? That should be mentioned here. It is important to mention here that void* actually means void**. > > Yes, it's now referencing discussions and retionale. > > I don't think the current sentence "The discussion of and rationales for MPI_ALLOC_MEM and MPI_FREE_MEM in Section 8.2 also apply to MPI_WIN_ALLOCATE" > > is enough for the user to realize there is important information back in Sec 8.2 that explains that void *baseptr is actually void **baseptr. And it's a common mistake users make when passing this parameter. How about adding this text "in particular... " at the end: > > "The discussion of and rationales for MPI_ALLOC_MEM and MPI_FREE_MEM in Section 8.2 also apply to MPI_WIN_ALLOCATE; in particular, see the rationale in Section 8.2 for an explanation of the type used for \mpiarg{baseptr}. done > >> 6:11 - Change "This is combined with local routines" to "It must be used in combination with local routines (MPI_Win_attach and MPI_Win_detach)" > > done > > Can you delete the parentheses around those functions (although they > were there in my mail). done - I also added a "the" > >> 7:19 - Awkward sentence. Change to "The memory region specified must not contain any part that is already attached to the window win." Delete the part starting from "that is" > > done > > Change "are erroneous" to "is erroneous" in 7:21. done > >> 19:37 - "datatype of" should be "origin_datatype from" > > done > > Bad line break now at 19:37. Hmm, that's a macro thing :-(. Not sure what to do. > >> 20:46 - awkward sentence. Change "and MPI_NO_OP or MPI_REPLACE" to "as well as MPI_NO_OP and MPI_REPLACE," (add comma at the end) > > done > > There should be a comma after MPI_REDUCE as well (as was there earlier). done > >> 29:43 - These two calls -> These four calls. Add sentence to cover lock_all and unlock_all > > done > > > >> 31:35 - comma after "needed". Delete then > >> 31:36 - make it compare-and-swap > > done > > The last one is not done. I had suggested changing "compare and swap and accumulates" to "compare-and-swap and accumulates" (i.e., adding the hyphens) just to make the sentence read more clearly. this is gone now > >> 37:11 - Awkward sentence. Change to "During the epoch, the calling process can access the window memory on all processes in win by using RMA operations." > > done > > win should be \mpiarg{win} done > >> 40:1 - Sentence style is different from previous functions. Change to "Locally completes at the origin all..." > > done > > Typo: origina -> origin done > I would prefer "Locally completes" instead of "Locally complete". It is a short form of "This function locally completes..." done > >> 47:14 - I would say delete this advice to implementors. If we keep it, I would like to fix the first sentence, which is awkward. > > I fixed it. > > "Overlapping accesses (and other operations that MPI-3 specifies) are undefined." > It is not clear to the reader what "other operations" the text in parenthesis refers to. right, I removed it. > "However, implementations may wish to provide a mode in which such operations are erroneous to aid in debugging code." > > "are erroneous to aid in debugging code" at the end of the sentence doesn't read well. I would change that sentence to > > "However, to assist users in debugging code, implementations may wish to provide a mode in which such operations are erroneous." done > >> 47:28 - why is "that use the same operation" being removed. It should be there. > > no, this is now in the new info key. I added a sentence clarifying this > > (and referencing back). > > OK. With that deletion, the chapter doesn't say anywhere whether concurrent overlapping accumulates with different operators are allowed or not. Or are they allowed only if one of the two operations is a no_op? > > And what is the default if the user doesn't pass any info key accumulate_ops? What should the implementation assume? Right, I believe Brian is working on a fix (we should put this on the list of open issues). A new version is uploaded. 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] current version of proposal
by Rajeev Thakur 05 Mar '11

05 Mar '11

There is a sentence at 54:30 that mentions "same operation". Maybe it needs to be updated. "The outcome of concurrent accumulate[s] operations to the same location, with the same operation and predefined datatype, is as if the accumulates where done at that location in some serial order." Rajeev On Mar 5, 2011, at 10:14 AM, James Dinan wrote: > On 03/04/2011 11:35 PM, Rajeev Thakur wrote: >>>> 47:28 - why is "that use the same operation" being removed. It >>>> should be there. >>> no, this is now in the new info key. I added a sentence clarifying >>> this (and referencing back). >> >> OK. With that deletion, the chapter doesn't say anywhere whether >> concurrent overlapping accumulates with different operators are >> allowed or not. Or are they allowed only if one of the two operations >> is a no_op? >> >> And what is the default if the user doesn't pass any info key >> accumulate_ops? What should the implementation assume? > > The new default for accumulate ordering is strict ordering. I think > that as long as the same datatype is used, the result of concurrent > conflicting accumulate operations is defined as some atomic interleaving > at the datatype-level. > > ~Jim. > _______________________________________________ > 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] current version of proposal
by James Dinan 05 Mar '11

05 Mar '11

On 03/04/2011 11:35 PM, Rajeev Thakur wrote: >>> 47:28 - why is "that use the same operation" being removed. It >>> should be there. >> no, this is now in the new info key. I added a sentence clarifying >> this (and referencing back). > > OK. With that deletion, the chapter doesn't say anywhere whether > concurrent overlapping accumulates with different operators are > allowed or not. Or are they allowed only if one of the two operations > is a no_op? > > And what is the default if the user doesn't pass any info key > accumulate_ops? What should the implementation assume? The new default for accumulate ordering is strict ordering. I think that as long as the same datatype is used, the result of concurrent conflicting accumulate operations is defined as some atomic interleaving at the datatype-level. ~Jim.

1 0

Re: [Mpi3-rma] current version of proposal
by Rajeev Thakur 04 Mar '11

04 Mar '11

Thanks. A few more comments: >> 5:28 - What discussion of alloc_mem in Section 8.2 also applies here? Is it the Rationale on the next page after free_mem? That should be mentioned here. It is important to mention here that void* actually means void**. > Yes, it's now referencing discussions and retionale. I don't think the current sentence "The discussion of and rationales for MPI_ALLOC_MEM and MPI_FREE_MEM in Section 8.2 also apply to MPI_WIN_ALLOCATE" is enough for the user to realize there is important information back in Sec 8.2 that explains that void *baseptr is actually void **baseptr. And it's a common mistake users make when passing this parameter. How about adding this text "in particular... " at the end: "The discussion of and rationales for MPI_ALLOC_MEM and MPI_FREE_MEM in Section 8.2 also apply to MPI_WIN_ALLOCATE; in particular, see the rationale in Section 8.2 for an explanation of the type used for \mpiarg{baseptr}. >> 6:11 - Change "This is combined with local routines" to "It must be used in combination with local routines (MPI_Win_attach and MPI_Win_detach)" > done Can you delete the parentheses around those functions (although they were there in my mail). >> 7:19 - Awkward sentence. Change to "The memory region specified must not contain any part that is already attached to the window win." Delete the part starting from "that is" > done Change "are erroneous" to "is erroneous" in 7:21. >> 19:37 - "datatype of" should be "origin_datatype from" > done Bad line break now at 19:37. >> 20:46 - awkward sentence. Change "and MPI_NO_OP or MPI_REPLACE" to "as well as MPI_NO_OP and MPI_REPLACE," (add comma at the end) > done There should be a comma after MPI_REDUCE as well (as was there earlier). >> 29:43 - These two calls -> These four calls. Add sentence to cover lock_all and unlock_all > done > >> 31:35 - comma after "needed". Delete then >> 31:36 - make it compare-and-swap > done The last one is not done. I had suggested changing "compare and swap and accumulates" to "compare-and-swap and accumulates" (i.e., adding the hyphens) just to make the sentence read more clearly. >> 37:11 - Awkward sentence. Change to "During the epoch, the calling process can access the window memory on all processes in win by using RMA operations." > done win should be \mpiarg{win} >> 40:1 - Sentence style is different from previous functions. Change to "Locally completes at the origin all..." > done Typo: origina -> origin I would prefer "Locally completes" instead of "Locally complete". It is a short form of "This function locally completes..." >> 47:14 - I would say delete this advice to implementors. If we keep it, I would like to fix the first sentence, which is awkward. > I fixed it. "Overlapping accesses (and other operations that MPI-3 specifies) are undefined." It is not clear to the reader what "other operations" the text in parenthesis refers to. "However, implementations may wish to provide a mode in which such operations are erroneous to aid in debugging code." "are erroneous to aid in debugging code" at the end of the sentence doesn't read well. I would change that sentence to "However, to assist users in debugging code, implementations may wish to provide a mode in which such operations are erroneous." >> 47:28 - why is "that use the same operation" being removed. It should be there. > no, this is now in the new info key. I added a sentence clarifying this > (and referencing back). OK. With that deletion, the chapter doesn't say anywhere whether concurrent overlapping accumulates with different operators are allowed or not. Or are they allowed only if one of the two operations is a no_op? And what is the default if the user doesn't pass any info key accumulate_ops? What should the implementation assume? >> 49:31 - "is" -> "are" > I disagree, it doesn't have to delay them. Not sure what you are disagreeing with. I only suggested a change from "is" to "are", which you have done :-). Rajeev

1 0

Re: [Mpi3-rma] current version of proposal
by Torsten Hoefler 04 Mar '11

04 Mar '11

Rajeev, Thank you very much for the comprehensive review! Comments are inline below: > 5:16 - "void **base" should be "void *baseptr". (void * is used in Alloc_mem) fixed > 5:28 - What discussion of alloc_mem in Section 8.2 also applies here? Is it the Rationale on the next page after free_mem? That should be mentioned here. It is important to mention here that void* actually means void**. Yes, it's now referencing discussions and retionale. > 6:11 - Change "This is combined with local routines" to "It must be used in combination with local routines (MPI_Win_attach and MPI_Win_detach)" done > 7:19 - Awkward sentence. Change to "The memory region specified must not contain any part that is already attached to the window win." Delete the part starting from "that is" done > 19:7 - "each buffer entry" -> "each entry in origin buffer" > 19:12 - "each buffer entry" -> "each entry in result buffer" > 19:19 - "each buffer entry" -> "each entry in target buffer" done > 19:27 - delete * in "int *target_count" done > 19:37 - "datatype of" should be "origin_datatype from" done > 20:23 - "the buffer entry" -> "the entry in origin, result, and target buffers" done > 20:42 - "datatype of" -> "datatype from" done > 20:46 - awkward sentence. Change "and MPI_NO_OP or MPI_REPLACE" to "as well as MPI_NO_OP and MPI_REPLACE," (add comma at the end) done > 21:13 - "of buffer entry" -> "of the element in all buffers" done > 21:33 - "target compare buffer" -> "target buffer" done > 21:34 - change to "must belong to one of the following categories of predefined datatypes" done > 22:42 - after "operation" add "(i.e., after the corresponding test or wait)" done > 25:28 - delete * in "int *target_count" done > 26:43 - Labeling problem: Figure 11.5 should be Figure 11.1 this seems correct in my draft? > 26:12 - Delete the sentences from "This query functionality" onwards. There is no way to request a memory model, only to query it. So no similarity with threads. I tried to fix it but you're right, the next sentence is enough, so I removed it as suggested. I liked the analogy though. > 29:43 - These two calls -> These four calls. Add sentence to cover lock_all and unlock_all done > 31:35 - comma after "needed". Delete then > 31:36 - make it compare-and-swap done > 37:11 - Awkward sentence. Change to "During the epoch, the calling process can access the window memory on all processes in win by using RMA operations." done > 37:14 - "refers to all" -> "refers to a lock on all" done > 39:20 - awkward sentence. Change to "MPI_WIN_FLUSH completes all outstanding RMA operations initiated by the calling process to the target rank. The operations are completed both at the origin and at the target." Delete sentence "RMA operations..." done > 40:1 - Sentence style is different from previous functions. Change to "Locally completes at the origin all..." done > 46:9 - Delete the part "when the RMA operation completes at the target". This Rule 5 is about when a local update is visible in the public window. It has nothing to do with RMA operation completing at target. done > 47:14 - I would say delete this advice to implementors. If we keep it, I would like to fix the first sentence, which is awkward. I fixed it. > 47:28 - why is "that use the same operation" being removed. It should be there. no, this is now in the new info key. I added a sentence clarifying this (and referencing back). > 47:42 - "based on avoiding" -> "to avoid" done > 47:47 - "at the target" sounds like you are referring to another process, whereas you are referring to this process. Just delete it. done > 48:1 - Remember to update Item 1 on previous page depending on the outcome of this. Right now it contradicts Item 1. yes, will be done later > 49:18 - or unlock_all done > 50:1, Example 11.12 - Lock_all and unlock_all are not collective. They are not needed on process B. Also, I would prefer the barrier to be before local_all on process A. Brian will fix the examples > 50:2: Delete "Process B only needs to call lock_all..." Brian will fix the examples > 51:1, Example 11.14: Same. Process B does not need to call lock_all, unlock_all. I would prefer the unlock_all on process A to be before the barrier. Brian will fix the examples > Typos/small fixes > ------------- > 1:39 - "in the following" -> "in this chapter" done > 1:47 - add comma before "which" done > 3:37 - delete "then" done > 3:45 - add comma after "libraries". Delete "then" done > 3:47 - add comma before "which" done > 5:27 - "valid," -> "valid;" done > 6:34 - "target. I.e," -> "target; i.e.," done > 7:41 - why is "vendor" in green, should just be deleted done > 7:43 - "MPI; that" -> "MPI, which" done > 7:46 - "in" -> "on" done > 7:47 - "that" -> "the" done > 8:45 - "memory," -> "memory;" done > 9:2 - "This, to" -> "This is to" done > 9:5 - after "argument" add "to the corresponding window creation function" done > 9:22 - delete first word "in" done > 10:32 - "MPI wait" -> "MPI test or wait" done > 19:34 - add space between last two variables done > 21:2 - why is functionality in green. delete it. done > 26:20 - "is" should be "are" done > 26:21 - which -> that done > 37:10 - delete green text done > 38:4 - E.g. -> For example (a sentence shouldn't begin with E.g. or I.e.) done > 38:25 - Delete "might". Should not be in green. done > 39:2 - I prefer the MPI 2.2 version because "The update..." applies only to the last of the 3 options in the previous sentence. done > 39:23 and 25 - delete green stuff; it wasn't in 2.2. done > 39:24 - "document, this" -> "document, which" done > 44:41 - Windows -> windows done > 46:27 - add comma after "call" done > 49:31 - "is" -> "are" I disagree, it doesn't have to delay them. > 50:20 - "reading a" -> "reading of a" done > 51:18 - proces -> process done > 52:25 - interation -> interaction done > 54:48 - add comma before which done Thanks a lot Rajeev! I uploaded a new version to the Wiki. This version also contains parts of Jim's corrections. https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… 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] current version of proposal
by Rajeev Thakur 02 Mar '11

02 Mar '11

My comments on the current draft: 5:16 - "void **base" should be "void *baseptr". (void * is used in Alloc_mem) 5:28 - What discussion of alloc_mem in Section 8.2 also applies here? Is it the Rationale on the next page after free_mem? That should be mentioned here. It is important to mention here that void* actually means void**. 6:11 - Change "This is combined with local routines" to "It must be used in combination with local routines (MPI_Win_attach and MPI_Win_detach)" 7:19 - Awkward sentence. Change to "The memory region specified must not contain any part that is already attached to the window win." Delete the part starting from "that is" 19:7 - "each buffer entry" -> "each entry in origin buffer" 19:12 - "each buffer entry" -> "each entry in result buffer" 19:19 - "each buffer entry" -> "each entry in target buffer" 19:27 - delete * in "int *target_count" 19:37 - "datatype of" should be "origin_datatype from" 20:23 - "the buffer entry" -> "the entry in origin, result, and target buffers" 20:42 - "datatype of" -> "datatype from" 20:46 - awkward sentence. Change "and MPI_NO_OP or MPI_REPLACE" to "as well as MPI_NO_OP and MPI_REPLACE," (add comma at the end) 21:13 - "of buffer entry" -> "of the element in all buffers" 21:33 - "target compare buffer" -> "target buffer" 21:34 - change to "must belong to one of the following categories of predefined datatypes" 22:42 - after "operation" add "(i.e., after the corresponding test or wait)" 25:28 - delete * in "int *target_count" 26:43 - Labeling problem: Figure 11.5 should be Figure 11.1 26:12 - Delete the sentences from "This query functionality" onwards. There is no way to request a memory model, only to query it. So no similarity with threads. 29:43 - These two calls -> These four calls. Add sentence to cover lock_all and unlock_all 31:35 - comma after "needed". Delete then 31:36 - make it compare-and-swap 37:11 - Awkward sentence. Change to "During the epoch, the calling process can access the window memory on all processes in win by using RMA operations." 37:14 - "refers to all" -> "refers to a lock on all" 39:20 - awkward sentence. Change to "MPI_WIN_FLUSH completes all outstanding RMA operations initiated by the calling process to the target rank. The operations are completed both at the origin and at the target." Delete sentence "RMA operations..." 40:1 - Sentence style is different from previous functions. Change to "Locally completes at the origin all..." 46:9 - Delete the part "when the RMA operation completes at the target". This Rule 5 is about when a local update is visible in the public window. It has nothing to do with RMA operation completing at target. 47:14 - I would say delete this advice to implementors. If we keep it, I would like to fix the first sentence, which is awkward. 47:28 - why is "that use the same operation" being removed. It should be there. 47:42 - "based on avoiding" -> "to avoid" 47:47 - "at the target" sounds like you are referring to another process, whereas you are referring to this process. Just delete it. 48:1 - Remember to update Item 1 on previous page depending on the outcome of this. Right now it contradicts Item 1. 49:18 - or unlock_all 50:1, Example 11.12 - Lock_all and unlock_all are not collective. They are not needed on process B. Also, I would prefer the barrier to be before local_all on process A. 50:2: Delete "Process B only needs to call lock_all..." 51:1, Example 11.14: Same. Process B does not need to call lock_all, unlock_all. I would prefer the unlock_all on process A to be before the barrier. Typos/small fixes ------------- 1:39 - "in the following" -> "in this chapter" 1:47 - add comma before "which" 3:37 - delete "then" 3:45 - add comma after "libraries". Delete "then" 3:47 - add comma before "which" 5:27 - "valid," -> "valid;" 6:34 - "target. I.e," -> "target; i.e.," 7:41 - why is "vendor" in green, should just be deleted 7:43 - "MPI; that" -> "MPI, which" 7:46 - "in" -> "on" 7:47 - "that" -> "the" 8:45 - "memory," -> "memory;" 9:2 - "This, to" -> "This is to" 9:5 - after "argument" add "to the corresponding window creation function" 9:22 - delete first word "in" 10:32 - "MPI wait" -> "MPI test or wait" 19:34 - add space between last two variables 21:2 - why is functionality in green. delete it. 26:20 - "is" should be "are" 26:21 - which -> that 37:10 - delete green text 38:4 - E.g. -> For example (a sentence shouldn't begin with E.g. or I.e.) 38:25 - Delete "might". Should not be in green. 39:2 - I prefer the MPI 2.2 version because "The update..." applies only to the last of the 3 options in the previous sentence. 39:23 and 25 - delete green stuff; it wasn't in 2.2. 39:24 - "document, this" -> "document, which" 44:41 - Windows -> windows 46:27 - add comma after "call" 49:31 - "is" -> "are" 50:20 - "reading a" -> "reading of a" 51:18 - proces -> process 52:25 - interation -> interaction 54:48 - add comma before which

1 0

Re: [Mpi3-rma] current version of proposal
by Barrett, Brian W 02 Mar '11

02 Mar '11

On 3/2/11 3:04 PM, "Torsten Hoefler" <htor(a)illinois.edu> wrote: >> >> As an aside, it's not clear in the current text which is the default for >> accumulate_ops: same_op or same_op_no_op. The semantics section still >> defines same_op, but that seems to go agains the use of info keys to >>relax >> requirements on the implementation. >True. Right now, the stricter (more limited) semantics are default (I >don't have an issue with this). We could forward-reference from the >info-key description to the semantics section to make it more clear. I think the semantics section needs to be made a bit more clear. It should have some text saying that the "same op" restriction can be loosened with an info key (right now it says nothing about the info key). That would make the default much more obvious. Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0