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

Re: [mpiwg-rma] same_op_no_op
by Balaji, Pavan 10 Mar '14

10 Mar '14

It doesn’t break backward compatibility. The info argument is still useful when you don’t want to use replace. I don’t see anything wrong with it. On Mar 10, 2014, at 11:01 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Does this or does this not break BW compatibility w.r.t. MPI-2.2 and > did we do it intentionally? Unless we did so intentionally and > explicitly, I will argue that the WG screwed up and the info key+val > is invalid. > > Jeff > > On Mon, Mar 10, 2014 at 11:03 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> If a hardware can implement MPI_SUM, it should be able to implement MPI_SUM with 0 as well. >> >> But that’s not a generic solution. >> >> Jeff: at some point you were planning to bring in a ticket which does more combinations of operations than just same_op and no_op. Maybe it’s worthwhile bringing that up again? >> >> — Pavan >> >> On Mar 10, 2014, at 9:26 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: >> >>> Maybe there's a loophole that I'm forgetting? >>> >>> >>> On Mon, Mar 10, 2014 at 9:43 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> How the hell can I do GA or SHMEM then? Roll my own mutexes and commit perf-suicide? >>> >>> Jeff >>> >>> Sent from my iPhone >>> >>> On Mar 10, 2014, at 8:32 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: >>> >>>> You can't use replace and sum concurrently at a given target address. >>>> >>>> ~Jim. >>>> >>>> On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>> Given the following, how do I use MPI_NO_OP, MPI_REPLACE and MPI_SUM >>>> in accumulate/atomic operations in a standard-compliant way? >>>> >>>> accumulate_ops — if set to same_op, the implementation will assume >>>> that all concurrent accumulate calls to the same target address will >>>> use the same operation. If set to same_op_no_op, then the >>>> implementation will assume that all concurrent accumulate calls to the >>>> same target address will use the same operation or MPI_NO_OP. This can >>>> eliminate the need to protect access for certain operation types where >>>> the hardware can guarantee atomicity. The default is same_op_no_op. >>>> >>>> We discuss this before and the resolution was not satisfying to me. >>>> >>>> Thanks, >>>> >>>> Jeff >>>> >>>> -- >>>> Jeff Hammond >>>> jeff.science(a)gmail.com >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > _______________________________________________ > 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] same_op_no_op
by Jeff Hammond 10 Mar '14

10 Mar '14

Does this or does this not break BW compatibility w.r.t. MPI-2.2 and did we do it intentionally? Unless we did so intentionally and explicitly, I will argue that the WG screwed up and the info key+val is invalid. Jeff On Mon, Mar 10, 2014 at 11:03 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > If a hardware can implement MPI_SUM, it should be able to implement MPI_SUM with 0 as well. > > But that’s not a generic solution. > > Jeff: at some point you were planning to bring in a ticket which does more combinations of operations than just same_op and no_op. Maybe it’s worthwhile bringing that up again? > > — Pavan > > On Mar 10, 2014, at 9:26 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > >> Maybe there's a loophole that I'm forgetting? >> >> >> On Mon, Mar 10, 2014 at 9:43 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> How the hell can I do GA or SHMEM then? Roll my own mutexes and commit perf-suicide? >> >> Jeff >> >> Sent from my iPhone >> >> On Mar 10, 2014, at 8:32 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: >> >>> You can't use replace and sum concurrently at a given target address. >>> >>> ~Jim. >>> >>> On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> Given the following, how do I use MPI_NO_OP, MPI_REPLACE and MPI_SUM >>> in accumulate/atomic operations in a standard-compliant way? >>> >>> accumulate_ops — if set to same_op, the implementation will assume >>> that all concurrent accumulate calls to the same target address will >>> use the same operation. If set to same_op_no_op, then the >>> implementation will assume that all concurrent accumulate calls to the >>> same target address will use the same operation or MPI_NO_OP. This can >>> eliminate the need to protect access for certain operation types where >>> the hardware can guarantee atomicity. The default is same_op_no_op. >>> >>> We discuss this before and the resolution was not satisfying to me. >>> >>> Thanks, >>> >>> Jeff >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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

