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

Re: [mpiwg-rma] Changes to the RMA chapter
by William Gropp 04 Mar '15

04 Mar '15

For the bigger one, yes, this is much harder and absolutely not ticket-0. no_locks is particularly tricky, because it applies to the window, not the window object, and hence is defined as local. Bill On Mar 4, 2015, at 4:59 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > There are two questions below. The formatting part (whether to use [SAME]) is a smaller issue. The bigger issue is whether we want to say that all the remaining info keys no_locks, etc., should be the same on all processes. > > I want to say that, but: (1) need the chapter committee consensus, and (2) I'm not sure it's a ticket-0 change, though we did make that change for same_size as ticket-0. > > -- Pavan > >> On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> >> That’s an excellent idea - we should use the same language throughout the standard, and the I/O chapter is probably the best source. >> >> Bill >> >> On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>> >>> Nathan suggested to use the I/O chapter format where info keys are annotated with "[SAME]" to indicate that all processes must provide the same info key. That is probably a ticket-0 change. We need to first agree on whether we want to do this. >>> >>> -- Pavan >>> >>>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>> >>>> >>>> Folks at Forum complained about the addition to the "same_size" info key which added the following phrase: >>>> >>>> "and that all processes have provided this info key with the same value" >>>> >>>> (this change was not a part of any ticket, and was made by the chapter committee) >>>> >>>> There were two concerns: >>>> >>>> 1. This is a backward incompatible change (as in, applications were not required to give the same value earlier), though folks understood why this is needed. They were OK as long as we add a Errata/Changelog item saying so. >>>> >>>> 2. The property that all processes should give the same info key was true for other keys in that section as well (no_locks, accumulate_ordering, accumulate_ops). So the same sentence should be added to them as well. >>>> >>>> The Forum wants to see a draft of these changes. I'd like to propose adding the same phrase ("and that all processes have provided this info key with the same value") to the other info keys as well. What do folks think? Is this something that we agree on (technically, it is possible to have different info keys in the job, but it probably doesn't make much sense). >>>> >>>> Thoughts? >>>> >>>> -- Pavan >>>> >>>> -- >>>> Pavan Balaji ✉️ >>>> http://www.mcs.anl.gov/~balaji >>>> >>>> _______________________________________________ >>>> mpiwg-rma mailing list >>>> mpiwg-rma(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >>> >>> -- >>> Pavan Balaji ✉️ >>> http://www.mcs.anl.gov/~balaji >>> >>> _______________________________________________ >>> 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 > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > 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] Changes to the RMA chapter
by Balaji, Pavan 04 Mar '15

04 Mar '15

There are two questions below. The formatting part (whether to use [SAME]) is a smaller issue. The bigger issue is whether we want to say that all the remaining info keys no_locks, etc., should be the same on all processes. I want to say that, but: (1) need the chapter committee consensus, and (2) I'm not sure it's a ticket-0 change, though we did make that change for same_size as ticket-0. -- Pavan > On Mar 4, 2015, at 4:56 PM, William Gropp <wgropp(a)illinois.edu> wrote: > > That’s an excellent idea - we should use the same language throughout the standard, and the I/O chapter is probably the best source. > > Bill > > On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> >> Nathan suggested to use the I/O chapter format where info keys are annotated with "[SAME]" to indicate that all processes must provide the same info key. That is probably a ticket-0 change. We need to first agree on whether we want to do this. >> >> -- Pavan >> >>> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>> >>> >>> Folks at Forum complained about the addition to the "same_size" info key which added the following phrase: >>> >>> "and that all processes have provided this info key with the same value" >>> >>> (this change was not a part of any ticket, and was made by the chapter committee) >>> >>> There were two concerns: >>> >>> 1. This is a backward incompatible change (as in, applications were not required to give the same value earlier), though folks understood why this is needed. They were OK as long as we add a Errata/Changelog item saying so. >>> >>> 2. The property that all processes should give the same info key was true for other keys in that section as well (no_locks, accumulate_ordering, accumulate_ops). So the same sentence should be added to them as well. >>> >>> The Forum wants to see a draft of these changes. I'd like to propose adding the same phrase ("and that all processes have provided this info key with the same value") to the other info keys as well. What do folks think? Is this something that we agree on (technically, it is possible to have different info keys in the job, but it probably doesn't make much sense). >>> >>> Thoughts? >>> >>> -- Pavan >>> >>> -- >>> Pavan Balaji ✉️ >>> http://www.mcs.anl.gov/~balaji >>> >>> _______________________________________________ >>> mpiwg-rma mailing list >>> mpiwg-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >> >> -- >> Pavan Balaji ✉️ >> http://www.mcs.anl.gov/~balaji >> >> _______________________________________________ >> 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 -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpiwg-rma] Changes to the RMA chapter
by William Gropp 04 Mar '15

