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

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

14 Mar '14

If my compiler has a flag for -fdisable-long-double-complex, we're good, right? Jeff Sent from my iPhone On Mar 14, 2014, at 11:54 AM, "Underwood, Keith D" <keith.d.underwood(a)intel.com> wrote: >> 2. Now we expect every system to have the equivalent of CMPXCHG16B and >> that basic types will never be longer than 16B (unless a longer atomic is made >> available)? > > You mean... like long double complex?

1 0

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

14 Mar '14

M**LOC doesn't act on standard types so it's really not relevant. I said this already. Jeff Sent from my iPhone > On Mar 14, 2014, at 11:49 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > Jeff Hammond <jeff.science(a)gmail.com> writes: > >> There's an easy solution for "bad" ops: fall back to C&S >> implementation the way one does on any shared memory arch when a >> particular atomic isn't supported but C&S is. >> >> This means that no mutexes are required, NICs that have HW support for >> NO_OP, REPLACE, SUM, XOR, etc. can use them, and when a user asks for >> something silly like PROD, the performance is degraded for those ops >> alone and not for anything else. > > 1. How does the above not justify the same for M**LOC? > > 2. Now we expect every system to have the equivalent of CMPXCHG16B and > that basic types will never be longer than 16B (unless a longer atomic > is made available)?

1 0

Re: [mpiwg-rma] same_op_no_op
by Underwood, Keith D 14 Mar '14

14 Mar '14

> 2. Now we expect every system to have the equivalent of CMPXCHG16B and > that basic types will never be longer than 16B (unless a longer atomic is made > available)? You mean... like long double complex?

1 0

Re: [mpiwg-rma] same_op_no_op
by Jed Brown 14 Mar '14

14 Mar '14

Jeff Hammond <jeff.science(a)gmail.com> writes: > There's an easy solution for "bad" ops: fall back to C&S > implementation the way one does on any shared memory arch when a > particular atomic isn't supported but C&S is. > > This means that no mutexes are required, NICs that have HW support for > NO_OP, REPLACE, SUM, XOR, etc. can use them, and when a user asks for > something silly like PROD, the performance is degraded for those ops > alone and not for anything else. 1. How does the above not justify the same for M**LOC? 2. Now we expect every system to have the equivalent of CMPXCHG16B and that basic types will never be longer than 16B (unless a longer atomic is made available)?

1 0

Re: [mpiwg-rma] RMA info keys/values not listed in appendix
by Rajeev Thakur 14 Mar '14

14 Mar '14

Ah, I didn't see that. Looks like all are there. Rajeev On Mar 14, 2014, at 11:33 AM, William Gropp <wgropp(a)illinois.edu> wrote: > There were a couple included in the latest errata. Are there others that are missing? > > Bill > > William Gropp > Director, Parallel Computing Institute > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > On Mar 14, 2014, at 11:31 AM, Rajeev Thakur wrote: > >> Appendix A.1.5 and A.1.6 on pg 683 list all reserved info keys and values. The ones from the RMA chapter are not listed there though. >> >> Rajeev >> >> _______________________________________________ >> 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 Underwood, Keith D 14 Mar '14

14 Mar '14

I'm sure that wasn't Keith making that objection... ;-) > -----Original Message----- > From: mpiwg-rma [mailto:[email protected]] On > Behalf Of Jeff Hammond > Sent: Friday, March 14, 2014 12:30 PM > To: MPI WG Remote Memory Access working group > Subject: Re: [mpiwg-rma] same_op_no_op > > I'm sure that the WG was too distracted by how many arguments each > function took to think about semantic issues :-) > > I think not making same_op_no_op_replace the default was just an > oversight, as you've previously suggested. I'm sure that Keith has been > consistent to objecting to atomicity of more than one non-trivial (i.e. not > NO_OP or REPLACE) op at the same time. I believe that my previous email > noting how to use C&S emulation addresses that issue though. > > Jeff > > On Fri, Mar 14, 2014 at 11:25 AM, Brian Barrett <brbarret(a)open-mpi.org> > wrote: > > I agree with Rajeev; concurrent access with different ops wasn't undefined > in MPI-2.2, it was erroneous. > > > > During the Forum meetings on RMA, there was strong opposition to > relaxing that semantic, which is how we ended up with same_op_no_op. It > sucked, but it sucked less than the semantics of MPI-2.2. > > > > I'm not opposed to loosening the restrictions (and, in fact, wanted them > looser during MPI-3), but it would be good to understand why we as a group > felt that wasn't ok 2 years ago. > > > > Brian > > > > On Mar 14, 2014, at 6:12 AM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > > > >> Where does it say in MPI 2.2 that concurrent accumulates with different > operations are allowed? > >> > >> On pg 365, ln 29-33, it says two concurrent accumulates that use the same > operation are allowed. > >> > >> • 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. > >> > >> > >> On Mar 14, 2014, at 12:25 AM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > >> > >>> 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 > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > -- > > Brian Barrett > > > > There is an art . . . to flying. The knack lies in learning how to > > throw yourself at the ground and miss. > > Douglas Adams, 'The Hitchhikers Guide to the Galaxy' > > > > _______________________________________________ > > 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] RMA info keys/values not listed in appendix
by William Gropp 14 Mar '14

