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

Re: [Mpi3-rma] RMA op compatibility matrix
by Pavan Balaji 14 Oct '11

14 Oct '11

On 10/14/2011 10:11 PM, Torsten Hoefler wrote: > On Fri, 2011-10-14 at 17:52 -0500, James Dinan wrote: >> Ahh, right. Thanks for your help. Updated tables are attached. > What about rules 2+3 in the unified model? They explicitly allow > overlapping put/acc + load and get + store but the behavior depends on > the implementation. I think we should have another color for those. Is it supposed to show "defined" or "allowed" combinations? It currently shows "defined" combinations. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by Torsten Hoefler 14 Oct '11

14 Oct '11

On Fri, 2011-10-14 at 17:52 -0500, James Dinan wrote: > Ahh, right. Thanks for your help. Updated tables are attached. What about rules 2+3 in the unified model? They explicitly allow overlapping put/acc + load and get + store but the behavior depends on the implementation. I think we should have another color for those. I agree to the separate matrix. Since all matrices are symmetric by definition, we could draw them into one, making the upper triangle unified and the lower triangle separate :-). All the Best, Torsten

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by James Dinan 14 Oct '11

14 Oct '11

Ahh, right. Thanks for your help. Updated tables are attached. ~Jim. On 10/14/11 5:42 PM, Pavan Balaji wrote: > Jim, > > The table looks fine, except what you call MPI-3 should be MPI-3 > UNIFIED. MPI-3 SEPARATE should be the same as MPI-2. > > -- Pavan > > On 10/14/2011 05:21 PM, James Dinan wrote: >> I am pretty sure that this rule is meant to apply to both the one-window >> and multiple-windows cases. The rationale that follows seems to confirm >> this: >> >> --snip-- >> >> Rationale. The last constraint on correct RMA accesses may seem unduly >> restrictive, as it forbids concurrent accesses to nonoverlapping >> locations in a window. The reason for this constraint is that, on some >> architectures, explicit coherence restoring operations may be needed at >> synchronization points. A different operation may be needed for >> locations that were locally updated by stores and for locations that >> were remotely updated by put or accumulate operations. Without this >> constraint, the MPI library will have to track precisely which locations >> in a window were updated by a put or accumulate call. The additional >> overhead of maintaining such information is considered prohibitive. (End >> of rationale.) >> >> --snip-- >> >> Sorry, I didn't think hard enough initially about the specific cases you >> mentioned and just applied my simplified rule of thumb that load/store >> conflicts with everything. >> >> I agree that load + Put/Acc and store + Get appear to be non-erroneous >> when the accesses are non-overlapping. >> >> Updated table is attached. Does this look correct now for MPI-2 and >> MPI-3? >> >> ~Jim. >> >> On 10/14/11 4:58 PM, Pavan Balaji wrote: >>> >>> I don't think believe that's correct. Both the "local update" and the >>> "put or accumulate" parts apply to the overlapping window. >>> >>> Here's the rule (which can be broken up into two rules): >>> >>> * A put or accumulate must not access a target window once a local >>> update or a put or accumulate update to another (overlapping) target >>> window have started on a location in the target window, until the update >>> becomes visible in the public copy of the window. >>> >>> * Conversely, a local update in process memory to a location in a window >>> must not start once a put or accumulate update to that target window has >>> started, until the put or accumulate update becomes visible in process >>> memory. In both cases, the restriction applies to operations even if >>> they access disjoint locations in the window. >>> >>> The second half is not relevant here because it's talking about the same >>> location, not the same window. >>> >>> The first half is not relevant here because it's talking about >>> overlapping windows. >>> >>> Even logically, the first rule only makes sense for overlapping windows. >>> It doesn't make sense for non-overlapping windows. Why would load + >>> Put/Acc be a problem? >>> >>> -- Pavan >>> >>> On 10/14/2011 04:48 PM, James Dinan wrote: >>>> I think this rule is overloaded to define semantics for both load/store >>>> and multiple windows. I believe that the parsing below with bracketed >>>> text removed is the correct interpretation for this case: >>>> >>>> A put or accumulate must not access a target window once a local update >>>> [or a put or accumulate update to another (overlapping) target window] >>>> have started on a location in the target window, until the update >>>> becomes visible in the public copy of the window. Conversely, a local >>>> update in process memory to a location in a window must not start >>>> once a >>>> put or accumulate update to that target window has started, until the >>>> put or accumulate update becomes visible in process memory. In both >>>> cases, the restriction applies to operations even if they access >>>> disjoint locations in the window. >>>> >>>> ~Jim. >>>> >>>> On 10/14/11 4:36 PM, Pavan Balaji wrote: >>>>> >>>>> That rule is for overlapping windows. >>>>> >>>>> Pavan Balaji @ iPhone >>>>> (Big fingers. Small email.) >>>>> >>>>> On Oct 14, 2011, at 4:33 PM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>>>> >>>>>> Rule #3 on page 365 of semantics and correctness: >>>>>> >>>>>> --snip-- >>>>>> >>>>>> 3. A put or accumulate must not access a target window once a local >>>>>> update or a put or accumulate update to another (overlapping) target >>>>>> window have started on a location in the target window, until the >>>>>> update becomes visible in the public copy of the window. Conversely, >>>>>> a local update in process memory to a location in a window must not >>>>>> start once a put or accumulate update to that target window has >>>>>> started, until the put or accumulate update becomes visible in >>>>>> process memory. In both cases, the restriction applies to operations >>>>>> even if they access disjoint locations in the window. >>>>>> >>>>>> A program is erroneous if it violates these rules. >>>>>> >>>>>> --snip-- >>>>>> >>>>>> ~Jim. >>>>>> >>>>>> PS- This rule is like five rules. We really should regroup once the >>>>>> ticket is accepted and see if it can be split into a few smaller, >>>>>> easier to digest rules. >>>>>> >>>>>> On 10/14/11 3:18 PM, Pavan Balaji wrote: >>>>>>> >>>>>>> Why are they incompatible in MPI-2? >>>>>>> >>>>>>> Pavan Balaji @ iPhone >>>>>>> (Big fingers. Small email.) >>>>>>> >>>>>>> On Oct 14, 2011, at 11:18 AM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>>>>>> >>>>>>>> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as >>>>>>>> there is no overlap. I've attached an updated PDF with both MPI-2 >>>>>>>> and MPI-3 tables. >>>>>>>> >>>>>>>> ~Jim. >>>>>>>> >>>>>>>> On 10/14/11 2:02 AM, Pavan Balaji wrote: >>>>>>>>> >>>>>>>>> There seem to be a few errors here: load + Put/Acc and store + Get >>>>>>>>> should be NOVL. >>>>>>>>> >>>>>>>>> -- Pavan >>>>>>>>> >>>>>>>>> On 10/10/2011 02:35 PM, James Dinan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> We discussed creating a table that shows compatibility between >>>>>>>>>> concurrent RMA operations. A rough mockup of this table is >>>>>>>>>> attached. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Jim. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpi3-rma mailing list >>>>>>>>>> mpi3-rma(a)lists.mpi-forum.org >>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>>>>>>>> >>>>>>>> <rma_op_matrix.pdf> >>>>>>>> <rma_op_matrix.pptx> >>> >

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by Pavan Balaji 14 Oct '11

