- mpi-comments - mailman3.cels.anl.gov

Re: [Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL, MPI_ADDRESS_NULL)
by Nils Smeds 22 Oct '21

22 Oct '21

Dan, Thank you for your encouraging response. Firstly, let me state that I have no strong feelings for either MPI_ADDRESS_NULL nor MPI_COMM_NULL other than they would satisfy my sense of "symmetry" or "closure". In my own programming I rarely find myself unclear what buffer address or communicator a specific code section is targeting. Most often it is the pt2pt matching triad (proc,tag,comm) that needs to be tailored to express the "intent" of the code so that an unimplemented fringe case does not pass by unnoticed. (Merely causes a dead-lock - as if that is any help - I know...) My view of the MPI_*_NULL entities in the standard is that they are comparable to NaN in floating point. MPI_TAG_NULL is not a member of the set of valid tags, and can not be matched in any tag comparison operation, not even itself or as "not a member of". MPI_TAG_ANY should not match a message with MPI_TAG_NULL, and there should indeed be no way to create a "real" message with MPI_TAG_NULL. So a statement as you suggested "When the tag argument is MPI_TAG_NULL the only allowed processor argument > is MPI_PROC_NULL" preferably in section 3.2.4 just before the last sentence describing the use of dest=MPI_PROC_NULL would be all that is needed. A probe for such a message (that can never be created as a "real" message) will thus return a status object with a count of 0 and a tag of MPI_TAG_ANY and no change in behaviour to existing implementations. So the updated suggested changes to the standards are: 1. Insert into appendix "A1 Assorted constants": MPI_TAG_NULL 2. Insert into section "9.1.2 Environmental Inquiries" (Line 34, end of first paragraph) [... is also a valid value for MPITAG_UB]. The constant MPI_TAG_NULL shall have a value outside of the 0...MPI_TAG_UB range. 3. Insert into section 3.2.4 before the last sentence (line 42.5): "When the tag argument is MPI_TAG_NULL the only allowed processor argument is MPI_PROC_NULL" 4. Add to section 3.10 "Null processes", last in the section: "*Advice to users:* Note that MPI_TAG_NULL is not a valid tag in the 0..MPI_TAG_UB range. Thus MPI_TAG_NULL is only allowed when the associated processor argument is MPI_PROC_NULL" To avoid a lengthy discussion into what probes of non-existing messages should return as a result, I suggest that the committee sees any triad (proc,tag,comm) where either component has a "NULL" value as defined in the standard (currently only MPI_PROC_NULL exists) is in essence a "NaN"-triad, and returns the already defined result of 0 elements of (MPI_PROC_NULL,MPI_ANY_TAG) as of section 3.10. Also, just by chance, this would not conflict with an introduction of an MPI_COMM_NULL item in the future. On Thu, Oct 21, 2021 at 7:14 PM Dan Holmes <danholmes(a)chi.scot> wrote: > Hi Nils, > > In general, I like the idea of having default/invalid values for these > MPI-related user variables. > > Would MPI_TAG_NULL be valid for a point-to-point send operation that does > NOT use MPI_PROC_NULL but is matched with receive operation at the > destination MPI process that uses MPI_ANY_TAG? Or should this be an > MPI_ERR_ARG/MPI_ERR_TAG error condition? Commonly, codes that use > MPI_ANY_TAG in receive operations must choose an arbitrary valid tag value > to use in the send operations at the source MPI process(es). Permitting the > use of MPI_TAG_NULL in combination with MPI_ANY_TAG might aid debugging > when the matching does not go the way the user expected. However, it would > add complexity to the matching rules/implementation. There is an > interaction here with INFO key assertions such as `mpi_assert_no_any_tag` — > which means the error could be discovered at the sender process -- and > `mpi_assert_only_any_tag` (if that one ever gets accepted into MPI). > > There is already an MPI constant that is commonly set to `(void*)0` (in > C), which is MPI_BOTTOM. Defining MPI_ADDRESS_NULL to be the same value is > not a good idea because MPI_BOTTOM is a valid address; although attempting > to read/write at that address is likely to cause trouble, using it as a > base for a user-defined datatype or a window offset is common/accepted > practice. Would it be sufficient for your purposes to use MPI_BOTTOM as > your “not valid” value? > > IMHO, there would need to be a statement that, “when the comm argument is > MPI_COMM_NULL, the only acceptable value for the source/dest argument is > MPI_PROC_NULL” because asking for the 3rd item from an empty set (for > example) is clearly an error. Your proposal tries to treat MPI_COMM_NULL as > if it is a valid MPI intra-communicator that has size zero, or a valid > inter-communicator that has a remote group of size zero. I think I would > prefer to create MPI_COMM_EMPTY for that purpose, and continue to use > MPI_COMM_NULL for situations that call for an invalid communicator, i.e. > something that can never be used as a communicator without causing an error > condition. > > The phrase used elsewhere in the MPI Standard is “XYZ parameter is > significant only <when condition>” > > Cheers, > Dan. > — > Dr Daniel Holmes PhD > Executive Director > Chief Technology Officer > CHI Ltd > danholmes(a)chi.scot > > > > On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments < > mpi-comments(a)lists.mpi-forum.org> wrote: > > *Summary:* > - Suggestion to introduce MPI_TAG_NULL in the standard with an obviously > illegal value (i.e. <0) > - Explicitly allow Point-to-Point messages to have one of more of: tag > MPI_TAG_NULL, datatype MPI_DATATYPE_NULL, invalid buffer addresses > (including MPI_ADDRESS_NULL) and communicator MPI_COMM_NULL, if (and only > if) the corresponding send or receive argument is MPI_PROC_NULL. > > *Argument:* > When writing code it is useful if it goes off with a bang when you do > something wrong. To catch matching errors in sends and receives I looked > for a MPI_TAG_NULL to use as a default value to catch cases where the tag > was not set correctly. I found that there was no such item. Referring to > the standard I found that tag values are restricted to the values > 0...MPI_TAG_UB, where MPI_TAG_UB (>=32767) can be found using the > MPI_Comm_get_attr() function. > > So I used my own value for MPI_TAG_NULL as -1 and coded away. However, the > MPI implementation I was using blew up when I used it in a MPI_Sendrecv > with the remote task being MPI_PROC_NULL throwing an error message "illegal > tag value", which was no surprise to me since I had set it to this value > explicitly. > > The workaround is of course to put a if( PartnerTask != MPI_PROC_NULL ) { > ... } around every point-to-point call, but I find it unnecessary and > makes the code look more complex. I think that MPI_PROC_NULL was invented > for exactly this purpose, to be a transparent if(...) clause for the > operation. Is there really a need to be restrictive on datat ype, tag or > any other argument when the P2P operation is with MPI_PROC_NULL? > > I would expect implementations to choose MPI_ADDRESS_NULL be equal to > (*) 0 in C and 0_MPI_ADDRESS_KIND in Fortran and MPI_TAG_NULL to be > default integer kind -1. > > *Implementation:* > Append to section "3.10 Null processes" text along the lines of: > > A call to any point-to-point messaging function with a process argument of > MPI_PROC_NULL is allowed to have any value for buffer address, data type, > tag and communicator including MPI_ADDRESS_NULL, MPI_DATATYPE_NULL, > MPI_TAG_NULL and MPI_COMM_NULL without causing an error condition in the > execution. > > > Insert into appendix "A1 Assorted constants" > > MPI_TAG_NULL and MPI_ADDRESS_NULL > > > Insert into section "9.1.2 Environmental Inquiries" (which is an odd > place where Tag values are specified in the standard): > > (Line 34, end of first paragraph) [... is also a valid value for > MPITAG_UB]. The constant MPI_TAG_NULL shall have a value outside of the > 0...MPI_TAG_UB range. The value MPI_TAG_NULL is erroneous to use in any > communication unless the associated process argument is MPI_PROC_NULL. > > > Add to section "15.3.3 Convention for Returning Strings" > > The constant MPI_ADDRESS_NULL can be used as an equivalent to the null > pointer. > > > > > /Nils Smeds > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments > > >

1 0

Re: [Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL, MPI_ADDRESS_NULL)
by Dan Holmes 21 Oct '21

21 Oct '21

Hi Nils, In general, I like the idea of having default/invalid values for these MPI-related user variables. Would MPI_TAG_NULL be valid for a point-to-point send operation that does NOT use MPI_PROC_NULL but is matched with receive operation at the destination MPI process that uses MPI_ANY_TAG? Or should this be an MPI_ERR_ARG/MPI_ERR_TAG error condition? Commonly, codes that use MPI_ANY_TAG in receive operations must choose an arbitrary valid tag value to use in the send operations at the source MPI process(es). Permitting the use of MPI_TAG_NULL in combination with MPI_ANY_TAG might aid debugging when the matching does not go the way the user expected. However, it would add complexity to the matching rules/implementation. There is an interaction here with INFO key assertions such as `mpi_assert_no_any_tag` — which means the error could be discovered at the sender process -- and `mpi_assert_only_any_tag` (if that one ever gets accepted into MPI). There is already an MPI constant that is commonly set to `(void*)0` (in C), which is MPI_BOTTOM. Defining MPI_ADDRESS_NULL to be the same value is not a good idea because MPI_BOTTOM is a valid address; although attempting to read/write at that address is likely to cause trouble, using it as a base for a user-defined datatype or a window offset is common/accepted practice. Would it be sufficient for your purposes to use MPI_BOTTOM as your “not valid” value? IMHO, there would need to be a statement that, “when the comm argument is MPI_COMM_NULL, the only acceptable value for the source/dest argument is MPI_PROC_NULL” because asking for the 3rd item from an empty set (for example) is clearly an error. Your proposal tries to treat MPI_COMM_NULL as if it is a valid MPI intra-communicator that has size zero, or a valid inter-communicator that has a remote group of size zero. I think I would prefer to create MPI_COMM_EMPTY for that purpose, and continue to use MPI_COMM_NULL for situations that call for an invalid communicator, i.e. something that can never be used as a communicator without causing an error condition. The phrase used elsewhere in the MPI Standard is “XYZ parameter is significant only <when condition>” Cheers, Dan. — Dr Daniel Holmes PhD Executive Director Chief Technology Officer CHI Ltd danholmes(a)chi.scot > On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments <mpi-comments(a)lists.mpi-forum.org> wrote: > > Summary: > - Suggestion to introduce MPI_TAG_NULL in the standard with an obviously illegal value (i.e. <0) > - Explicitly allow Point-to-Point messages to have one of more of: tag MPI_TAG_NULL, datatype MPI_DATATYPE_NULL, invalid buffer addresses (including MPI_ADDRESS_NULL) and communicator MPI_COMM_NULL, if (and only if) the corresponding send or receive argument is MPI_PROC_NULL. > > Argument: > When writing code it is useful if it goes off with a bang when you do something wrong. To catch matching errors in sends and receives I looked for a MPI_TAG_NULL to use as a default value to catch cases where the tag was not set correctly. I found that there was no such item. Referring to the standard I found that tag values are restricted to the values 0...MPI_TAG_UB, where MPI_TAG_UB (>=32767) can be found using the MPI_Comm_get_attr() function. > > So I used my own value for MPI_TAG_NULL as -1 and coded away. However, the MPI implementation I was using blew up when I used it in a MPI_Sendrecv with the remote task being MPI_PROC_NULL throwing an error message "illegal tag value", which was no surprise to me since I had set it to this value explicitly. > > The workaround is of course to put a if( PartnerTask != MPI_PROC_NULL ) { ... } around every point-to-point call, but I find it unnecessary and makes the code look more complex. I think that MPI_PROC_NULL was invented for exactly this purpose, to be a transparent if(...) clause for the operation. Is there really a need to be restrictive on datat ype, tag or any other argument when the P2P operation is with MPI_PROC_NULL? > > I would expect implementations to choose MPI_ADDRESS_NULL be equal to (*) 0 in C and 0_MPI_ADDRESS_KIND in Fortran and MPI_TAG_NULL to be default integer kind -1. > > Implementation: > Append to section "3.10 Null processes" text along the lines of: > A call to any point-to-point messaging function with a process argument of MPI_PROC_NULL is allowed to have any value for buffer address, data type, tag and communicator including MPI_ADDRESS_NULL, MPI_DATATYPE_NULL, MPI_TAG_NULL and MPI_COMM_NULL without causing an error condition in the execution. > > Insert into appendix "A1 Assorted constants" > MPI_TAG_NULL and MPI_ADDRESS_NULL > > Insert into section "9.1.2 Environmental Inquiries" (which is an odd place where Tag values are specified in the standard): > (Line 34, end of first paragraph) [... is also a valid value for MPITAG_UB]. The constant MPI_TAG_NULL shall have a value outside of the 0...MPI_TAG_UB range. The value MPI_TAG_NULL is erroneous to use in any communication unless the associated process argument is MPI_PROC_NULL. > > Add to section "15.3.3 Convention for Returning Strings" > The constant MPI_ADDRESS_NULL can be used as an equivalent to the null pointer. > > > > /Nils Smeds > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments

1 0

Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL, MPI_ADDRESS_NULL)
by Nils Smeds 21 Oct '21

21 Oct '21

*Summary:* - Suggestion to introduce MPI_TAG_NULL in the standard with an obviously illegal value (i.e. <0) - Explicitly allow Point-to-Point messages to have one of more of: tag MPI_TAG_NULL, datatype MPI_DATATYPE_NULL, invalid buffer addresses (including MPI_ADDRESS_NULL) and communicator MPI_COMM_NULL, if (and only if) the corresponding send or receive argument is MPI_PROC_NULL. *Argument:* When writing code it is useful if it goes off with a bang when you do something wrong. To catch matching errors in sends and receives I looked for a MPI_TAG_NULL to use as a default value to catch cases where the tag was not set correctly. I found that there was no such item. Referring to the standard I found that tag values are restricted to the values 0...MPI_TAG_UB, where MPI_TAG_UB (>=32767) can be found using the MPI_Comm_get_attr() function. So I used my own value for MPI_TAG_NULL as -1 and coded away. However, the MPI implementation I was using blew up when I used it in a MPI_Sendrecv with the remote task being MPI_PROC_NULL throwing an error message "illegal tag value", which was no surprise to me since I had set it to this value explicitly. The workaround is of course to put a if( PartnerTask != MPI_PROC_NULL ) { ... } around every point-to-point call, but I find it unnecessary and makes the code look more complex. I think that MPI_PROC_NULL was invented for exactly this purpose, to be a transparent if(...) clause for the operation. Is there really a need to be restrictive on datat ype, tag or any other argument when the P2P operation is with MPI_PROC_NULL? I would expect implementations to choose MPI_ADDRESS_NULL be equal to (*) 0 in C and 0_MPI_ADDRESS_KIND in Fortran and MPI_TAG_NULL to be default integer kind -1. *Implementation:* Append to section "3.10 Null processes" text along the lines of: A call to any point-to-point messaging function with a process argument of MPI_PROC_NULL is allowed to have any value for buffer address, data type, tag and communicator including MPI_ADDRESS_NULL, MPI_DATATYPE_NULL, MPI_TAG_NULL and MPI_COMM_NULL without causing an error condition in the execution. Insert into appendix "A1 Assorted constants" MPI_TAG_NULL and MPI_ADDRESS_NULL Insert into section "9.1.2 Environmental Inquiries" (which is an odd place where Tag values are specified in the standard): (Line 34, end of first paragraph) [... is also a valid value for MPITAG_UB]. The constant MPI_TAG_NULL shall have a value outside of the 0...MPI_TAG_UB range. The value MPI_TAG_NULL is erroneous to use in any communication unless the associated process argument is MPI_PROC_NULL. Add to section "15.3.3 Convention for Returning Strings" The constant MPI_ADDRESS_NULL can be used as an equivalent to the null pointer. /Nils Smeds

