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

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

02 Mar '11

On Wed, Mar 02, 2011 at 02:52:07PM -0700, Barrett, Brian W wrote: > On 3/2/11 1:50 PM, "James Dinan" <dinan(a)mcs.anl.gov> wrote: > > >On 03/02/2011 01:48 PM, Barrett, Brian W wrote: > >> On 3/2/11 9:47 AM, "James Dinan"<dinan(a)mcs.anl.gov> wrote: > >>> When we state that accumulates with the same operation are > >>> non-conflicting, should I be interpreting this as CAS is only > >>> non-conflicting with other CAS operations? This is a bit of a stretch > >>> since CAS doesn't take an op argument, but I suppose it's doable. Some > >>> text to help the reader make this connection for CAS would definitely > >>> help. > >> > >> CAS is defined as an accumulate operation (pg 1, ln 38--41), so yes, CAS > >> should be interpreted as a different operation than MPI_REPLACE or > >>MPI_SUM > >> or... I personally think this is obvious, but have no objection to an > >> additional sentence in the accumulate_ops info key specifying this. I > >> believe that's the only place in the current text where operation > >> conflicts are discussed, but I could be wrong. > > > >I think there are two ways to interpret the current text: > > > >1. CAS defines a new accumulate op that can only be performed by > >MPI_Compare_and_swap, thus it is only non-conflicting with itself. > > > >2. MPI_Compare_and_swap has a fixed op=MPI_REPLACE and it is > >non-conflicting with all other accumulate calls if op=MPI_REPLACE is > >given. > > > >Number 1 seems tricky to me because Get_accumulate with op=MPI_REPLACE > >does an unconditional SWAP. Number 2 seems to mesh better with existing > >accumulate operations, but do concurrent CAS, SWAP, and REPLACE > >operations play nice? > > That's true, I guess I'm ok defining CAS as on MPI_REPLACE operation. > That would mean that you could use CAS, Accumulate(REPLACE), > Get_Accumulate(REPLACE), and Get_Accumulate(NO_OP) to the same address, > with no other operations legal. That doesn't bother me too much, and > probably makes sense. > > As an aside, it's not clear in the current text which is the default for > accumulate_ops: same_op or same_op_no_op. The semantics section still > defines same_op, but that seems to go agains the use of info keys to relax > requirements on the implementation. True. Right now, the stricter (more limited) semantics are default (I don't have an issue with this). We could forward-reference from the info-key description to the semantics section to make it more clear. All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

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

02 Mar '11

On 3/2/11 1:50 PM, "James Dinan" <dinan(a)mcs.anl.gov> wrote: >On 03/02/2011 01:48 PM, Barrett, Brian W wrote: >> On 3/2/11 9:47 AM, "James Dinan"<dinan(a)mcs.anl.gov> wrote: >>> When we state that accumulates with the same operation are >>> non-conflicting, should I be interpreting this as CAS is only >>> non-conflicting with other CAS operations? This is a bit of a stretch >>> since CAS doesn't take an op argument, but I suppose it's doable. Some >>> text to help the reader make this connection for CAS would definitely >>> help. >> >> CAS is defined as an accumulate operation (pg 1, ln 38--41), so yes, CAS >> should be interpreted as a different operation than MPI_REPLACE or >>MPI_SUM >> or... I personally think this is obvious, but have no objection to an >> additional sentence in the accumulate_ops info key specifying this. I >> believe that's the only place in the current text where operation >> conflicts are discussed, but I could be wrong. > >I think there are two ways to interpret the current text: > >1. CAS defines a new accumulate op that can only be performed by >MPI_Compare_and_swap, thus it is only non-conflicting with itself. > >2. MPI_Compare_and_swap has a fixed op=MPI_REPLACE and it is >non-conflicting with all other accumulate calls if op=MPI_REPLACE is >given. > >Number 1 seems tricky to me because Get_accumulate with op=MPI_REPLACE >does an unconditional SWAP. Number 2 seems to mesh better with existing >accumulate operations, but do concurrent CAS, SWAP, and REPLACE >operations play nice? That's true, I guess I'm ok defining CAS as on MPI_REPLACE operation. That would mean that you could use CAS, Accumulate(REPLACE), Get_Accumulate(REPLACE), and Get_Accumulate(NO_OP) to the same address, with no other operations legal. That doesn't bother me too much, and probably makes sense. As an aside, it's not clear in the current text which is the default for accumulate_ops: same_op or same_op_no_op. The semantics section still defines same_op, but that seems to go agains the use of info keys to relax requirements on the implementation. Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0

Re: [Mpi3-rma] current version of proposal
by James Dinan 02 Mar '11

02 Mar '11

On 03/02/2011 01:48 PM, Barrett, Brian W wrote: > On 3/2/11 9:47 AM, "James Dinan"<dinan(a)mcs.anl.gov> wrote: >> When we state that accumulates with the same operation are >> non-conflicting, should I be interpreting this as CAS is only >> non-conflicting with other CAS operations? This is a bit of a stretch >> since CAS doesn't take an op argument, but I suppose it's doable. Some >> text to help the reader make this connection for CAS would definitely >> help. > > CAS is defined as an accumulate operation (pg 1, ln 38--41), so yes, CAS > should be interpreted as a different operation than MPI_REPLACE or MPI_SUM > or... I personally think this is obvious, but have no objection to an > additional sentence in the accumulate_ops info key specifying this. I > believe that's the only place in the current text where operation > conflicts are discussed, but I could be wrong. I think there are two ways to interpret the current text: 1. CAS defines a new accumulate op that can only be performed by MPI_Compare_and_swap, thus it is only non-conflicting with itself. 2. MPI_Compare_and_swap has a fixed op=MPI_REPLACE and it is non-conflicting with all other accumulate calls if op=MPI_REPLACE is given. Number 1 seems tricky to me because Get_accumulate with op=MPI_REPLACE does an unconditional SWAP. Number 2 seems to mesh better with existing accumulate operations, but do concurrent CAS, SWAP, and REPLACE operations play nice? ~Jim.