14 Oct '11

Jim, The table looks fine, except what you call MPI-3 should be MPI-3 UNIFIED. MPI-3 SEPARATE should be the same as MPI-2. -- Pavan On 10/14/2011 05:21 PM, James Dinan wrote: > I am pretty sure that this rule is meant to apply to both the one-window > and multiple-windows cases. The rationale that follows seems to confirm > this: > > --snip-- > > Rationale. The last constraint on correct RMA accesses may seem unduly > restrictive, as it forbids concurrent accesses to nonoverlapping > locations in a window. The reason for this constraint is that, on some > architectures, explicit coherence restoring operations may be needed at > synchronization points. A different operation may be needed for > locations that were locally updated by stores and for locations that > were remotely updated by put or accumulate operations. Without this > constraint, the MPI library will have to track precisely which locations > in a window were updated by a put or accumulate call. The additional > overhead of maintaining such information is considered prohibitive. (End > of rationale.) > > --snip-- > > Sorry, I didn't think hard enough initially about the specific cases you > mentioned and just applied my simplified rule of thumb that load/store > conflicts with everything. > > I agree that load + Put/Acc and store + Get appear to be non-erroneous > when the accesses are non-overlapping. > > Updated table is attached. Does this look correct now for MPI-2 and MPI-3? > > ~Jim. > > On 10/14/11 4:58 PM, Pavan Balaji wrote: >> >> I don't think believe that's correct. Both the "local update" and the >> "put or accumulate" parts apply to the overlapping window. >> >> Here's the rule (which can be broken up into two rules): >> >> * A put or accumulate must not access a target window once a local >> update or a put or accumulate update to another (overlapping) target >> window have started on a location in the target window, until the update >> becomes visible in the public copy of the window. >> >> * Conversely, a local update in process memory to a location in a window >> must not start once a put or accumulate update to that target window has >> started, until the put or accumulate update becomes visible in process >> memory. In both cases, the restriction applies to operations even if >> they access disjoint locations in the window. >> >> The second half is not relevant here because it's talking about the same >> location, not the same window. >> >> The first half is not relevant here because it's talking about >> overlapping windows. >> >> Even logically, the first rule only makes sense for overlapping windows. >> It doesn't make sense for non-overlapping windows. Why would load + >> Put/Acc be a problem? >> >> -- Pavan >> >> On 10/14/2011 04:48 PM, James Dinan wrote: >>> I think this rule is overloaded to define semantics for both load/store >>> and multiple windows. I believe that the parsing below with bracketed >>> text removed is the correct interpretation for this case: >>> >>> A put or accumulate must not access a target window once a local update >>> [or a put or accumulate update to another (overlapping) target window] >>> have started on a location in the target window, until the update >>> becomes visible in the public copy of the window. Conversely, a local >>> update in process memory to a location in a window must not start once a >>> put or accumulate update to that target window has started, until the >>> put or accumulate update becomes visible in process memory. In both >>> cases, the restriction applies to operations even if they access >>> disjoint locations in the window. >>> >>> ~Jim. >>> >>> On 10/14/11 4:36 PM, Pavan Balaji wrote: >>>> >>>> That rule is for overlapping windows. >>>> >>>> Pavan Balaji @ iPhone >>>> (Big fingers. Small email.) >>>> >>>> On Oct 14, 2011, at 4:33 PM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>>> >>>>> Rule #3 on page 365 of semantics and correctness: >>>>> >>>>> --snip-- >>>>> >>>>> 3. A put or accumulate must not access a target window once a local >>>>> update or a put or accumulate update to another (overlapping) target >>>>> window have started on a location in the target window, until the >>>>> update becomes visible in the public copy of the window. Conversely, >>>>> a local update in process memory to a location in a window must not >>>>> start once a put or accumulate update to that target window has >>>>> started, until the put or accumulate update becomes visible in >>>>> process memory. In both cases, the restriction applies to operations >>>>> even if they access disjoint locations in the window. >>>>> >>>>> A program is erroneous if it violates these rules. >>>>> >>>>> --snip-- >>>>> >>>>> ~Jim. >>>>> >>>>> PS- This rule is like five rules. We really should regroup once the >>>>> ticket is accepted and see if it can be split into a few smaller, >>>>> easier to digest rules. >>>>> >>>>> On 10/14/11 3:18 PM, Pavan Balaji wrote: >>>>>> >>>>>> Why are they incompatible in MPI-2? >>>>>> >>>>>> Pavan Balaji @ iPhone >>>>>> (Big fingers. Small email.) >>>>>> >>>>>> On Oct 14, 2011, at 11:18 AM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>>>>> >>>>>>> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as >>>>>>> there is no overlap. I've attached an updated PDF with both MPI-2 >>>>>>> and MPI-3 tables. >>>>>>> >>>>>>> ~Jim. >>>>>>> >>>>>>> On 10/14/11 2:02 AM, Pavan Balaji wrote: >>>>>>>> >>>>>>>> There seem to be a few errors here: load + Put/Acc and store + Get >>>>>>>> should be NOVL. >>>>>>>> >>>>>>>> -- Pavan >>>>>>>> >>>>>>>> On 10/10/2011 02:35 PM, James Dinan wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> We discussed creating a table that shows compatibility between >>>>>>>>> concurrent RMA operations. A rough mockup of this table is >>>>>>>>> attached. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Jim. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mpi3-rma mailing list >>>>>>>>> mpi3-rma(a)lists.mpi-forum.org >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>>>>>>> >>>>>>> <rma_op_matrix.pdf> >>>>>>> <rma_op_matrix.pptx> >> -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by James Dinan 14 Oct '11