1 0

Re: [mpiwg-rma] same_op_no_op
by Balaji, Pavan 10 Mar '14

10 Mar '14

If a hardware can implement MPI_SUM, it should be able to implement MPI_SUM with 0 as well. But that’s not a generic solution. Jeff: at some point you were planning to bring in a ticket which does more combinations of operations than just same_op and no_op. Maybe it’s worthwhile bringing that up again? — Pavan On Mar 10, 2014, at 9:26 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Maybe there's a loophole that I'm forgetting? > > > On Mon, Mar 10, 2014 at 9:43 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > How the hell can I do GA or SHMEM then? Roll my own mutexes and commit perf-suicide? > > Jeff > > Sent from my iPhone > > On Mar 10, 2014, at 8:32 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > >> You can't use replace and sum concurrently at a given target address. >> >> ~Jim. >> >> On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> Given the following, how do I use MPI_NO_OP, MPI_REPLACE and MPI_SUM >> in accumulate/atomic operations in a standard-compliant way? >> >> accumulate_ops — if set to same_op, the implementation will assume >> that all concurrent accumulate calls to the same target address will >> use the same operation. If set to same_op_no_op, then the >> implementation will assume that all concurrent accumulate calls to the >> same target address will use the same operation or MPI_NO_OP. This can >> eliminate the need to protect access for certain operation types where >> the hardware can guarantee atomicity. The default is same_op_no_op. >> >> We discuss this before and the resolution was not satisfying to me. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> _______________________________________________ >> 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 > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] same_op_no_op
by Jim Dinan 10 Mar '14

10 Mar '14

Maybe there's a loophole that I'm forgetting? On Mon, Mar 10, 2014 at 9:43 PM, Jeff Hammond <jeff.science(a)gmail.com>wrote: > How the hell can I do GA or SHMEM then? Roll my own mutexes and commit > perf-suicide? > > Jeff > > Sent from my iPhone > > On Mar 10, 2014, at 8:32 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > You can't use replace and sum concurrently at a given target address. > > ~Jim. > > On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond <jeff.science(a)gmail.com>wrote: > >> Given the following, how do I use MPI_NO_OP, MPI_REPLACE and MPI_SUM >> in accumulate/atomic operations in a standard-compliant way? >> >> accumulate_ops -- if set to same_op, the implementation will assume >> that all concurrent accumulate calls to the same target address will >> use the same operation. If set to same_op_no_op, then the >> implementation will assume that all concurrent accumulate calls to the >> same target address will use the same operation or MPI_NO_OP. This can >> eliminate the need to protect access for certain operation types where >> the hardware can guarantee atomicity. The default is same_op_no_op. >> >> We discuss this before and the resolution was not satisfying to me. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> _______________________________________________ >> 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 > > > _______________________________________________ > 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] same_op_no_op
by Jeff Hammond 10 Mar '14

10 Mar '14

How the hell can I do GA or SHMEM then? Roll my own mutexes and commit perf-suicide? Jeff Sent from my iPhone > On Mar 10, 2014, at 8:32 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > You can't use replace and sum concurrently at a given target address. > > ~Jim. > >> On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> Given the following, how do I use MPI_NO_OP, MPI_REPLACE and MPI_SUM >> in accumulate/atomic operations in a standard-compliant way? >> >> accumulate_ops — if set to same_op, the implementation will assume >> that all concurrent accumulate calls to the same target address will >> use the same operation. If set to same_op_no_op, then the >> implementation will assume that all concurrent accumulate calls to the >> same target address will use the same operation or MPI_NO_OP. This can >> eliminate the need to protect access for certain operation types where >> the hardware can guarantee atomicity. The default is same_op_no_op. >> >> We discuss this before and the resolution was not satisfying to me. >> >> Thanks, >> >> Jeff >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> _______________________________________________ >> mpiwg-rma mailing list >> mpiwg-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

