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

Re: [Mpi3-rma] Info accumulate_ops
by Rolf Rabenseifner 20 Oct '12

20 Oct '12

> ... So a valid user program in MPI-2.2 was only > allowed to use the same OP for concurrent accumulates. ... Torsten, I was never aware of this restriction. But you are right: MPI-2.2 page 365 lines 31-33: A location in a window must not be accessed as a target of an RMA operation once an update to that location has started, until the update becomes visible in the public window copy. There is one exception to this rule, in the case where the same variable is updated by two concurrent accumulates that use the same operation, with the same predened datatype, on the same window. Rolf ----- Original Message ----- > From: "Torsten Hoefler" <htor(a)illinois.edu> > To: "MPI 3.0 Remote Memory Access working group" <mpi3-rma(a)lists.mpi-forum.org> > Sent: Friday, October 19, 2012 8:38:21 PM > Subject: Re: [Mpi3-rma] Info accumulate_ops > On Tue, Oct 16, 2012 at 01:35:08PM +0000, Hubert Ritzdorf wrote: > > Hi, > > > > I think that there is a problem in the definition of info > > argument > > "accumulate_ops" of MPI_Win_create functions (Page 406, Line 4-9 > > of MPI 3.0 document). > > > > (*) A value is missing if not all concurrent accumulate calls > > perform the > > same operation. > > Possible values might be: "not_same_op" or "false" > This would be illegal (as described in the semantics section). The > NO_OP > was an exception to allow querying a flag with our "fake atomic reads" > while performing atomic updates CAS etc.. So really only the two > mentioned combinations are legal. > > > (*) The actual default value of "same_op_no_op" breaks the > > backward > > compatibility and causes problems in portability of > > applications, > > since a MPI > > implementation is not required to evaluate (recognize) info > > keys. > > Therefore, "not_same_op" must be the default value of info > > argument > > "accumulate_ops". > Default value means that this is the default semantic if the key is > not > set (or not evaluated). So a valid user program in MPI-2.2 was only > allowed to use the same OP for concurrent accumulates. In MPI-3.0 it > may > use the same op and also NO_OP in addition. Thus, this richer semantic > cannot break backward compatibility. Setting the info key enables the > user to enable the more limited MPI-2.2 semantics which may unlock a > set > of richer optimizations possible in the library. > > Best, > Torsten > > -- > ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- > Torsten Hoefler | Assistant Professor > Dept. of Computer Science | ETH Zürich > Universitätsstrasse 6 | Zurich-8092, Switzerland > CAB E 64.1 | Phone: +41 76 309 79 29 > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: Allmandring 30)

1 0

Re: [Mpi3-rma] Info accumulate_ops
by Torsten Hoefler 19 Oct '12

19 Oct '12

On Tue, Oct 16, 2012 at 01:35:08PM +0000, Hubert Ritzdorf wrote: > Hi, > > I think that there is a problem in the definition of info argument > "accumulate_ops" of MPI_Win_create functions (Page 406, Line 4-9 > of MPI 3.0 document). > > (*) A value is missing if not all concurrent accumulate calls perform the > same operation. > Possible values might be: "not_same_op" or "false" This would be illegal (as described in the semantics section). The NO_OP was an exception to allow querying a flag with our "fake atomic reads" while performing atomic updates CAS etc.. So really only the two mentioned combinations are legal. > (*) The actual default value of "same_op_no_op" breaks the backward > compatibility and causes problems in portability of applications, > since a MPI > implementation is not required to evaluate (recognize) info keys. > Therefore, "not_same_op" must be the default value of info argument > "accumulate_ops". Default value means that this is the default semantic if the key is not set (or not evaluated). So a valid user program in MPI-2.2 was only allowed to use the same OP for concurrent accumulates. In MPI-3.0 it may use the same op and also NO_OP in addition. Thus, this richer semantic cannot break backward compatibility. Setting the info key enables the user to enable the more limited MPI-2.2 semantics which may unlock a set of richer optimizations possible in the library. Best, Torsten -- ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- Torsten Hoefler | Assistant Professor Dept. of Computer Science | ETH Zï¿½rich Universitï¿½tsstrasse 6 | Zurich-8092, Switzerland CAB E 64.1 | Phone: +41 76 309 79 29