04 Mar '15

That’s an excellent idea - we should use the same language throughout the standard, and the I/O chapter is probably the best source. Bill On Mar 4, 2015, at 4:39 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > Nathan suggested to use the I/O chapter format where info keys are annotated with "[SAME]" to indicate that all processes must provide the same info key. That is probably a ticket-0 change. We need to first agree on whether we want to do this. > > -- Pavan > >> On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> >> Folks at Forum complained about the addition to the "same_size" info key which added the following phrase: >> >> "and that all processes have provided this info key with the same value" >> >> (this change was not a part of any ticket, and was made by the chapter committee) >> >> There were two concerns: >> >> 1. This is a backward incompatible change (as in, applications were not required to give the same value earlier), though folks understood why this is needed. They were OK as long as we add a Errata/Changelog item saying so. >> >> 2. The property that all processes should give the same info key was true for other keys in that section as well (no_locks, accumulate_ordering, accumulate_ops). So the same sentence should be added to them as well. >> >> The Forum wants to see a draft of these changes. I'd like to propose adding the same phrase ("and that all processes have provided this info key with the same value") to the other info keys as well. What do folks think? Is this something that we agree on (technically, it is possible to have different info keys in the job, but it probably doesn't make much sense). >> >> Thoughts? >> >> -- Pavan >> >> -- >> Pavan Balaji ✉️ >> http://www.mcs.anl.gov/~balaji >> >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > 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] Changes to the RMA chapter
by Balaji, Pavan 04 Mar '15

04 Mar '15

Nathan suggested to use the I/O chapter format where info keys are annotated with "[SAME]" to indicate that all processes must provide the same info key. That is probably a ticket-0 change. We need to first agree on whether we want to do this. -- Pavan > On Mar 4, 2015, at 4:37 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > Folks at Forum complained about the addition to the "same_size" info key which added the following phrase: > > "and that all processes have provided this info key with the same value" > > (this change was not a part of any ticket, and was made by the chapter committee) > > There were two concerns: > > 1. This is a backward incompatible change (as in, applications were not required to give the same value earlier), though folks understood why this is needed. They were OK as long as we add a Errata/Changelog item saying so. > > 2. The property that all processes should give the same info key was true for other keys in that section as well (no_locks, accumulate_ordering, accumulate_ops). So the same sentence should be added to them as well. > > The Forum wants to see a draft of these changes. I'd like to propose adding the same phrase ("and that all processes have provided this info key with the same value") to the other info keys as well. What do folks think? Is this something that we agree on (technically, it is possible to have different info keys in the job, but it probably doesn't make much sense). > > Thoughts? > > -- Pavan > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Changes to the RMA chapter
by Balaji, Pavan 04 Mar '15

04 Mar '15

Folks at Forum complained about the addition to the "same_size" info key which added the following phrase: "and that all processes have provided this info key with the same value" (this change was not a part of any ticket, and was made by the chapter committee) There were two concerns: 1. This is a backward incompatible change (as in, applications were not required to give the same value earlier), though folks understood why this is needed. They were OK as long as we add a Errata/Changelog item saying so. 2. The property that all processes should give the same info key was true for other keys in that section as well (no_locks, accumulate_ordering, accumulate_ops). So the same sentence should be added to them as well. The Forum wants to see a draft of these changes. I'd like to propose adding the same phrase ("and that all processes have provided this info key with the same value") to the other info keys as well. What do folks think? Is this something that we agree on (technically, it is possible to have different info keys in the job, but it probably doesn't make much sense). Thoughts? -- Pavan -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpiwg-rma] Ticket #456 Slide on MPI-3 shared memory window synchronization
by Rolf Rabenseifner 04 Mar '15