1 0

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

02 Mar '11

On 3/2/11 9:47 AM, "James Dinan" <dinan(a)mcs.anl.gov> wrote: >Hi Brian, > >When we state that accumulates with the same operation are >non-conflicting, should I be interpreting this as CAS is only >non-conflicting with other CAS operations? This is a bit of a stretch >since CAS doesn't take an op argument, but I suppose it's doable. Some >text to help the reader make this connection for CAS would definitely >help. CAS is defined as an accumulate operation (pg 1, ln 38--41), so yes, CAS should be interpreted as a different operation than MPI_REPLACE or MPI_SUM or... I personally think this is obvious, but have no objection to an additional sentence in the accumulate_ops info key specifying this. I believe that's the only place in the current text where operation conflicts are discussed, but I could be wrong. Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0

Re: [Mpi3-rma] current version of proposal
by James Dinan 02 Mar '11

02 Mar '11

Hi Brian, When we state that accumulates with the same operation are non-conflicting, should I be interpreting this as CAS is only non-conflicting with other CAS operations? This is a bit of a stretch since CAS doesn't take an op argument, but I suppose it's doable. Some text to help the reader make this connection for CAS would definitely help. ~Jim. On 03/02/2011 10:30 AM, Barrett, Brian W wrote: > I agree with most of the edits, but not the move from "accumulate > operations" to "atomic operations". I understand the reluctance to call > compare-and-swap an accumulate operation, but we used "accumulate > operations" so that we wouldn't run into any semantic changes to the > greater document. This was the same reason we didn't make rational > overlap semantics for put/get. If we're going to change our minds and > make the change to accumulate operations, but not change put/get > semantics, that seems rather odd. > > Brian > > On 3/1/11 1:54 PM, "James Dinan"<dinan(a)mcs.anl.gov> wrote: > >> Hi All, >> >> I did a read through and attached my edits. I also scanned in the >> edited document and typed up the edits so you don't have to interpret my >> scribbled notes. I *think* there might have been one or two pages that >> were flipped over when I scanned it, so keep an eye out. >> >> A couple of those edits are non-trivial, so feel free to move anything >> that should be discussed to the mailing list. >> >> For example, I suggested merging MPI_Win_query into a window attribute - >> we've remove the datatype and op from the call, so now it should work >> cleanly as an attribute. >> >> Thanks, >> ~Jim. >> >> On 02/28/2011 03:43 PM, Torsten Hoefler wrote: >>> Hello all, >>> >>> I updated the version again (hopefully for a last time) with Brian's >>> cleanup of the examples (Brian, I edited the style a bit). See >>> >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-pro >>> posal1/ >>> >>> All the Best, >>> Torsten >>> >> >> > >

1 0

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

02 Mar '11

I agree with most of the edits, but not the move from "accumulate operations" to "atomic operations". I understand the reluctance to call compare-and-swap an accumulate operation, but we used "accumulate operations" so that we wouldn't run into any semantic changes to the greater document. This was the same reason we didn't make rational overlap semantics for put/get. If we're going to change our minds and make the change to accumulate operations, but not change put/get semantics, that seems rather odd. Brian On 3/1/11 1:54 PM, "James Dinan" <dinan(a)mcs.anl.gov> wrote: >Hi All, > >I did a read through and attached my edits. I also scanned in the >edited document and typed up the edits so you don't have to interpret my >scribbled notes. I *think* there might have been one or two pages that >were flipped over when I scanned it, so keep an eye out. > >A couple of those edits are non-trivial, so feel free to move anything >that should be discussed to the mailing list. > >For example, I suggested merging MPI_Win_query into a window attribute - >we've remove the datatype and op from the call, so now it should work >cleanly as an attribute. > >Thanks, > ~Jim. > >On 02/28/2011 03:43 PM, Torsten Hoefler wrote: >> Hello all, >> >> I updated the version again (hopefully for a last time) with Brian's >> cleanup of the examples (Brian, I edited the style a bit). See >> >> >>https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-pro >>posal1/ >> >> All the Best, >> Torsten >> > > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0

Re: [Mpi3-rma] current version of proposal
by James Dinan 01 Mar '11

01 Mar '11

Hi All, I did a read through and attached my edits. I also scanned in the edited document and typed up the edits so you don't have to interpret my scribbled notes. I *think* there might have been one or two pages that were flipped over when I scanned it, so keep an eye out. A couple of those edits are non-trivial, so feel free to move anything that should be discussed to the mailing list. For example, I suggested merging MPI_Win_query into a window attribute - we've remove the datatype and op from the call, so now it should work cleanly as an attribute. Thanks, ~Jim. On 02/28/2011 03:43 PM, Torsten Hoefler wrote: > Hello all, > > I updated the version again (hopefully for a last time) with Brian's > cleanup of the examples (Brian, I edited the style a bit). See > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… > > All the Best, > Torsten >

1 0