1 0

Re: [Mpi3-rma] Info accumulate_ops
by Sur, Sayantan 19 Oct '12

19 Oct '12

I had raised this issue during the chapter review. It felt odd to me that the default was for some optimized behavior which can potentially lead to erroneous results in case the program doesn't obey this behavior. MPI-3: "This can eliminate the need to protect access for certain operation types where the hardware can guarantee atomicity." It appears MPI-2 had the same restriction on concurrent ops, just not through an info key though. MPI-2.2, 11.7, Pg 365, line 29-34: "A location in a window must not be accessed as a target of an RMA operation once an update to that location has started, until the update becomes visible in the public window copy. There is one exception to this rule, in the case where the same variable is updated by two concurrent accumulates that use the same operation, with the same predefined datatype, on the same window." === Sayantan Sur, Ph.D. Intel Corp. > -----Original Message----- > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > bounces(a)lists.mpi-forum.org] On Behalf Of Rolf Rabenseifner > Sent: Friday, October 19, 2012 7:25 AM > To: MPI 3.0 Remote Memory Access working group > Subject: Re: [Mpi3-rma] Info accumulate_ops > > I would like to see an errata proposal from the RMA group. > - It is unclear, what does it mean, not to use the > info accumulate_ops. > Info keywords cannot have a default value > because you must define the keyword always > together with a value. > - It is unclear which value would be returned with info_get > if an MPI library handles this keyword, but > the application has not set it. > - It is unclear which behavior we have when an MPI library > does not support this info: Is it MPI-2.2 behavior? > > Best regards > Rolf > > ----- Original Message ----- > > From: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com> > > To: mpi3-rma(a)lists.mpi-forum.org > > Sent: Tuesday, October 16, 2012 3:35:08 PM > > Subject: [Mpi3-rma] Info accumulate_ops Hi, > > > > I think that there is a problem in the definition of info argument > > "accumulate_ops" of MPI_Win_create functions (Page 406, Line 4-9 of > > MPI 3.0 document). > > > > (*) A value is missing if not all concurrent accumulate calls perform > > the same operation. > > Possible values might be: "not_same_op" or "false" > > (*) The actual default value of "same_op_no_op" breaks the backward > > compatibility and causes problems in portability of applications, > > since a MPI implementation is not required to evaluate (recognize) > > info keys. > > Therefore, "not_same_op" must be the default value of info argument > > "accumulate_ops". > > > > Hubert > > > > > > > > _______________________________________________ > > mpi3-rma mailing list > > mpi3-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: Allmandring 30) > _______________________________________________ > 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] Info accumulate_ops
by Rolf Rabenseifner 19 Oct '12

19 Oct '12

I would like to see an errata proposal from the RMA group. - It is unclear, what does it mean, not to use the info accumulate_ops. Info keywords cannot have a default value because you must define the keyword always together with a value. - It is unclear which value would be returned with info_get if an MPI library handles this keyword, but the application has not set it. - It is unclear which behavior we have when an MPI library does not support this info: Is it MPI-2.2 behavior? Best regards Rolf ----- Original Message ----- > From: "Hubert Ritzdorf" <Hubert.Ritzdorf(a)emea.nec.com> > To: mpi3-rma(a)lists.mpi-forum.org > Sent: Tuesday, October 16, 2012 3:35:08 PM > Subject: [Mpi3-rma] Info accumulate_ops > Hi, > > I think that there is a problem in the definition of info argument > "accumulate_ops" of MPI_Win_create functions (Page 406, Line 4-9 > of MPI 3.0 document). > > (*) A value is missing if not all concurrent accumulate calls perform > the > same operation. > Possible values might be: "not_same_op" or "false" > (*) The actual default value of "same_op_no_op" breaks the backward > compatibility and causes problems in portability of applications, > since a MPI > implementation is not required to evaluate (recognize) info keys. > Therefore, "not_same_op" must be the default value of info argument > "accumulate_ops". > > Hubert > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-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: Allmandring 30)

