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

Re: [Mpi3-rma] MPI_Fetch_and_op and predefined datatypes
by Jim Dinan 26 Oct '12

26 Oct '12

Did we also intend to include pair types for F&Op? They are allowed in reductions. ~Jim. On 10/26/12 4:07 PM, Torsten Hoefler wrote: > On Fri, Oct 26, 2012 at 04:22:02PM -0500, Jeff Hammond wrote: >> I don't want to wait for 3.1. Are we seriously going to require >> MPI_WCHAR support in F&Op to be MPI-3 compliant? That makes no sense. > I think the intent of "Any of the predefined operations for MPI_REDUCE, > as well as MPI_NO_OP or MPI_REPLACE, can be specified as op; > user-defined functions cannot be used." is clear. One could even dream > up a use-case for MPI_WCHAR if one wants to emulate an atomic read > (using MPI_NO_OP). > > I will not vote against an errata if you want to propose text and > initiate the process. > > Best, > Torsten >

1 0

Re: [Mpi3-rma] MPI_Fetch_and_op and predefined datatypes
by Jeff Hammond 26 Oct '12

26 Oct '12

I think Hubert has enumerated the text changes already. I'm happy to let him work on the errata. I have a BGQ to accept :-) Jeff On Fri, Oct 26, 2012 at 4:07 PM, Torsten Hoefler <htor(a)illinois.edu> wrote: > On Fri, Oct 26, 2012 at 04:22:02PM -0500, Jeff Hammond wrote: >> I don't want to wait for 3.1. Are we seriously going to require >> MPI_WCHAR support in F&Op to be MPI-3 compliant? That makes no sense. > I think the intent of "Any of the predefined operations for MPI_REDUCE, > as well as MPI_NO_OP or MPI_REPLACE, can be specified as op; > user-defined functions cannot be used." is clear. One could even dream > up a use-case for MPI_WCHAR if one wants to emulate an atomic read > (using MPI_NO_OP). > > I will not vote against an errata if you want to propose text and > initiate the process. > > Best, > Torsten > > -- > ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- > Torsten Hoefler | Assistant Professor > Dept. of Computer Science | ETH Zï¿½rich > Universitï¿½tsstrasse 6 | Zurich-8092, Switzerland > CAB E 64.1 | Phone: +41 76 309 79 29 > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [Mpi3-rma] MPI_Fetch_and_op and predefined datatypes
by Jeff Hammond 26 Oct '12

26 Oct '12

I don't want to wait for 3.1. Are we seriously going to require MPI_WCHAR support in F&Op to be MPI-3 compliant? That makes no sense. Jeff On Fri, Oct 26, 2012 at 3:47 PM, Torsten Hoefler <htor(a)illinois.edu> wrote: > Agreed. This wording change makes things more clear and correct. I would > not suggest this as an errata item, rather directly fix it in 3.1. We > should make a decision on this at the next meeting! > > Thanks Hubert! > > Torsten > > On Fri, Oct 26, 2012 at 02:39:20PM +0000, Hubert Ritzdorf wrote: >> Hi, >> >> Page 429, Line 41-42 specifies for MPI_Fetch_and_op: >> >> The datatype argument must be a predefi?ned datatype. >> >> I think it should be: >> >> The datatype argument must be a MPI basic datatype (cf. Section 5.9.2 on >> page 176). >> >> Reasons: >> >> (*) This would be consistent to the reduce functions and >> MPI_Compare_and_swap >> and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, >> MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. >> >> (*) MPI_Compare_and_swap accepts handles created by >> MPI_TYPE_CREATE_F90_INTEGER ( they are contained in Fortran integer >> category). >> >> (*) Predefined datatypes such as MPI_WCHAR or MPI_PACKED are useless in >> MPI_Fetch_and_op. >> >> Additionally, on Page 430, Line 39: >> predefined datatypes >> should be replaced by >> basic datatypes >> since Section 5.9.2 defines the MPI basic datatypes and not the >> predefined >> datatypes (which are defined in Tables 3.x). >> >> Hubert > >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > -- > ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- > Torsten Hoefler | Assistant Professor > Dept. of Computer Science | ETH Zï¿½rich > Universitï¿½tsstrasse 6 | Zurich-8092, Switzerland > CAB E 64.1 | Phone: +41 76 309 79 29 > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [Mpi3-rma] MPI_Fetch_and_op and predefined datatypes
by Torsten Hoefler 26 Oct '12

26 Oct '12