Re: [mpiwg-rma] same_op_no_op
by Jim Dinan 10 Mar '14

10 Mar '14

You can't use replace and sum concurrently at a given target address. ~Jim. On Mon, Mar 10, 2014 at 4:30 PM, Jeff Hammond <jeff.science(a)gmail.com>wrote: > Given the following, how do I use MPI_NO_OP, MPI_REPLACE and MPI_SUM > in accumulate/atomic operations in a standard-compliant way? > > accumulate_ops -- if set to same_op, the implementation will assume > that all concurrent accumulate calls to the same target address will > use the same operation. If set to same_op_no_op, then the > implementation will assume that all concurrent accumulate calls to the > same target address will use the same operation or MPI_NO_OP. This can > eliminate the need to protect access for certain operation types where > the hardware can guarantee atomicity. The default is same_op_no_op. > > We discuss this before and the resolution was not satisfying to me. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

same_op_no_op
by Jeff Hammond 10 Mar '14

10 Mar '14

Given the following, how do I use MPI_NO_OP, MPI_REPLACE and MPI_SUM in accumulate/atomic operations in a standard-compliant way? accumulate_ops — if set to same_op, the implementation will assume that all concurrent accumulate calls to the same target address will use the same operation. If set to same_op_no_op, then the implementation will assume that all concurrent accumulate calls to the same target address will use the same operation or MPI_NO_OP. This can eliminate the need to protect access for certain operation types where the hardware can guarantee atomicity. The default is same_op_no_op. We discuss this before and the resolution was not satisfying to me. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

AM papers
by Balaji, Pavan 04 Mar '14

04 Mar '14

Hello, Some of you had asked about the AM papers we published recently. Here they are: The AM model: http://www.mcs.anl.gov/~balaji/pubs/2013/icpads/icpads13.am.pdf Asychronous progress in AM: http://www.mcs.anl.gov/~balaji/pubs/2013/ccgrid/ccgrid13.am.pdf AM optimizations: http://www.mcs.anl.gov/~balaji/pubs/2013/scalcom/scalcom13.am.pdf The paper on CAF over MPI-3, which had an issue with missing AM support in MPI is here: CAF over MPI-3: http://www.mcs.anl.gov/~balaji/pubs/2014/ppopp/ppopp14.caf-mpi.pdf Thanks, — Pavan

1 0

Re: [mpiwg-rma] Inconsistency of MPI_WIN_FENCE semantic
by Jim Dinan 26 Feb '14

26 Feb '14