1 0

[Mpi3-rma] Info accumulate_ops
by Hubert Ritzdorf 16 Oct '12

16 Oct '12

Hi, I think that there is a problem in the definition of info argument "accumulate_ops" of MPI_Win_create functions (Page 406, Line 4-9 of MPI 3.0 document). (*) A value is missing if not all concurrent accumulate calls perform the same operation. Possible values might be: "not_same_op" or "false" (*) The actual default value of "same_op_no_op" breaks the backward compatibility and causes problems in portability of applications, since a MPI implementation is not required to evaluate (recognize) info keys. Therefore, "not_same_op" must be the default value of info argument "accumulate_ops". Hubert

1 0

Re: [Mpi3-rma] FW: MPI_Accumulate
by Underwood, Keith D 02 Oct '12

02 Oct '12

Yeah, because I was certainly advocating that implementations write the string "Jeff said to write POOP here" over and over into conflicting write areas. After all, we wouldn't want users to get used to some non-compliant behavior ;-) > -----Original Message----- > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > bounces(a)lists.mpi-forum.org] On Behalf Of Pavan Balaji > Sent: Tuesday, October 02, 2012 2:29 PM > To: MPI 3.0 Remote Memory Access working group > Cc: MPI 3.0 Remote Memory Access working group > Subject: Re: [Mpi3-rma] FW: MPI_Accumulate > > > Let's not mix what an implementation might (and will likely) do with what the > standard specifies. > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > On Oct 2, 2012, at 1:26 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > > > Okay, sorry, I was assuming that no one makes hardware that is less > > than byte-wise atomic. I suppose an implementation could do as I > > suggested at some point and write the bit representation of "POOP" to > > memory for conflicting writes, but this seems like it would be slower > > than just doing conflicting writes and letting the memory controller > > figure it out. > > > > Jeff > > > > On Tue, Oct 2, 2012 at 1:22 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > >> > >> Put is not byte wise atomic. It is not atomic at all. Only the accumulate- > style operations are predefined datatype granularity atomic. > >> > >> -- > >> Pavan Balaji > >> http://www.mcs.anl.gov/~balaji > >> > >> On Oct 2, 2012, at 11:48 AM, Jeff Hammond <jhammond(a)alcf.anl.gov> > wrote: > >> > >>> My understanding has always been that MPI_Accumulate was and is > >>> atomic at granularity of the underlying built-in datatype, as > >>> opposed to byte-wise atomic like MPI_Put. This is the whole reason > >>> that MPI_Accumulate w/ MPI_REPLACE exists. Without the additional > >>> atomicity guarantee, that feature would be pointless. > >>> > >>> Jeff > >>> > >>> On Tue, Oct 2, 2012 at 11:38 AM, Richard Graham > <richardg(a)mellanox.com> wrote: > >>>> resending > >>>> > >>>> > >>>> > >>>> From: Richard Graham > >>>> Sent: Tuesday, October 02, 2012 12:22 PM > >>>> To: MPI 3.0 Remote Memory Access working group > >>>> (mpi3-rma(a)lists.mpi-forum.org) > >>>> Subject: MPI_Accumulate > >>>> > >>>> > >>>> > >>>> What are the requirements placed on MPI_Accumulate if more than > one > >>>> mpi process tries to update the same location ? Does MPI provide > >>>> any consistency promises, or is it up to the application to > >>>> guarantee these ? I see that the get accumulate routines are > >>>> defined to be atomic, but don’t see the same requirement for > accumulate. > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Rich > >>>> > >>>> > >>>> _______________________________________________ > >>>> mpi3-rma mailing list > >>>> mpi3-rma(a)lists.mpi-forum.org > >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > >>> > >>> > >>> > >>> -- > >>> Jeff Hammond > >>> Argonne Leadership Computing Facility University of Chicago > >>> Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 > >>> http://www.linkedin.com/in/jeffhammond > >>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > >>> > >>> _______________________________________________ > >>> mpi3-rma mailing list > >>> mpi3-rma(a)lists.mpi-forum.org > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > >> > >> _______________________________________________ > >> mpi3-rma mailing list > >> mpi3-rma(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > > > > > > -- > > Jeff Hammond > > Argonne Leadership Computing Facility > > University of Chicago Computation Institute jhammond(a)alcf.anl.gov / > > (630) 252-5381 http://www.linkedin.com/in/jeffhammond > > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > > > > _______________________________________________ > > mpi3-rma mailing list > > mpi3-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > 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] FW: MPI_Accumulate
by Pavan Balaji 02 Oct '12