04 Mar '15

Bill, > It is a summary of the text in new Section 11.5.4A in > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 I used in the slide in the discussion about shared memory RMA here in Portland. It helped us in the question about what the current text of MPI-3.0 and 3.1 says about MPI_WIN_FLUSH - a still un-answered question. Rolf ----- Original Message ----- > From: "wgropp" <wgropp(a)illinois.edu> > To: "MPI WG Remote Memory Access working group" <mpiwg-rma(a)lists.mpi-forum.org> > Cc: "Chulho Kim" <chulho(a)lenovo.com> > Sent: Tuesday, March 3, 2015 9:17:42 PM > Subject: Re: [mpiwg-rma] Ticket #456 Slide on MPI-3 shared memory window synchronization > What text are we talking about? The last entries on this ticket were 3 months > ago, and the consensus at that time was that we needed a different discussion > of this material. > > Bill > > On Mar 3, 2015, at 2:09 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > >> Dear all, >> >> Slide is attached. >> >> It is a summary of the text in new Section 11.5.4A in >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 >> >> 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) >> <mpi_3_rab_shared-memory-ticket456.pptx>_______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

ChangeLog entries for RMA chapter
by Balaji, Pavan 03 Mar '15

03 Mar '15

Hi Rolf, The following two changelog entries are missing for the RMA chapter -- Ticket #433. Proposed changelog entry: Section 11.2.4 on page ??, and MPI-3.0 Section ?? on page ??. Clarify that MPI_WIN_ATTACH must only be for simply contiguous buffers. Ticket #458. Proposed changelog entry (I'm not entirely sure, but maybe this can be ignored): Section 11.3 on page ??, and MPI-3.0 Section ?? on page ??. Clarify that outcome of conflicting accesses to the same memory locations refers to the resulting data values. Thanks, -- Pavan -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpiwg-rma] Ticket #456 Slide on MPI-3 shared memory window synchronization
by William Gropp 03 Mar '15

03 Mar '15

What text are we talking about? The last entries on this ticket were 3 months ago, and the consensus at that time was that we needed a different discussion of this material. Bill On Mar 3, 2015, at 2:09 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Dear all, > > Slide is attached. > > It is a summary of the text in new Section 11.5.4A in > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 > > 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) > <mpi_3_rab_shared-memory-ticket456.pptx>_______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Ticket #456 Slide on MPI-3 shared memory window synchronization
by Rolf Rabenseifner 03 Mar '15

03 Mar '15

Dear all, Slide is attached. It is a summary of the text in new Section 11.5.4A in https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/456 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] Ticket #458
by Jim Dinan 06 Feb '15

06 Feb '15

I believe this ticket exists because an implementer asked if any outcome was allowed, including the machine catching on fire. It seems useful to clarify what we mean by outcome, since we use this term throughout the text. ~Jim. On Fri, Feb 6, 2015 at 12:04 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > I think the chapter committee should handle this. I think the current > text is obvious enough that no one is going to screw it up, but that > the clarification has value and thus should be implemented. > > Best, > > Jeff > > On Fri, Feb 6, 2015 at 8:43 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > Hi All, > > > > The following ticket is marked as MPI 3.0 errata, but appears not to have > > gone forward for a vote: > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/458 > > > > Did we either abandon this or decide that it should be handled by the > > chapter committee? It seems likely that it was the latter and I forgot > to > > update the ticket. Just want to make sure it doesn't get lost in the > > shuffle. > > > > Thanks, > > ~Jim. > > > > ---8<--- > > > > Here is the proposed change. > > > > Existing Text (Pg. 418, line 44): > > > > The outcome of concurrent conflicting accesses to the same memory > locations > > is undefined... > > > > Proposed Change > > > > The resulting data values, or outcome, of concurrent conflicting > accesses to > > the same memory locations is undefined... > > > > _______________________________________________ > > 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