14 Oct '11

I am pretty sure that this rule is meant to apply to both the one-window and multiple-windows cases. The rationale that follows seems to confirm this: --snip-- Rationale. The last constraint on correct RMA accesses may seem unduly restrictive, as it forbids concurrent accesses to nonoverlapping locations in a window. The reason for this constraint is that, on some architectures, explicit coherence restoring operations may be needed at synchronization points. A different operation may be needed for locations that were locally updated by stores and for locations that were remotely updated by put or accumulate operations. Without this constraint, the MPI library will have to track precisely which locations in a window were updated by a put or accumulate call. The additional overhead of maintaining such information is considered prohibitive. (End of rationale.) --snip-- Sorry, I didn't think hard enough initially about the specific cases you mentioned and just applied my simplified rule of thumb that load/store conflicts with everything. I agree that load + Put/Acc and store + Get appear to be non-erroneous when the accesses are non-overlapping. Updated table is attached. Does this look correct now for MPI-2 and MPI-3? ~Jim. On 10/14/11 4:58 PM, Pavan Balaji wrote: > > I don't think believe that's correct. Both the "local update" and the > "put or accumulate" parts apply to the overlapping window. > > Here's the rule (which can be broken up into two rules): > > * A put or accumulate must not access a target window once a local > update or a put or accumulate update to another (overlapping) target > window have started on a location in the target window, until the update > becomes visible in the public copy of the window. > > * Conversely, a local update in process memory to a location in a window > must not start once a put or accumulate update to that target window has > started, until the put or accumulate update becomes visible in process > memory. In both cases, the restriction applies to operations even if > they access disjoint locations in the window. > > The second half is not relevant here because it's talking about the same > location, not the same window. > > The first half is not relevant here because it's talking about > overlapping windows. > > Even logically, the first rule only makes sense for overlapping windows. > It doesn't make sense for non-overlapping windows. Why would load + > Put/Acc be a problem? > > -- Pavan > > On 10/14/2011 04:48 PM, James Dinan wrote: >> I think this rule is overloaded to define semantics for both load/store >> and multiple windows. I believe that the parsing below with bracketed >> text removed is the correct interpretation for this case: >> >> A put or accumulate must not access a target window once a local update >> [or a put or accumulate update to another (overlapping) target window] >> have started on a location in the target window, until the update >> becomes visible in the public copy of the window. Conversely, a local >> update in process memory to a location in a window must not start once a >> put or accumulate update to that target window has started, until the >> put or accumulate update becomes visible in process memory. In both >> cases, the restriction applies to operations even if they access >> disjoint locations in the window. >> >> ~Jim. >> >> On 10/14/11 4:36 PM, Pavan Balaji wrote: >>> >>> That rule is for overlapping windows. >>> >>> Pavan Balaji @ iPhone >>> (Big fingers. Small email.) >>> >>> On Oct 14, 2011, at 4:33 PM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>> >>>> Rule #3 on page 365 of semantics and correctness: >>>> >>>> --snip-- >>>> >>>> 3. A put or accumulate must not access a target window once a local >>>> update or a put or accumulate update to another (overlapping) target >>>> window have started on a location in the target window, until the >>>> update becomes visible in the public copy of the window. Conversely, >>>> a local update in process memory to a location in a window must not >>>> start once a put or accumulate update to that target window has >>>> started, until the put or accumulate update becomes visible in >>>> process memory. In both cases, the restriction applies to operations >>>> even if they access disjoint locations in the window. >>>> >>>> A program is erroneous if it violates these rules. >>>> >>>> --snip-- >>>> >>>> ~Jim. >>>> >>>> PS- This rule is like five rules. We really should regroup once the >>>> ticket is accepted and see if it can be split into a few smaller, >>>> easier to digest rules. >>>> >>>> On 10/14/11 3:18 PM, Pavan Balaji wrote: >>>>> >>>>> Why are they incompatible in MPI-2? >>>>> >>>>> Pavan Balaji @ iPhone >>>>> (Big fingers. Small email.) >>>>> >>>>> On Oct 14, 2011, at 11:18 AM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>>>> >>>>>> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as >>>>>> there is no overlap. I've attached an updated PDF with both MPI-2 >>>>>> and MPI-3 tables. >>>>>> >>>>>> ~Jim. >>>>>> >>>>>> On 10/14/11 2:02 AM, Pavan Balaji wrote: >>>>>>> >>>>>>> There seem to be a few errors here: load + Put/Acc and store + Get >>>>>>> should be NOVL. >>>>>>> >>>>>>> -- Pavan >>>>>>> >>>>>>> On 10/10/2011 02:35 PM, James Dinan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> We discussed creating a table that shows compatibility between >>>>>>>> concurrent RMA operations. A rough mockup of this table is >>>>>>>> attached. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jim. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpi3-rma mailing list >>>>>>>> mpi3-rma(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>>>>>> >>>>>> <rma_op_matrix.pdf> >>>>>> <rma_op_matrix.pptx> >

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by Pavan Balaji 14 Oct '11

14 Oct '11

Btw, even in your interpretation what I said still holds true: load + Put/Acc and store + Get should be NOVL. The rule is says that put/acc + store don't mix. And put/acc + put/acc for overlapping windows don't mix. -- Pavan On 10/14/2011 04:58 PM, Pavan Balaji wrote: > > I don't think believe that's correct. Both the "local update" and the > "put or accumulate" parts apply to the overlapping window. > > Here's the rule (which can be broken up into two rules): > > * A put or accumulate must not access a target window once a local > update or a put or accumulate update to another (overlapping) target > window have started on a location in the target window, until the update > becomes visible in the public copy of the window. > > * Conversely, a local update in process memory to a location in a > window must not start once a put or accumulate update to that target > window has started, until the put or accumulate update becomes visible > in process memory. In both cases, the restriction applies to operations > even if they access disjoint locations in the window. > > The second half is not relevant here because it's talking about the same > location, not the same window. > > The first half is not relevant here because it's talking about > overlapping windows. > > Even logically, the first rule only makes sense for overlapping windows. > It doesn't make sense for non-overlapping windows. Why would load + > Put/Acc be a problem? > > -- Pavan > > On 10/14/2011 04:48 PM, James Dinan wrote: >> I think this rule is overloaded to define semantics for both load/store >> and multiple windows. I believe that the parsing below with bracketed >> text removed is the correct interpretation for this case: >> >> A put or accumulate must not access a target window once a local update >> [or a put or accumulate update to another (overlapping) target window] >> have started on a location in the target window, until the update >> becomes visible in the public copy of the window. Conversely, a local >> update in process memory to a location in a window must not start once a >> put or accumulate update to that target window has started, until the >> put or accumulate update becomes visible in process memory. In both >> cases, the restriction applies to operations even if they access >> disjoint locations in the window. >> >> ~Jim. >> >> On 10/14/11 4:36 PM, Pavan Balaji wrote: >>> >>> That rule is for overlapping windows. >>> >>> Pavan Balaji @ iPhone >>> (Big fingers. Small email.) >>> >>> On Oct 14, 2011, at 4:33 PM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>> >>>> Rule #3 on page 365 of semantics and correctness: >>>> >>>> --snip-- >>>> >>>> 3. A put or accumulate must not access a target window once a local update or a put or accumulate update to another (overlapping) target window have started on a location in the target window, until the update becomes visible in the public copy of the window. Conversely, a local update in process memory to a location in a window must not start once a put or accumulate update to that target window has started, until the put or accumulate update becomes visible in process memory. In both cases, the restriction applies to operations even if they access disjoint locations in the window. >>>> >>>> A program is erroneous if it violates these rules. >>>> >>>> --snip-- >>>> >>>> ~Jim. >>>> >>>> PS- This rule is like five rules. We really should regroup once the ticket is accepted and see if it can be split into a few smaller, easier to digest rules. >>>> >>>> On 10/14/11 3:18 PM, Pavan Balaji wrote: >>>>> >>>>> Why are they incompatible in MPI-2? >>>>> >>>>> Pavan Balaji @ iPhone >>>>> (Big fingers. Small email.) >>>>> >>>>> On Oct 14, 2011, at 11:18 AM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>>>> >>>>>> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as there is no overlap. I've attached an updated PDF with both MPI-2 and MPI-3 tables. >>>>>> >>>>>> ~Jim. >>>>>> >>>>>> On 10/14/11 2:02 AM, Pavan Balaji wrote: >>>>>>> >>>>>>> There seem to be a few errors here: load + Put/Acc and store + Get >>>>>>> should be NOVL. >>>>>>> >>>>>>> -- Pavan >>>>>>> >>>>>>> On 10/10/2011 02:35 PM, James Dinan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> We discussed creating a table that shows compatibility between >>>>>>>> concurrent RMA operations. A rough mockup of this table is attached. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jim. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpi3-rma mailing list >>>>>>>> mpi3-rma(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>>>>>> >>>>>> <rma_op_matrix.pdf> >>>>>> <rma_op_matrix.pptx> > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by Pavan Balaji 14 Oct '11

14 Oct '11

I don't think believe that's correct. Both the "local update" and the "put or accumulate" parts apply to the overlapping window. Here's the rule (which can be broken up into two rules): * A put or accumulate must not access a target window once a local update or a put or accumulate update to another (overlapping) target window have started on a location in the target window, until the update becomes visible in the public copy of the window. * Conversely, a local update in process memory to a location in a window must not start once a put or accumulate update to that target window has started, until the put or accumulate update becomes visible in process memory. In both cases, the restriction applies to operations even if they access disjoint locations in the window. The second half is not relevant here because it's talking about the same location, not the same window. The first half is not relevant here because it's talking about overlapping windows. Even logically, the first rule only makes sense for overlapping windows. It doesn't make sense for non-overlapping windows. Why would load + Put/Acc be a problem? -- Pavan On 10/14/2011 04:48 PM, James Dinan wrote: > I think this rule is overloaded to define semantics for both load/store > and multiple windows. I believe that the parsing below with bracketed > text removed is the correct interpretation for this case: > > A put or accumulate must not access a target window once a local update > [or a put or accumulate update to another (overlapping) target window] > have started on a location in the target window, until the update > becomes visible in the public copy of the window. Conversely, a local > update in process memory to a location in a window must not start once a > put or accumulate update to that target window has started, until the > put or accumulate update becomes visible in process memory. In both > cases, the restriction applies to operations even if they access > disjoint locations in the window. > > ~Jim. > > On 10/14/11 4:36 PM, Pavan Balaji wrote: >> >> That rule is for overlapping windows. >> >> Pavan Balaji @ iPhone >> (Big fingers. Small email.) >> >> On Oct 14, 2011, at 4:33 PM, James Dinan<dinan(a)mcs.anl.gov> wrote: >> >>> Rule #3 on page 365 of semantics and correctness: >>> >>> --snip-- >>> >>> 3. A put or accumulate must not access a target window once a local update or a put or accumulate update to another (overlapping) target window have started on a location in the target window, until the update becomes visible in the public copy of the window. Conversely, a local update in process memory to a location in a window must not start once a put or accumulate update to that target window has started, until the put or accumulate update becomes visible in process memory. In both cases, the restriction applies to operations even if they access disjoint locations in the window. >>> >>> A program is erroneous if it violates these rules. >>> >>> --snip-- >>> >>> ~Jim. >>> >>> PS- This rule is like five rules. We really should regroup once the ticket is accepted and see if it can be split into a few smaller, easier to digest rules. >>> >>> On 10/14/11 3:18 PM, Pavan Balaji wrote: >>>> >>>> Why are they incompatible in MPI-2? >>>> >>>> Pavan Balaji @ iPhone >>>> (Big fingers. Small email.) >>>> >>>> On Oct 14, 2011, at 11:18 AM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>>> >>>>> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as there is no overlap. I've attached an updated PDF with both MPI-2 and MPI-3 tables. >>>>> >>>>> ~Jim. >>>>> >>>>> On 10/14/11 2:02 AM, Pavan Balaji wrote: >>>>>> >>>>>> There seem to be a few errors here: load + Put/Acc and store + Get >>>>>> should be NOVL. >>>>>> >>>>>> -- Pavan >>>>>> >>>>>> On 10/10/2011 02:35 PM, James Dinan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> We discussed creating a table that shows compatibility between >>>>>>> concurrent RMA operations. A rough mockup of this table is attached. >>>>>>> >>>>>>> Cheers, >>>>>>> Jim. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpi3-rma mailing list >>>>>>> mpi3-rma(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>>>>> >>>>> <rma_op_matrix.pdf> >>>>> <rma_op_matrix.pptx> -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by James Dinan 14 Oct '11

14 Oct '11

I think this rule is overloaded to define semantics for both load/store and multiple windows. I believe that the parsing below with bracketed text removed is the correct interpretation for this case: A put or accumulate must not access a target window once a local update [or a put or accumulate update to another (overlapping) target window] have started on a location in the target window, until the update becomes visible in the public copy of the window. Conversely, a local update in process memory to a location in a window must not start once a put or accumulate update to that target window has started, until the put or accumulate update becomes visible in process memory. In both cases, the restriction applies to operations even if they access disjoint locations in the window. ~Jim. On 10/14/11 4:36 PM, Pavan Balaji wrote: > > That rule is for overlapping windows. > > Pavan Balaji @ iPhone > (Big fingers. Small email.) > > On Oct 14, 2011, at 4:33 PM, James Dinan<dinan(a)mcs.anl.gov> wrote: > >> Rule #3 on page 365 of semantics and correctness: >> >> --snip-- >> >> 3. A put or accumulate must not access a target window once a local update or a put or accumulate update to another (overlapping) target window have started on a location in the target window, until the update becomes visible in the public copy of the window. Conversely, a local update in process memory to a location in a window must not start once a put or accumulate update to that target window has started, until the put or accumulate update becomes visible in process memory. In both cases, the restriction applies to operations even if they access disjoint locations in the window. >> >> A program is erroneous if it violates these rules. >> >> --snip-- >> >> ~Jim. >> >> PS- This rule is like five rules. We really should regroup once the ticket is accepted and see if it can be split into a few smaller, easier to digest rules. >> >> On 10/14/11 3:18 PM, Pavan Balaji wrote: >>> >>> Why are they incompatible in MPI-2? >>> >>> Pavan Balaji @ iPhone >>> (Big fingers. Small email.) >>> >>> On Oct 14, 2011, at 11:18 AM, James Dinan<dinan(a)mcs.anl.gov> wrote: >>> >>>> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as there is no overlap. I've attached an updated PDF with both MPI-2 and MPI-3 tables. >>>> >>>> ~Jim. >>>> >>>> On 10/14/11 2:02 AM, Pavan Balaji wrote: >>>>> >>>>> There seem to be a few errors here: load + Put/Acc and store + Get >>>>> should be NOVL. >>>>> >>>>> -- Pavan >>>>> >>>>> On 10/10/2011 02:35 PM, James Dinan wrote: >>>>>> Hi All, >>>>>> >>>>>> We discussed creating a table that shows compatibility between >>>>>> concurrent RMA operations. A rough mockup of this table is attached. >>>>>> >>>>>> Cheers, >>>>>> Jim. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi3-rma mailing list >>>>>> mpi3-rma(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>>>> >>>> <rma_op_matrix.pdf> >>>> <rma_op_matrix.pptx>

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by Pavan Balaji 14 Oct '11

14 Oct '11

That rule is for overlapping windows. Pavan Balaji @ iPhone (Big fingers. Small email.) On Oct 14, 2011, at 4:33 PM, James Dinan <dinan(a)mcs.anl.gov> wrote: > Rule #3 on page 365 of semantics and correctness: > > --snip-- > > 3. A put or accumulate must not access a target window once a local update or a put or accumulate update to another (overlapping) target window have started on a location in the target window, until the update becomes visible in the public copy of the window. Conversely, a local update in process memory to a location in a window must not start once a put or accumulate update to that target window has started, until the put or accumulate update becomes visible in process memory. In both cases, the restriction applies to operations even if they access disjoint locations in the window. > > A program is erroneous if it violates these rules. > > --snip-- > > ~Jim. > > PS- This rule is like five rules. We really should regroup once the ticket is accepted and see if it can be split into a few smaller, easier to digest rules. > > On 10/14/11 3:18 PM, Pavan Balaji wrote: >> >> Why are they incompatible in MPI-2? >> >> Pavan Balaji @ iPhone >> (Big fingers. Small email.) >> >> On Oct 14, 2011, at 11:18 AM, James Dinan<dinan(a)mcs.anl.gov> wrote: >> >>> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as there is no overlap. I've attached an updated PDF with both MPI-2 and MPI-3 tables. >>> >>> ~Jim. >>> >>> On 10/14/11 2:02 AM, Pavan Balaji wrote: >>>> >>>> There seem to be a few errors here: load + Put/Acc and store + Get >>>> should be NOVL. >>>> >>>> -- Pavan >>>> >>>> On 10/10/2011 02:35 PM, James Dinan wrote: >>>>> Hi All, >>>>> >>>>> We discussed creating a table that shows compatibility between >>>>> concurrent RMA operations. A rough mockup of this table is attached. >>>>> >>>>> Cheers, >>>>> Jim. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpi3-rma mailing list >>>>> mpi3-rma(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>>> >>> <rma_op_matrix.pdf> >>> <rma_op_matrix.pptx>

1 0

Re: [Mpi3-rma] RMA op compatibility matrix
by James Dinan 14 Oct '11

14 Oct '11

Rule #3 on page 365 of semantics and correctness: --snip-- 3. A put or accumulate must not access a target window once a local update or a put or accumulate update to another (overlapping) target window have started on a location in the target window, until the update becomes visible in the public copy of the window. Conversely, a local update in process memory to a location in a window must not start once a put or accumulate update to that target window has started, until the put or accumulate update becomes visible in process memory. In both cases, the restriction applies to operations even if they access disjoint locations in the window. A program is erroneous if it violates these rules. --snip-- ~Jim. PS- This rule is like five rules. We really should regroup once the ticket is accepted and see if it can be split into a few smaller, easier to digest rules. On 10/14/11 3:18 PM, Pavan Balaji wrote: > > Why are they incompatible in MPI-2? > > Pavan Balaji @ iPhone > (Big fingers. Small email.) > > On Oct 14, 2011, at 11:18 AM, James Dinan<dinan(a)mcs.anl.gov> wrote: > >> In MPI-2, the are not compatible, but in MPI-3, it's ok as long as there is no overlap. I've attached an updated PDF with both MPI-2 and MPI-3 tables. >> >> ~Jim. >> >> On 10/14/11 2:02 AM, Pavan Balaji wrote: >>> >>> There seem to be a few errors here: load + Put/Acc and store + Get >>> should be NOVL. >>> >>> -- Pavan >>> >>> On 10/10/2011 02:35 PM, James Dinan wrote: >>>> Hi All, >>>> >>>> We discussed creating a table that shows compatibility between >>>> concurrent RMA operations. A rough mockup of this table is attached. >>>> >>>> Cheers, >>>> Jim. >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpi3-rma mailing list >>>> mpi3-rma(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>> >> <rma_op_matrix.pdf> >> <rma_op_matrix.pptx>

1 0