1 0

Make MPI_Precv_init to return an array of MPI_Request to avoid MPI_Wait* MPI_Test* routines duplication
by BRELLE, EMMANUEL 15 Oct '21

15 Oct '21

Dear MPI-forum members, This comment applies to MPI-4.0 standard (https://www.mpi-forum.org/docs/mpi-4.0/mpi40-report.pdf) Having partitioned communication looks very promising to speed up applications, but I am wondering why did you introduce "MPI_Parrived"(page 151) routine instead of making "MPI_Precv_init"(page 147) returning an array of MPI_Request. To my understanding, one of the need for partitioned communications is runtimes that exchange set of "tasks" : computations do not immediately need all the partitions to continue. Partitioned communication enabled message aggregation but a single partition could be sufficient to unlock computation. In this case, processes will have to search over each partition to catch a completed ones that not have been already found. This is what MPI_Waitany (page 116) does with an array of MPI_Request. It would be have been therefore more interesting to handle explicit MPI_Request objects. I would appreciate that MPI_Precv_init returns an array of MPI_request in addition of the main MPI_request (p147 line 39). MPI_Parrived could be deprecated for MPI_Test on these sub-requests. In extension this would also avoid to duplicate MPI_Testany(p117), MPI_Waitall(p118), MPI_Testall(p119), MPI_Waitsome (p 120) and MPI_Testsome(p121). In a first idea, MPI users would provide this array of the size of the number of partitions as an extra parmeter to MPI_Precv_init. If the array is valid (for example not a special value "MPI_NO_REQUESTS") these MPI_Request would be created by MPI_Precv_init and freed by a call of MPI_Request_free on the main request. Waiting all the sub-requests would be equivalent to wait the main request. Like requests from MPI_Irecv, it would be invalid to call MPI_Start on these sub-requests. Regards, Emmanuel Brelle

1 0

Re: [Mpi-comments] MPI 4.0 and Fortran about the Problem with Code Movement and MPI_F_SYNC_REG (section 19.1.17)
by Rolf Rabenseifner 19 Aug '21

19 Aug '21

Dear Dimitri, > I 've a question about the use of MPI_F_SYNC_REG to avoid optimisation > problem. > > If I understand well a way to avoid change in order is to use > MPI_F_SYNC_REG after the wait like this : <type>, ASYNCHRONOUS :: buf ! this is also needed!!! > call MPI_ISEND(buf,...,req) > ! some work > call MPI_WAIT(req,...) > if (.not. MPI_ASYNC_PROTECTS_NONBLOCKING) call MPI_F_SYNC_REG(buf) > buf = val2 Only half correct, because the ASYNCHRONOUS declaration was missing. I added it. You are allowed to add "ASYNCHRONOUS" in the unit where it is relevant. > My question is what in this solution prevent the compiler to put the > "call MPI_WAIT" after the line "buf = val2" ? If your compiler supports Fortran TS29113 then your compiler move accesses to the ASYNCHRONOUS buf across subroutine calls. In that case, your MPI library (if compiled for that compiler) should set MPI_ASYNC_PROTECTS_NONBLOCKING = .TRUE. and therefore the additional call MPI_F_SYNC_REG(buf) is already removed at compile time. If your compiler does not support Fortran TS29113 then your MPI library (if compiled for that compiler) must set MPI_ASYNC_PROTECTS_NONBLOCKING = .FALSE. and the "if (.not. MPI_ASYNC_PROTECTS_NONBLOCKING)" testing is removed at compile time and the "call MPI_F_SYNC_REG(buf)" is always done. In general, the compiler must not - change the sequence of library calls that it cannot analyze, - and must not move the assignment of "buf = val2" across a subroutine call with this buf in the argument list, again provided the compiler cannot analyze what MPI_F_SYNC_REG is doing. Based on these two rules together, the MPI_WAIT call and the assignment cannot be interchanged. I hope this answers your question. For more details about MPI and Fortran, you may look at course chapter 4 and 5 in my MPI-4.0 course: https://www.hlrs.de/training/par-prog-ws/MPI-course-material Best regards Rolf ----- Original Message ----- > From: "Comments on the MPI Standard" <mpi-comments(a)lists.mpi-forum.org> > To: "Comments on the MPI Standard" <mpi-comments(a)lists.mpi-forum.org> > Cc: "Dimitri Lecas" <dimitri.lecas(a)idris.fr> > Sent: Thursday, August 19, 2021 11:07:17 AM > Subject: [Mpi-comments] MPI 4.0 and Fortran about the Problem with Code Movement and MPI_F_SYNC_REG (section 19.1.17) > Hello, > > I 've a question about the use of MPI_F_SYNC_REG to avoid optimisation > problem. > > If I understand well a way to avoid change in order is to use > MPI_F_SYNC_REG after the wait like this : > > > call MPI_ISEND(buf,...,req) > ! some work > call MPI_WAIT(req,...) > if (.not. MPI_ASYNC_PROTECTS_NONBLOCKING) call MPI_F_SYNC_REG(buf) > buf = val2 > > > My question is what in this solution prevent the compiler to put the > "call MPI_WAIT" after the line "buf = val2" ? > > > Regards > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .

1 0

MPI 4.0 and Fortran about the Problem with Code Movement and MPI_F_SYNC_REG (section 19.1.17)
by Dimitri Lecas 19 Aug '21

19 Aug '21

Hello, I 've a question about the use of MPI_F_SYNC_REG to avoid optimisation problem. If I understand well a way to avoid change in order is to use MPI_F_SYNC_REG after the wait like this : call MPI_ISEND(buf,...,req) ! some work call MPI_WAIT(req,...) if (.not. MPI_ASYNC_PROTECTS_NONBLOCKING) call MPI_F_SYNC_REG(buf) buf = val2 My question is what in this solution prevent the compiler to put the "call MPI_WAIT" after the line "buf = val2" ? Regards

1 0

Re: [Mpi-comments] mpi-comments Digest, Vol 13, Issue 1
by HOLMES Daniel 15 Jun '20

15 Jun '20

Hi Sajid Ali, This has been recorded as issue 297: https://github.com/mpi-forum/mpi-issues/issues/297 and is addressed in pull request 244: https://github.com/mpi-forum/mpi-standard/pull/244 Thank you for bringing this to our attention. Our sincere apologies for all ill-feeling this casual usage of unacceptable language has caused. Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 14 Jun 2020, at 18:00, mpi-comments-request(a)lists.mpi-forum.org<mailto:[email protected]> wrote: Send mpi-comments mailing list submissions to mpi-comments(a)lists.mpi-forum.org<mailto:[email protected]> To subscribe or unsubscribe via the World Wide Web, visit https://lists.mpi-forum.org/mailman/listinfo/mpi-comments or, via email, send a message with subject or body 'help' to mpi-comments-request(a)lists.mpi-forum.org You can reach the person managing the list at mpi-comments-owner(a)lists.mpi-forum.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mpi-comments digest..." Today's Topics: 1. Inclusive language (Sajid Ali) ---------------------------------------------------------------------- Message: 1 Date: Sun, 14 Jun 2020 11:42:53 -0500 From: Sajid Ali <sajidsyed2021(a)u.northwestern.edu> To: mpi-comments(a)lists.mpi-forum.org Subject: [Mpi-comments] Inclusive language Message-ID: <CAOGsD9icLeaF2hV0Y8++JW6AJC6R15_56A004-ACMX4k1_=BgA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi MPI-Forum, This is request to move away from the master-slave terminology currently used in the following locations in the 2019 draft specification : - section 6.4.1 : page 256, line 46 - example 6.5.3 page 272 and page 273 These would be better described by supervisor/executor or manager/worker or anything the members of "Groups, Contexts, Communicators, Caching" working group see fit. Thank You, Sajid Ali | PhD Candidate Applied Physics Northwestern University s-sajid-ali.github.io -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mpi-forum.org/pipermail/mpi-comments/attachments/20200614/c77a…> ------------------------------ Subject: Digest Footer _______________________________________________ mpi-comments mailing list mpi-comments(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-comments ------------------------------ End of mpi-comments Digest, Vol 13, Issue 1 *******************************************

1 0

Re: [Mpi-comments] Inclusive language
by Martin Schulz 15 Jun '20

15 Jun '20

Dear Sajid, Thank you for this comment - we certainly agree and we will address this in the next version of the MPI standard. Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de > On 14. Jun 2020, at 18:42, Sajid Ali via mpi-comments <mpi-comments(a)lists.mpi-forum.org> wrote: > > Hi MPI-Forum, > > This is request to move away from the master-slave terminology currently used in the following locations in the 2019 draft specification : > - section 6.4.1 : page 256, line 46 > - example 6.5.3 page 272 and page 273 > These would be better described by supervisor/executor or manager/worker or anything the members of "Groups, Contexts, Communicators, Caching" working group see fit. > > Thank You, > Sajid Ali | PhD Candidate > Applied Physics > Northwestern University > s-sajid-ali.github.io <http://s-sajid-ali.github.io/>_______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments

1 0

Inclusive language
by Sajid Ali 14 Jun '20

14 Jun '20

Hi MPI-Forum, This is request to move away from the master-slave terminology currently used in the following locations in the 2019 draft specification : - section 6.4.1 : page 256, line 46 - example 6.5.3 page 272 and page 273 These would be better described by supervisor/executor or manager/worker or anything the members of "Groups, Contexts, Communicators, Caching" working group see fit. Thank You, Sajid Ali | PhD Candidate Applied Physics Northwestern University s-sajid-ali.github.io

1 0

User-Defined Reduction Operations: possible enhancement
by Gilles Gouaillardet 01 Mar '20

01 Mar '20

Dear MPI Forum, In chapter 5.9.5 (User-Defined Reduction Operations), page 185 of MPI 3.1 and page 187 of MPI 2019 Draft, it reads : Advice to implementors. We outline below a naive and inefficient implementation of MPI_REDUCE not supporting the "in place" option. Strictly speaking, the outlined implementation is only valid for intra-communicators (and does not support the "in place" option), so you might consider amending this line before MPI 2019 is out. Best regards, Gilles

1 0