02 Oct '12

Let's not mix what an implementation might (and will likely) do with what the standard specifies. -- Pavan Balaji http://www.mcs.anl.gov/~balaji On Oct 2, 2012, at 1:26 PM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > Okay, sorry, I was assuming that no one makes hardware that is less > than byte-wise atomic. I suppose an implementation could do as I > suggested at some point and write the bit representation of "POOP" to > memory for conflicting writes, but this seems like it would be slower > than just doing conflicting writes and letting the memory controller > figure it out. > > Jeff > > On Tue, Oct 2, 2012 at 1:22 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >> >> Put is not byte wise atomic. It is not atomic at all. Only the accumulate-style operations are predefined datatype granularity atomic. >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji >> >> On Oct 2, 2012, at 11:48 AM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: >> >>> My understanding has always been that MPI_Accumulate was and is atomic >>> at granularity of the underlying built-in datatype, as opposed to >>> byte-wise atomic like MPI_Put. This is the whole reason that >>> MPI_Accumulate w/ MPI_REPLACE exists. Without the additional >>> atomicity guarantee, that feature would be pointless. >>> >>> Jeff >>> >>> On Tue, Oct 2, 2012 at 11:38 AM, Richard Graham <richardg(a)mellanox.com> wrote: >>>> resending >>>> >>>> >>>> >>>> From: Richard Graham >>>> Sent: Tuesday, October 02, 2012 12:22 PM >>>> To: MPI 3.0 Remote Memory Access working group >>>> (mpi3-rma(a)lists.mpi-forum.org) >>>> Subject: MPI_Accumulate >>>> >>>> >>>> >>>> What are the requirements placed on MPI_Accumulate if more than one mpi >>>> process tries to update the same location ? Does MPI provide any >>>> consistency promises, or is it up to the application to guarantee these ? I >>>> see that the get accumulate routines are defined to be atomic, but don’t see >>>> the same requirement for accumulate. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Rich >>>> >>>> >>>> _______________________________________________ >>>> mpi3-rma mailing list >>>> mpi3-rma(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>> >>> >>> >>> -- >>> Jeff Hammond >>> Argonne Leadership Computing Facility >>> University of Chicago Computation Institute >>> jhammond(a)alcf.anl.gov / (630) 252-5381 >>> http://www.linkedin.com/in/jeffhammond >>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >>> >>> _______________________________________________ >>> mpi3-rma mailing list >>> mpi3-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > > _______________________________________________ > 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] FW: MPI_Accumulate
by Jeff Hammond 02 Oct '12

02 Oct '12