I tend to agree with this, the wording is misleading, but not incorrect. There is a third implementation that has been only implicitly mentioned. The synchronization that the spec requires to start the access epoch is weaker than a barrier. A point-to-point synchronization between origin and target is what is required by the standard. This is achieved with the deferred implementation or potentially by piggybacking when RMA is done through eager send/recv (which is not such a bad option for active target). If you want to use RDMA, you could initiate the access epoch with a point-to-point synchronization first (send/recv ping-pong, RDMA read of a flag on the window, etc), before accessing the target window. ~Jim. On Wed, Feb 26, 2014 at 12:39 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > Assuming your interpretation is right, the statement is not incorrect. At > this point it is just a matter of taste and not something the standard > needs to fix anyway. > > -- Pavan > > On Feb 25, 2014, at 11:36 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > > > I don't find it confusing. It makes the case where the barrier is not > needed even more clear. > > > > In the example below, if the second fence didn't have a NOPRECEDE, even > a deferred implementation will need to do a barrier because it doesn't know > if the process is a target of RMA operations from other processes. > > > > If NOPRECEDE is called, it must be called on all processes, so then it > is clear that no one is doing RMA. > > > > So "in particular" might in fact be better than "for example". > > > > > > On Feb 25, 2014, at 11:25 PM, "Balaji, Pavan" <balaji(a)anl.gov> > > wrote: > > > >> > >> Why do you want that MPI_MODE_NOPRECEDE? What's its purpose? > >> > >> -- Pavan > >> > >> On Feb 25, 2014, at 11:24 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > >> > >>> Instead of "in particular" if it said "for example, a call with assert > equal to MPI_MODE_NOPRECEDE" would it help? > >>> > >>> On Feb 25, 2014, at 11:14 PM, "Balaji, Pavan" <balaji(a)anl.gov> > >>> wrote: > >>> > >>>> > >>>> If that was indeed the intention, then the wording is very > unfortunate. I'd recommend not having the mention of MPI_MODE_NOPRECEDE at > all. It serves no real purpose and ends up confusing things. > >>>> > >>>> -- Pavan > >>>> > >>>> On Feb 25, 2014, at 11:09 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> > wrote: > >>>> > >>>>> It means to say that in the example below, the second fence (which > does not end any epoch) does not necessarily act as a barrier. The > NOPRECEDE makes it very clear (and hence the "in particular a call with > assert=NOPRECEDE") that no RMA calls were issued prior to that fence. > >>>>> > >>>>> Fence > >>>>> x=1 > >>>>> Fence(NOPRECEDE) > >>>>> Put > >>>>> Fence > >>>>> > >>>>> Note that a fence "completes an RMA access epoch if it was preceded > by another fence call and the local process issued RMA communication calls > on win between these two calls. The call completes an RMA exposure epoch > if it was preceded by another fence call and the local window was the > target of RMA accesses between these two calls." > >>>>> > >>>>> So the second fence does not complete any epoch, which the user has > made even more clear with the assert, and so it need not be a barrier. > >>>>> > >>>>> > >>>>> On Feb 25, 2014, at 10:58 PM, "Balaji, Pavan" <balaji(a)anl.gov> > >>>>> wrote: > >>>>> > >>>>>> > >>>>>> Then the following sentence in the standard is weird: > >>>>>> > >>>>>> "a call to MPI_WIN_FENCE that is known not to end any epoch (in > particular a call with assert equal to MPI_MODE_NOPRECEDE) does not > necessarily act as a barrier" > >>>>>> > >>>>>> Why this special treatment for NOPRECEDE as no WIN_FENCE has > barrier semantics? > >>>>>> > >>>>>> -- Pavan > >>>>>> > >>>>>> On Feb 25, 2014, at 10:54 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> > wrote: > >>>>>> > >>>>>>> Agreed that the handshake can't be done in the RMA operation. > >>>>>>> > >>>>>>> If you choose to implement fence eagerly, i.e., perform RMA ops as > they are called, the first fence will have to be a barrier. > >>>>>>> > >>>>>>> But if you choose to implement the deferred fence, the first fence > and all RMA ops can be deferred until the fence that completes the epoch. > >>>>>>> > >>>>>>> > >>>>>>> On Feb 25, 2014, at 10:46 PM, "Zhao, Xin" <xinzhao3(a)illinois.edu> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> I agree with this. If the handshake is done in the first RMA > operation after the fence, then that operation becomes blocking. In > Standard P418 it says all communication calls are non-blocking. > >>>>>>>> > >>>>>>>> Xin > >>>>>>>> ________________________________________ > >>>>>>>> From: mpiwg-rma [mpiwg-rma-bounces(a)lists.mpi-forum.org] on > behalf of Balaji, Pavan [balaji(a)anl.gov] > >>>>>>>> Sent: Tuesday, February 25, 2014 9:38 PM > >>>>>>>> To: MPI WG Remote Memory Access working group > >>>>>>>> Subject: Re: [mpiwg-rma] Inconsistency of MPI_WIN_FENCE semantic > >>>>>>>> > >>>>>>>> In practice, it'll need to have barrier semantics. Otherwise, > PUT will need to be a two-sided operation to ensure that it's not issued > before the other process calls MPI_WIN_FENCE. > >>>>>>>> > >>>>>>>> -- Pavan > >>>>>>>> > >>>>>>>> On Feb 25, 2014, at 9:21 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> > wrote: > >>>>>>>> > >>>>>>>>>> (1) On P440-P441 it say that "RMA operations on win started by > a process after the fence call returns will access their target window only > after MPI_WIN_FENCE has been called by the target process". This requires > MPI_WIN_FENCE that starts an epoch to act as an barrier. > >>>>>>>>> > >>>>>>>>> It only says "RMA operations on win started by a process after > the fence call returns will access their target window only after > MPI_WIN_FENCE has been called by the target process". NOT "This > requires MPI_WIN_FENCE that starts an epoch to act as an barrier." > >>>>>>>>> > >>>>>>>>> Why does the fence have to act as a barrier. The handshake could > be done when first RMA operation is called after the fence. > >>>>>>>>> > >>>>>>>>> Rajeev > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Feb 25, 2014, at 8:41 PM, "Zhao, Xin" <xinzhao3(a)illinois.edu> > wrote: > >>>>>>>>> > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> There is an inconsistency of MPI_WIN_FENCE semantic in MPI 3.0 > Standard that makes me confused: > >>>>>>>>>> > >>>>>>>>>> (1) On P440-P441 it say that "RMA operations on win started by > a process after the fence call returns will access their target window only > after MPI_WIN_FENCE has been called by the target process". This requires > MPI_WIN_FENCE that starts an epoch to act as an barrier. > >>>>>>>>>> > >>>>>>>>>> (2) However, (1) contradict with the word at end of P441: "a > call to MPI_WIN_FENCE that is known not to end any epoch (in particular a > call with assert equal to MPI_MODE_NOPRECEDE) does not necessarily act as a > barrier". > >>>>>>>>>> > >>>>>>>>>> Should the word of (1) add: "when MPI_MODE_NOPRECEDE is not > given"? > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Xin > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> 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 > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > > mpiwg-rma mailing list > > mpiwg-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >

1 0

Re: [mpiwg-rma] Inconsistency of MPI_WIN_FENCE semantic
by Balaji, Pavan 25 Feb '14

25 Feb '14

Assuming your interpretation is right, the statement is not incorrect. At this point it is just a matter of taste and not something the standard needs to fix anyway. — Pavan On Feb 25, 2014, at 11:36 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > I don't find it confusing. It makes the case where the barrier is not needed even more clear. > > In the example below, if the second fence didn't have a NOPRECEDE, even a deferred implementation will need to do a barrier because it doesn't know if the process is a target of RMA operations from other processes. > > If NOPRECEDE is called, it must be called on all processes, so then it is clear that no one is doing RMA. > > So "in particular" might in fact be better than "for example". > > > On Feb 25, 2014, at 11:25 PM, "Balaji, Pavan" <balaji(a)anl.gov> > wrote: > >> >> Why do you want that MPI_MODE_NOPRECEDE? What’s its purpose? >> >> — Pavan >> >> On Feb 25, 2014, at 11:24 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >> >>> Instead of "in particular" if it said "for example, a call with assert equal to MPI_MODE_NOPRECEDE" would it help? >>> >>> On Feb 25, 2014, at 11:14 PM, "Balaji, Pavan" <balaji(a)anl.gov> >>> wrote: >>> >>>> >>>> If that was indeed the intention, then the wording is very unfortunate. I’d recommend not having the mention of MPI_MODE_NOPRECEDE at all. It serves no real purpose and ends up confusing things. >>>> >>>> — Pavan >>>> >>>> On Feb 25, 2014, at 11:09 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >>>> >>>>> It means to say that in the example below, the second fence (which does not end any epoch) does not necessarily act as a barrier. The NOPRECEDE makes it very clear (and hence the "in particular a call with assert=NOPRECEDE") that no RMA calls were issued prior to that fence. >>>>> >>>>> Fence >>>>> x=1 >>>>> Fence(NOPRECEDE) >>>>> Put >>>>> Fence >>>>> >>>>> Note that a fence "completes an RMA access epoch if it was preceded by another fence call and the local process issued RMA communication calls on win between these two calls. The call completes an RMA exposure epoch if it was preceded by another fence call and the local window was the target of RMA accesses between these two calls." >>>>> >>>>> So the second fence does not complete any epoch, which the user has made even more clear with the assert, and so it need not be a barrier. >>>>> >>>>> >>>>> On Feb 25, 2014, at 10:58 PM, "Balaji, Pavan" <balaji(a)anl.gov> >>>>> wrote: >>>>> >>>>>> >>>>>> Then the following sentence in the standard is weird: >>>>>> >>>>>> "a call to MPI_WIN_FENCE that is known not to end any epoch (in particular a call with assert equal to MPI_MODE_NOPRECEDE) does not necessarily act as a barrier” >>>>>> >>>>>> Why this special treatment for NOPRECEDE as no WIN_FENCE has barrier semantics? >>>>>> >>>>>> — Pavan >>>>>> >>>>>> On Feb 25, 2014, at 10:54 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >>>>>> >>>>>>> Agreed that the handshake can't be done in the RMA operation. >>>>>>> >>>>>>> If you choose to implement fence eagerly, i.e., perform RMA ops as they are called, the first fence will have to be a barrier. >>>>>>> >>>>>>> But if you choose to implement the deferred fence, the first fence and all RMA ops can be deferred until the fence that completes the epoch. >>>>>>> >>>>>>> >>>>>>> On Feb 25, 2014, at 10:46 PM, "Zhao, Xin" <xinzhao3(a)illinois.edu> >>>>>>> wrote: >>>>>>> >>>>>>>> I agree with this. If the handshake is done in the first RMA operation after the fence, then that operation becomes blocking. In Standard P418 it says all communication calls are non-blocking. >>>>>>>> >>>>>>>> Xin >>>>>>>> ________________________________________ >>>>>>>> From: mpiwg-rma [mpiwg-rma-bounces(a)lists.mpi-forum.org] on behalf of Balaji, Pavan [balaji(a)anl.gov] >>>>>>>> Sent: Tuesday, February 25, 2014 9:38 PM >>>>>>>> To: MPI WG Remote Memory Access working group >>>>>>>> Subject: Re: [mpiwg-rma] Inconsistency of MPI_WIN_FENCE semantic >>>>>>>> >>>>>>>> In practice, it’ll need to have barrier semantics. Otherwise, PUT will need to be a two-sided operation to ensure that it’s not issued before the other process calls MPI_WIN_FENCE. >>>>>>>> >>>>>>>> — Pavan >>>>>>>> >>>>>>>> On Feb 25, 2014, at 9:21 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >>>>>>>> >>>>>>>>>> (1) On P440-P441 it say that "RMA operations on win started by a process after the fence call returns will access their target window only after MPI_WIN_FENCE has been called by the target process". This requires MPI_WIN_FENCE that starts an epoch to act as an barrier. >>>>>>>>> >>>>>>>>> It only says "RMA operations on win started by a process after the fence call returns will access their target window only after MPI_WIN_FENCE has been called by the target process". NOT "This requires MPI_WIN_FENCE that starts an epoch to act as an barrier." >>>>>>>>> >>>>>>>>> Why does the fence have to act as a barrier. The handshake could be done when first RMA operation is called after the fence. >>>>>>>>> >>>>>>>>> Rajeev >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 25, 2014, at 8:41 PM, "Zhao, Xin" <xinzhao3(a)illinois.edu> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> There is an inconsistency of MPI_WIN_FENCE semantic in MPI 3.0 Standard that makes me confused: >>>>>>>>>> >>>>>>>>>> (1) On P440-P441 it say that "RMA operations on win started by a process after the fence call returns will access their target window only after MPI_WIN_FENCE has been called by the target process". This requires MPI_WIN_FENCE that starts an epoch to act as an barrier. >>>>>>>>>> >>>>>>>>>> (2) However, (1) contradict with the word at end of P441: "a call to MPI_WIN_FENCE that is known not to end any epoch (in particular a call with assert equal to MPI_MODE_NOPRECEDE) does not necessarily act as a barrier". >>>>>>>>>> >>>>>>>>>> Should the word of (1) add: "when MPI_MODE_NOPRECEDE is not given"? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Xin >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0