On Fri, Oct 26, 2012 at 04:22:02PM -0500, Jeff Hammond wrote: > I don't want to wait for 3.1. Are we seriously going to require > MPI_WCHAR support in F&Op to be MPI-3 compliant? That makes no sense. I think the intent of "Any of the predefined operations for MPI_REDUCE, as well as MPI_NO_OP or MPI_REPLACE, can be specified as op; user-defined functions cannot be used." is clear. One could even dream up a use-case for MPI_WCHAR if one wants to emulate an atomic read (using MPI_NO_OP). I will not vote against an errata if you want to propose text and initiate the process. Best, Torsten -- ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- Torsten Hoefler | Assistant Professor Dept. of Computer Science | ETH Zï¿½rich Universitï¿½tsstrasse 6 | Zurich-8092, Switzerland CAB E 64.1 | Phone: +41 76 309 79 29

1 0

Re: [Mpi3-rma] MPI_Fetch_and_op and predefined datatypes
by Torsten Hoefler 26 Oct '12

26 Oct '12

Agreed. This wording change makes things more clear and correct. I would not suggest this as an errata item, rather directly fix it in 3.1. We should make a decision on this at the next meeting! Thanks Hubert! Torsten On Fri, Oct 26, 2012 at 02:39:20PM +0000, Hubert Ritzdorf wrote: > Hi, > > Page 429, Line 41-42 specifies for MPI_Fetch_and_op: > > The datatype argument must be a predefi?ned datatype. > > I think it should be: > > The datatype argument must be a MPI basic datatype (cf. Section 5.9.2 on > page 176). > > Reasons: > > (*) This would be consistent to the reduce functions and > MPI_Compare_and_swap > and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, > MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. > > (*) MPI_Compare_and_swap accepts handles created by > MPI_TYPE_CREATE_F90_INTEGER ( they are contained in Fortran integer > category). > > (*) Predefined datatypes such as MPI_WCHAR or MPI_PACKED are useless in > MPI_Fetch_and_op. > > Additionally, on Page 430, Line 39: > predefined datatypes > should be replaced by > basic datatypes > since Section 5.9.2 defines the MPI basic datatypes and not the > predefined > datatypes (which are defined in Tables 3.x). > > Hubert > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- Torsten Hoefler | Assistant Professor Dept. of Computer Science | ETH Zï¿½rich Universitï¿½tsstrasse 6 | Zurich-8092, Switzerland CAB E 64.1 | Phone: +41 76 309 79 29

1 0

Re: [Mpi3-rma] MPI_Fetch_and_op and predefined datatypes
by Jeff Hammond 26 Oct '12

26 Oct '12

I agree with everything said here. Jeff On Fri, Oct 26, 2012 at 9:39 AM, Hubert Ritzdorf <Hubert.Ritzdorf(a)emea.nec.com> wrote: > Hi, > > Page 429, Line 41-42 specifies for MPI_Fetch_and_op: > > The datatype argument must be a predefi?ned datatype. > > I think it should be: > > The datatype argument must be a MPI basic datatype (cf. Section 5.9.2 on > page 176). > > Reasons: > > (*) This would be consistent to the reduce functions and > MPI_Compare_and_swap > and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, > MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. > > (*) MPI_Compare_and_swap accepts handles created by > MPI_TYPE_CREATE_F90_INTEGER ( they are contained in Fortran integer > category). > > (*) Predefined datatypes such as MPI_WCHAR or MPI_PACKED are useless in > MPI_Fetch_and_op. > > > Additionally, on Page 430, Line 39: > predefined datatypes > should be replaced by > basic datatypes > since Section 5.9.2 defines the MPI basic datatypes and not the predefined > datatypes (which are defined in Tables 3.x). > > Hubert > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

[Mpi3-rma] MPI_Fetch_and_op and predefined datatypes
by Hubert Ritzdorf 26 Oct '12

26 Oct '12

Hi, Page 429, Line 41-42 specifies for MPI_Fetch_and_op: The datatype argument must be a predefi?ned datatype. I think it should be: The datatype argument must be a MPI basic datatype (cf. Section 5.9.2 on page 176). Reasons: (*) This would be consistent to the reduce functions and MPI_Compare_and_swap and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. (*) MPI_Compare_and_swap accepts handles created by MPI_TYPE_CREATE_F90_INTEGER ( they are contained in Fortran integer category). (*) Predefined datatypes such as MPI_WCHAR or MPI_PACKED are useless in MPI_Fetch_and_op. Additionally, on Page 430, Line 39: predefined datatypes should be replaced by basic datatypes since Section 5.9.2 defines the MPI basic datatypes and not the predefined datatypes (which are defined in Tables 3.x). Hubert

1 0

[Mpi3-rma] Errata: Info Appendices
by Jim Dinan 24 Oct '12

24 Oct '12

Hi All, It looks like we will need an errata for Appendix A.1.5 Info Keys, to add: accumulate_ordering accumulate_ops same_size alloc_shared_noncontig In A1.6 Info Values, also add: same_op same_op_no_op rar raw waw war Cheers, ~Jim.

1 0