Okay, sorry, I was assuming that no one makes hardware that is less than byte-wise atomic. I suppose an implementation could do as I suggested at some point and write the bit representation of "POOP" to memory for conflicting writes, but this seems like it would be slower than just doing conflicting writes and letting the memory controller figure it out. Jeff On Tue, Oct 2, 2012 at 1:22 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > Put is not byte wise atomic. It is not atomic at all. Only the accumulate-style operations are predefined datatype granularity atomic. > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > On Oct 2, 2012, at 11:48 AM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > >> My understanding has always been that MPI_Accumulate was and is atomic >> at granularity of the underlying built-in datatype, as opposed to >> byte-wise atomic like MPI_Put. This is the whole reason that >> MPI_Accumulate w/ MPI_REPLACE exists. Without the additional >> atomicity guarantee, that feature would be pointless. >> >> Jeff >> >> On Tue, Oct 2, 2012 at 11:38 AM, Richard Graham <richardg(a)mellanox.com> wrote: >>> resending >>> >>> >>> >>> From: Richard Graham >>> Sent: Tuesday, October 02, 2012 12:22 PM >>> To: MPI 3.0 Remote Memory Access working group >>> (mpi3-rma(a)lists.mpi-forum.org) >>> Subject: MPI_Accumulate >>> >>> >>> >>> What are the requirements placed on MPI_Accumulate if more than one mpi >>> process tries to update the same location ? Does MPI provide any >>> consistency promises, or is it up to the application to guarantee these ? I >>> see that the get accumulate routines are defined to be atomic, but donï¿½t see >>> the same requirement for accumulate. >>> >>> >>> >>> Thanks, >>> >>> Rich >>> >>> >>> _______________________________________________ >>> mpi3-rma mailing list >>> mpi3-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> >> >> -- >> Jeff Hammond >> Argonne Leadership Computing Facility >> University of Chicago Computation Institute >> jhammond(a)alcf.anl.gov / (630) 252-5381 >> http://www.linkedin.com/in/jeffhammond >> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [Mpi3-rma] FW: MPI_Accumulate
by Pavan Balaji 02 Oct '12

02 Oct '12

Put is not byte wise atomic. It is not atomic at all. Only the accumulate-style operations are predefined datatype granularity atomic. -- Pavan Balaji http://www.mcs.anl.gov/~balaji On Oct 2, 2012, at 11:48 AM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > My understanding has always been that MPI_Accumulate was and is atomic > at granularity of the underlying built-in datatype, as opposed to > byte-wise atomic like MPI_Put. This is the whole reason that > MPI_Accumulate w/ MPI_REPLACE exists. Without the additional > atomicity guarantee, that feature would be pointless. > > Jeff > > On Tue, Oct 2, 2012 at 11:38 AM, Richard Graham <richardg(a)mellanox.com> wrote: >> resending >> >> >> >> From: Richard Graham >> Sent: Tuesday, October 02, 2012 12:22 PM >> To: MPI 3.0 Remote Memory Access working group >> (mpi3-rma(a)lists.mpi-forum.org) >> Subject: MPI_Accumulate >> >> >> >> What are the requirements placed on MPI_Accumulate if more than one mpi >> process tries to update the same location ? Does MPI provide any >> consistency promises, or is it up to the application to guarantee these ? I >> see that the get accumulate routines are defined to be atomic, but don’t see >> the same requirement for accumulate. >> >> >> >> Thanks, >> >> Rich >> >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > > _______________________________________________ > 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] FW: MPI_Accumulate
by Richard Graham 02 Oct '12

02 Oct '12

Thanks -----Original Message----- From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Hammond Sent: Tuesday, October 02, 2012 12:52 PM To: MPI 3.0 Remote Memory Access working group Subject: Re: [Mpi3-rma] FW: MPI_Accumulate MPI-3 11.7.1 describes the atomicity of accumulate. Jeff On Tue, Oct 2, 2012 at 11:48 AM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > My understanding has always been that MPI_Accumulate was and is atomic > at granularity of the underlying built-in datatype, as opposed to > byte-wise atomic like MPI_Put. This is the whole reason that > MPI_Accumulate w/ MPI_REPLACE exists. Without the additional > atomicity guarantee, that feature would be pointless. > > Jeff > > On Tue, Oct 2, 2012 at 11:38 AM, Richard Graham <richardg(a)mellanox.com> wrote: >> resending >> >> >> >> From: Richard Graham >> Sent: Tuesday, October 02, 2012 12:22 PM >> To: MPI 3.0 Remote Memory Access working group >> (mpi3-rma(a)lists.mpi-forum.org) >> Subject: MPI_Accumulate >> >> >> >> What are the requirements placed on MPI_Accumulate if more than one >> mpi process tries to update the same location ? Does MPI provide any >> consistency promises, or is it up to the application to guarantee >> these ? I see that the get accumulate routines are defined to be >> atomic, but don't see the same requirement for accumulate. >> >> >> >> Thanks, >> >> Rich >> >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute jhammond(a)alcf.anl.gov / > (630) 252-5381 http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0