14 Mar '14

There were a couple included in the latest errata. Are there others that are missing? Bill William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Mar 14, 2014, at 11:31 AM, Rajeev Thakur wrote: > Appendix A.1.5 and A.1.6 on pg 683 list all reserved info keys and values. The ones from the RMA chapter are not listed there though. > > Rajeev > > _______________________________________________ > mpiwg-rma mailing list > mpiwg-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma

1 0

RMA info keys/values not listed in appendix
by Rajeev Thakur 14 Mar '14

14 Mar '14

Appendix A.1.5 and A.1.6 on pg 683 list all reserved info keys and values. The ones from the RMA chapter are not listed there though. Rajeev

1 0

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

14 Mar '14

I'm sure that the WG was too distracted by how many arguments each function took to think about semantic issues :-) I think not making same_op_no_op_replace the default was just an oversight, as you've previously suggested. I'm sure that Keith has been consistent to objecting to atomicity of more than one non-trivial (i.e. not NO_OP or REPLACE) op at the same time. I believe that my previous email noting how to use C&S emulation addresses that issue though. Jeff On Fri, Mar 14, 2014 at 11:25 AM, Brian Barrett <brbarret(a)open-mpi.org> wrote: > I agree with Rajeev; concurrent access with different ops wasn't undefined in MPI-2.2, it was erroneous. > > During the Forum meetings on RMA, there was strong opposition to relaxing that semantic, which is how we ended up with same_op_no_op. It sucked, but it sucked less than the semantics of MPI-2.2. > > I'm not opposed to loosening the restrictions (and, in fact, wanted them looser during MPI-3), but it would be good to understand why we as a group felt that wasn't ok 2 years ago. > > Brian > > On Mar 14, 2014, at 6:12 AM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > >> Where does it say in MPI 2.2 that concurrent accumulates with different operations are allowed? >> >> On pg 365, ln 29-33, it says two concurrent accumulates that use the same operation are allowed. >> >> • 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. >> >> >> On Mar 14, 2014, at 12:25 AM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: >> >>> 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 >>> >>> _______________________________________________ >>> 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 >> > > -- > Brian Barrett > > There is an art . . . to flying. The knack lies in learning how to > throw yourself at the ground and miss. > Douglas Adams, 'The Hitchhikers Guide to the Galaxy' > > _______________________________________________ > 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 Brian Barrett 14 Mar '14

14 Mar '14

I agree with Rajeev; concurrent access with different ops wasn't undefined in MPI-2.2, it was erroneous. During the Forum meetings on RMA, there was strong opposition to relaxing that semantic, which is how we ended up with same_op_no_op. It sucked, but it sucked less than the semantics of MPI-2.2. I'm not opposed to loosening the restrictions (and, in fact, wanted them looser during MPI-3), but it would be good to understand why we as a group felt that wasn't ok 2 years ago. Brian On Mar 14, 2014, at 6:12 AM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > Where does it say in MPI 2.2 that concurrent accumulates with different operations are allowed? > > On pg 365, ln 29-33, it says two concurrent accumulates that use the same operation are allowed. > > • 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. > > > On Mar 14, 2014, at 12:25 AM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > >> 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 >> >> _______________________________________________ >> 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 > -- Brian Barrett There is an art . . . to flying. The knack lies in learning how to throw yourself at the ground and miss. Douglas Adams, 'The Hitchhikers Guide to the Galaxy'

1 0