Re: [Mpi3-rma] Info accumulate_ops
by Hubert Ritzdorf 23 Oct '12

23 Oct '12

Hi Thorsten and Jim, thanks for the advice. My fault. I didn't carefully read the section "SEMANTICS AND CORRECTNESS" in the (old) document. Sorry to bother you Hubert ________________________________________ From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] Sent: Tuesday, October 23, 2012 5:13 PM To: mpi3-rma(a)lists.mpi-forum.org Subject: Re: [Mpi3-rma] Info accumulate_ops +1 to Torsten's comment. My reading of the current text "default" would indicate that the user should be able to query this info key and get same_op_no_op unless they have set it to same_op. If this is not allowed or what we intended, an errata to clarify this seems reasonable. We could indicate a text change from: The default is same_op_no_op. to something like: When this info key is not specified, the default behavior assumes same_op_no_op. Hubert, concurrent accumulate operations with different ops, targeting the same location is forbidden by the MPI-2 and MPI-3 standards. We added an exception for no_op in MPI-3, which the user can disable as a performance hint. ~Jim. On 10/19/12 1:38 PM, Torsten Hoefler wrote: > On Tue, Oct 16, 2012 at 01:35:08PM +0000, Hubert Ritzdorf wrote: >> Hi, >> >> I think that there is a problem in the definition of info argument >> "accumulate_ops" of MPI_Win_create functions (Page 406, Line 4-9 >> of MPI 3.0 document). >> >> (*) A value is missing if not all concurrent accumulate calls perform the >> same operation. >> Possible values might be: "not_same_op" or "false" > This would be illegal (as described in the semantics section). The NO_OP > was an exception to allow querying a flag with our "fake atomic reads" > while performing atomic updates CAS etc.. So really only the two > mentioned combinations are legal. > >> (*) The actual default value of "same_op_no_op" breaks the backward >> compatibility and causes problems in portability of applications, >> since a MPI >> implementation is not required to evaluate (recognize) info keys. >> Therefore, "not_same_op" must be the default value of info argument >> "accumulate_ops". > Default value means that this is the default semantic if the key is not > set (or not evaluated). So a valid user program in MPI-2.2 was only > allowed to use the same OP for concurrent accumulates. In MPI-3.0 it may > use the same op and also NO_OP in addition. Thus, this richer semantic > cannot break backward compatibility. Setting the info key enables the > user to enable the more limited MPI-2.2 semantics which may unlock a set > of richer optimizations possible in the library. > > Best, > Torsten > _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma Click https://www.mailcontrol.com/sr/5mNGp1xC+PTGX2PQPOmvUi5k6UwC8217lo8Osznu0yDs… to report this email as spam.

1 0

Re: [Mpi3-rma] Info accumulate_ops
by Jim Dinan 23 Oct '12

23 Oct '12

+1 to Torsten's comment. My reading of the current text "default" would indicate that the user should be able to query this info key and get same_op_no_op unless they have set it to same_op. If this is not allowed or what we intended, an errata to clarify this seems reasonable. We could indicate a text change from: The default is same_op_no_op. to something like: When this info key is not specified, the default behavior assumes same_op_no_op. Hubert, concurrent accumulate operations with different ops, targeting the same location is forbidden by the MPI-2 and MPI-3 standards. We added an exception for no_op in MPI-3, which the user can disable as a performance hint. ~Jim. On 10/19/12 1:38 PM, Torsten Hoefler wrote: > On Tue, Oct 16, 2012 at 01:35:08PM +0000, Hubert Ritzdorf wrote: >> Hi, >> >> I think that there is a problem in the definition of info argument >> "accumulate_ops" of MPI_Win_create functions (Page 406, Line 4-9 >> of MPI 3.0 document). >> >> (*) A value is missing if not all concurrent accumulate calls perform the >> same operation. >> Possible values might be: "not_same_op" or "false" > This would be illegal (as described in the semantics section). The NO_OP > was an exception to allow querying a flag with our "fake atomic reads" > while performing atomic updates CAS etc.. So really only the two > mentioned combinations are legal. > >> (*) The actual default value of "same_op_no_op" breaks the backward >> compatibility and causes problems in portability of applications, >> since a MPI >> implementation is not required to evaluate (recognize) info keys. >> Therefore, "not_same_op" must be the default value of info argument >> "accumulate_ops". > Default value means that this is the default semantic if the key is not > set (or not evaluated). So a valid user program in MPI-2.2 was only > allowed to use the same OP for concurrent accumulates. In MPI-3.0 it may > use the same op and also NO_OP in addition. Thus, this richer semantic > cannot break backward compatibility. Setting the info key enables the > user to enable the more limited MPI-2.2 semantics which may unlock a set > of richer optimizations possible in the library. > > Best, > Torsten >

1 0