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

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

14 Mar '14

All, I’ve written up these thoughts in the below ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/416 Comments are welcome on the ticket. — Pavan On Mar 13, 2014, at 4:13 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > On Mar 13, 2014, at 4:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> It was not disallowed in MPI-2. I meant that we made a mistake in MPI-3 to disallow it since that is not backward compatible. >> >> You told me two days ago it was at best undefined, which is no more >> useful than disallowed: > > I’m not sure what you are referring to, but that was no my intention. Perhaps I misunderstood what you were asking. > > It think it’s pretty clear that it’s disallowed in MPI-3, not undefined. > >>> IMO, we should have kept the same semantics as MPI-2, but allowed the user to relax it with info arguments. >> >> Well we broke backwards compatibility but made it almost impossible >> for anyone to notice and certainly didn't add an advice to users so we >> are clearly all jerks. > > I like MPI-2’s approach. The data content is undefined, but not an error. > > — Pavan > > _______________________________________________ > 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] {MAX,MIN}LOC in RMA
by Jed Brown 13 Mar '14

13 Mar '14

Jeff Hammond <jeff.science(a)gmail.com> writes: >>> If NIC does FP for complex, this is fine. >> >> Show me a NIC that does. > > Prove that one doesn't exist already. > > See also: shared memory. Uh, what shared memory system provides atomic complex multiply? >>> M**Loc isn't a commons HW atomic. Prove that this doesn't exist. You'll recall that I've nearly given up on RMA because Ops are not extensible. I can't implement anything important using RMA without also implementing it over non-RMA because my code has to work with types like float128 and longer pair types.

1 0

Re: [mpiwg-rma] {MAX,MIN}LOC in RMA
by Jeff Hammond 13 Mar '14

13 Mar '14

>> If NIC does FP for complex, this is fine. > > Show me a NIC that does. Prove that one doesn't exist already. See also: shared memory. >> M**Loc isn't a commons HW atomic.

1 0

Re: [mpiwg-rma] {MAX,MIN}LOC in RMA
by Jed Brown 13 Mar '14

13 Mar '14

Jeff Hammond <jeff.science(a)gmail.com> writes: > If NIC does FP for complex, this is fine. Show me a NIC that does. > M**Loc isn't a commons HW atomic.

1 0

Re: [mpiwg-rma] {MAX,MIN}LOC in RMA
by Jeff Hammond 13 Mar '14

13 Mar '14

> On Mar 13, 2014, at 8:42 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > Jeff Hammond <jeff.science(a)gmail.com> writes: > >> But this can't be done in hardware easily so how did we ever let it >> into the RMA chapter? :-) > > How 'bout MPI_PROD for complex? > If NIC does FP for complex, this is fine. M**Loc isn't a commons HW atomic. > We use MINLOC to resolve sharing in unstructured meshes. My RMA > implementation is no longer default due to buggy MPI implementations of > RMA datatypes, but we are using that semantic operation.

1 0

Re: [mpiwg-rma] {MAX,MIN}LOC in RMA
by Jed Brown 13 Mar '14

13 Mar '14

Jeff Hammond <jeff.science(a)gmail.com> writes: > But this can't be done in hardware easily so how did we ever let it > into the RMA chapter? :-) How 'bout MPI_PROD for complex? We use MINLOC to resolve sharing in unstructured meshes. My RMA implementation is no longer default due to buggy MPI implementations of RMA datatypes, but we are using that semantic operation.

1 0

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

13 Mar '14

On Mar 13, 2014, at 4:08 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> It was not disallowed in MPI-2. I meant that we made a mistake in MPI-3 to disallow it since that is not backward compatible. > > You told me two days ago it was at best undefined, which is no more > useful than disallowed: I’m not sure what you are referring to, but that was no my intention. Perhaps I misunderstood what you were asking. It think it’s pretty clear that it’s disallowed in MPI-3, not undefined. >> IMO, we should have kept the same semantics as MPI-2, but allowed the user to relax it with info arguments. > > Well we broke backwards compatibility but made it almost impossible > for anyone to notice and certainly didn't add an advice to users so we > are clearly all jerks. I like MPI-2’s approach. The data content is undefined, but not an error. — Pavan

1 0

Re: [mpiwg-rma] same_op_no_op
by Jeff Hammond 13 Mar '14

13 Mar '14

So do we want to prohibit diff op atomicity in all cases or is that the default? I think many implementations won't care but the RMA-in-hardware ones really want same_op_no_op_replace or less (as in more restrictive). Jeff On Thu, Mar 13, 2014 at 3:28 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Because it's an info key, we can't make the relax the semantic, we can only > restrict it. So, the most permissive semantic needs to be the default. > > > On Thu, Mar 13, 2014 at 3:54 PM, Dave Goodell (dgoodell) > <dgoodell(a)cisco.com> wrote: >> >> On Mar 13, 2014, at 2:47 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> > same_op_no_op_replace might not be completely SHMEM-compliant but it >> > almost certainly meets the needs of reasonable SHMEM programs. Right >> > now, the incompatibility of REPLACE and <any reduce op> puts me in a >> > very bad place for essentially all PGAS models. >> >> Wouldn't you be in a perfectly fine place if we just add >> "same_op_no_op_replace" to the standard and then you modify your codes to >> use it? >> >> I really don't understand your insistence on changing the default >> behavior... >> >> -Dave >> >> _______________________________________________ >> 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 Jeff Hammond 13 Mar '14

13 Mar '14

On Thu, Mar 13, 2014 at 2:52 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > On Mar 13, 2014, at 2:47 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> If we thought it was a mistake in MPI-2 to disallow it, wouldn't we >> have tried to relax it in MPI-3? Brian had commented before that we >> might have been confused when defining same_op_no_op and really meant >> same_op_no_op_replace, which is a perfectly reasonable default >> semantic. > > It was not disallowed in MPI-2. I meant that we made a mistake in MPI-3 to disallow it since that is not backward compatible. You told me two days ago it was at best undefined, which is no more useful than disallowed: ============================== On Tue, Mar 11, 2014 at 12:04 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > MPI-2 defines atomicity only for the same operation, not any operation for MPI_ACCUMULATE. > > — Pavan ============================== > IMO, we should have kept the same semantics as MPI-2, but allowed the user to relax it with info arguments. Well we broke backwards compatibility but made it almost impossible for anyone to notice and certainly didn't add an advice to users so we are clearly all jerks. Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

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

13 Mar '14

Because it's an info key, we can't make the relax the semantic, we can only restrict it. So, the most permissive semantic needs to be the default. On Thu, Mar 13, 2014 at 3:54 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com > wrote: > On Mar 13, 2014, at 2:47 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > same_op_no_op_replace might not be completely SHMEM-compliant but it > > almost certainly meets the needs of reasonable SHMEM programs. Right > > now, the incompatibility of REPLACE and <any reduce op> puts me in a > > very bad place for essentially all PGAS models. > > Wouldn't you be in a perfectly fine place if we just add > "same_op_no_op_replace" to the standard and then you modify your codes to > use it? > > I really don't understand your insistence on changing the default > behavior... > > -Dave > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma >

1 0