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

Fortran naming schemes
by Gregor Corbin 18 Oct '22

18 Oct '22

Dear MPI-Forum, I have some difficulties to interpret the naming schemes in section 19.1.5 (MPI 4.0 standard): Consider two routines (e.g. MPI_Send, MPI_Recv) in the same Fortran support method (e.g. 'use mpi_f08'), that both take a choice buffer argument. Does the Standard (a) allow to implement one routine with naming scheme 1A (MPI_Send_f08) and the other with scheme 1B (MPI_Recv_f08ts), (b) demand that 1B (_f08ts) is used either for all routines with choice buffer arguments or none, (c) something else entirely? My interpretation of this paragraph(p.798, 5-7) The mpi and mpi_f08 modules and the mpif.h include file will each correspond to exactly one implementation scheme from Table 19.1. However, the MPI library may contain multiple implementation schemes from Table 19.1. depends whether there are only two distinct naming schemes 1 and 2(each with two sub-options A and B) or four distinct naming schemes 1A, 1B, 2A and 2B. The first would imply (a), the second would imply (b). On the other hand, p.798, line 1-3: To set MPI_SUBARRAYS_SUPPORTED to .TRUE. within a Fortran support method, it is required that all nonblocking and split-collective routines with buffer arguments are implemented according to 1B and 2B implies option (a). Best, Gregor

1 0

Re: [Mpi-comments] non-collective version of MPI_File_set_view
by Wei-Keng Liao 26 Feb '22

26 Feb '22

I notice the following statement in the MPI standard. "MPI_FILE_SET_VIEW is collective; the values for datarep and the extents of etype in the file data representation must be identical on all processes in the group; values for disp, filetype, and info may vary." Is it safe to say the requirement of identical etype extents applies only when shared file pointer is used? For individual file pointers, it looks like this requirement is not necessary. Wei-keng > On Feb 25, 2022, at 3:04 PM, Wei-Keng Liao via mpi-comments <mpi-comments(a)lists.mpi-forum.org> wrote: > > I would like to suggest a non-collective version of MPI_File_set_view. > The current MPI_File_set_view is defines as the following. > MPI_FILE_SET_VIEW(fh, disp, etype, filetype, datarep, info) > > The last two arguments, datarep and info, may be necessary to be > set collectively, but disp, etype, and filetype are only relevant > to the calling process. > > It is not rare to see in today's MPI-IO programs the interleaved > calls to collective and independent file read/write functions. > For example, an application writes to multiple variables of different > sizes. Large variables are partitioned among processes while small > ones are read/written by rank 0 only. Accessing partitioned variables > often uses filetype, such as MPI_Type_create_subarray, to set the view. > Having only the collective version of MPI_File_set_view introduces a > penalty for processes not accessing small variables in this scenario. > To deal with this issue, PnetCDF opens the file twice, one with > MPI_COMM_WORLD and the other with MPI_COMM_SELF, so the latter can > be used to do independent I/O. > > A non-collective version of MPI_File_set_view can look similar, but > without the last two arguments, datarep and info. > > An alternative is to create a new set of MPI I/O functions that add > the three arguments disp, etype, and filetype. For example, a new > write function corresponds to > MPI_FILE_WRITE(fh, buf, count, datatype, status) > will be > MPI_FILE_WRITE_x(fh, buf, count, datatype, disp, etype, filetype, status) > > > Wei-keng Liao > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://urldefense.com/v3/__https://lists.mpi-forum.org/mailman/listinfo/mp…

1 0

non-collective version of MPI_File_set_view
by Wei-Keng Liao 25 Feb '22

25 Feb '22

I would like to suggest a non-collective version of MPI_File_set_view. The current MPI_File_set_view is defines as the following. MPI_FILE_SET_VIEW(fh, disp, etype, filetype, datarep, info) The last two arguments, datarep and info, may be necessary to be set collectively, but disp, etype, and filetype are only relevant to the calling process. It is not rare to see in today's MPI-IO programs the interleaved calls to collective and independent file read/write functions. For example, an application writes to multiple variables of different sizes. Large variables are partitioned among processes while small ones are read/written by rank 0 only. Accessing partitioned variables often uses filetype, such as MPI_Type_create_subarray, to set the view. Having only the collective version of MPI_File_set_view introduces a penalty for processes not accessing small variables in this scenario. To deal with this issue, PnetCDF opens the file twice, one with MPI_COMM_WORLD and the other with MPI_COMM_SELF, so the latter can be used to do independent I/O. A non-collective version of MPI_File_set_view can look similar, but without the last two arguments, datarep and info. An alternative is to create a new set of MPI I/O functions that add the three arguments disp, etype, and filetype. For example, a new write function corresponds to MPI_FILE_WRITE(fh, buf, count, datatype, status) will be MPI_FILE_WRITE_x(fh, buf, count, datatype, disp, etype, filetype, status) Wei-keng Liao

1 0

Re: [Mpi-comments] is MPI_Igather thread-safe?
by Joseph Schuchart 15 Jan '22

15 Jan '22

Jonas, The MPI standard states in §6.12 that > All processes must call collective operations (blocking and nonblocking) in the same order per communicator. In your first example (the one posted on SO) this is not the case because there is no ordering among the threads. Two processes might post Igather with different root arguments in a different order. The operations do not match, which is erroneous. The results can a deadlock, an error, or the hounds of hell coming at you. I don't think your second example is correct either: All threads start the same operation without inter-thread synchronization so they can be interleaved at the MPI level. The Igather that Thread 1 starts in Process 1 might be matched with the Igather started on Thread 2 on Process 2 (if Thread 1 starts its Igather before Thread 2 on Process 1 and Thread 2 posts its Igather before Thread 1 on Process 2). So Thread 1 will receive the wrong data. HTH Joseph On 1/15/22 6:33 AM, Jonas Thies via mpi-comments wrote: > > Dear MPI forum, > > I posted a technical question on StackOverflow and was advised to ask > it in this mailing list. > > The original post is here: > https://stackoverflow.com/questions/70697604/is-mpi-igather-thread-safe > > In a nutshell, I am trying to call independent MPI_Igathers in an > OpenMP-parallel for-loop (after testing for MPI_THREAD_MULTIPLE), > > and am getting a deadlock apparently caused by mismatched sends and > receives, even in a very much stripped down example. > > Any help on wether my code is not standard-conforming would be greatly > appreciated. I attached two versions of the code for convenience, one > of them is also in the StackOverflow post. The _v2 version does not > deadlock but produces incorrect results when run with multiple MPI > processes and multiple OpenMP thread per process. > > Thanks and best wishes, > > Jonas > > -- > *J. Thies* > Assistant Professor > > TU Delft > Faculty Electrical Engineering, Mathematics and Computer Science > Institute of Applied Mathematics and High Performance Computing Center > Mekelweg 4 > 2628 CD Delft > > T +31 15 27 XXXX > *J.Thies(a)tudelft.nl* > > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments

1 0

is MPI_Igather thread-safe?
by Jonas Thies 15 Jan '22

15 Jan '22

Dear MPI forum, I posted a technical question on StackOverflow and was advised to ask it in this mailing list. The original post is here: https://stackoverflow.com/questions/70697604/is-mpi-igather-thread-safe In a nutshell, I am trying to call independent MPI_Igathers in an OpenMP-parallel for-loop (after testing for MPI_THREAD_MULTIPLE), and am getting a deadlock apparently caused by mismatched sends and receives, even in a very much stripped down example. Any help on wether my code is not standard-conforming would be greatly appreciated. I attached two versions of the code for convenience, one of them is also in the StackOverflow post. The _v2 version does not deadlock but produces incorrect results when run with multiple MPI processes and multiple OpenMP thread per process. Thanks and best wishes, Jonas -- *J. Thies* Assistant Professor TU Delft Faculty Electrical Engineering, Mathematics and Computer Science Institute of Applied Mathematics and High Performance Computing Center Mekelweg 4 2628 CD Delft T +31 15 27 XXXX *J.Thies(a)tudelft.nl*

1 0

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

22 Oct '21

Dan and Nils, I agree to you both - therefore no objection from my side. ----- Original Message ----- > From: "Nils Smeds" <nils.smeds(a)gmail.com> > To: "Comments on the MPI Standard" <mpi-comments(a)lists.mpi-forum.org> > Cc: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Sent: Friday, October 22, 2021 3:25:52 PM > Subject: Re: [Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL, MPI_ADDRESS_NULL) > No I certainly do not hope so, > > I would suggest that only an MPI implementation with a "pedantic" mode > would check for this. For any production level implementation the check for > MPI_PROC_NULL (if present in the implementation) will be sufficient. If > MPI_TAG_NULL is provided with a valid processor argument (against the > suggested standard wording) the probe code will run through all pending > messages and not find any matching tag since MPI_TAG_NULL is not inside the > 0..MPI_TAG_UB range. Just as a probe for MPI_PROC_NULL today could > (should?) be scanning all messages. > > Probes with either MPI_PROC_NULL or MPI_TAG_NONE should not need fast > lanes. Let them suffer by checking every message and find that there is > nothing for them. Then, if you are nice, you can raise an error before > returning. > > If tags are implemented as signed integers MPI_TAG_NULL would most likely > be implemented as a negative value (which by the standard is not in the > valid tag range). If tags are implemented using unsigned int values, the > implementation could set MPI_TAG_NULL to "huge(unsigned 0)" and MPI_TAB_UB > to MPI_TAG_NULL-1. Either way it should not break existing implementations > (famous last words, I know...). > > > > On Fri, Oct 22, 2021 at 3:02 PM Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > >> Do I understand correctly, that this proposal must add an additional >> lateny (internal if statement) to MPI_PROBE for *all* messages >> and also in most implementations (that do not want to ignore the >> error-checking >> when MPI_TAG_NULL is passed) for *all* point-to-point messages, >> but >> it this new MPI_TAG_NULL feature may be rearely used and extremly rarely >> used >> in MPI_PROBE? >> >> ----- 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: "Nils Smeds" <nils.smeds(a)gmail.com> >> > Sent: Friday, October 22, 2021 2:33:36 PM >> > Subject: Re: [Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and >> MPI_TAG_NULL, MPI_ADDRESS_NULL) >> >> > 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 >> > >> > >> > >> > " W hen 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): >> > >> > " W hen 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 >> > [ mailto:[email protected] | danholmes(a)chi.scot ] >> > >> > >> > >> > >> > >> > >> > On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments < [ >> > mailto:[email protected] | >> 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 >> > [ mailto:[email protected] | >> mpi-comments(a)lists.mpi-forum.org ] >> > [ https://lists.mpi-forum.org/mailman/listinfo/mpi-comments | >> > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments ] >> > >> > >> > _______________________________________________ >> > 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) . -- 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

Suggestion for MPI_COMM_NULL
by Nils Smeds 22 Oct '21

22 Oct '21

[This is a branch-off from thread "Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL,MPI_ADDRESS_NULL)" ] It turns out that MPI_COMM_NULL opens some questions that I am sure can be resolved by people on the list. It is enlightening that you see my suggested MPI_COMM_NULL as a set and not an item. I did not think about that, but it is of course the more natural approach and MPI_COMM_NULL can then be seen as problematic. I do indeed have the view that the MPI_xxxx_NULL items are to be compared to NaN in that they are items in themselves. In particular they are items that are not members of any set of similar items. Thus, MPI_COMM_NULL is a process communicator that is not a member of any set of (valid) process communicators and it is not MPI_COMM_EMPTY. I am not sure that there is a need for an explicit MPI_COMM_EMPTY, but if there was it is allowed and can be created as a sub-communicator to any communicator by MPI_Comm_create, eg for MPI_COMM_WORLD: MPI_Comm_create(MPI_COMM_WORLD,MPI_GROUP_EMPTY,&mpi_comm_empty) but its usefulness I find debatable. The set operations in MPI are, I believe, restricted to the MPI_GROUP_xxx set of items and do not directly involve communicators, but I am on thin ice here. This is for the intra-communicator people, MPMD and multi-physics scientists to have opinions on. In my view, the group members of MPI_COMM_NULL should be MPI_GROUP_NONE (not MPI_GROUP_EMPTY) if it should return any members at all. My suggestion would rather be that MPI_COMM_NULL is an illegal communicator argument in any call to MPI_Group_*() or MPI_Comm_*() that takes a communicator as an argument, eg MPI_Comm_dup(), MPI_Comm_free(), MPI_Comm_group(). So, I think that you and I are arguing for the same definition of MPI_COMM_NULL . /Nils 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. > [...] > 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>” > >

1 0

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

No I certainly do not hope so, I would suggest that only an MPI implementation with a "pedantic" mode would check for this. For any production level implementation the check for MPI_PROC_NULL (if present in the implementation) will be sufficient. If MPI_TAG_NULL is provided with a valid processor argument (against the suggested standard wording) the probe code will run through all pending messages and not find any matching tag since MPI_TAG_NULL is not inside the 0..MPI_TAG_UB range. Just as a probe for MPI_PROC_NULL today could (should?) be scanning all messages. Probes with either MPI_PROC_NULL or MPI_TAG_NONE should not need fast lanes. Let them suffer by checking every message and find that there is nothing for them. Then, if you are nice, you can raise an error before returning. If tags are implemented as signed integers MPI_TAG_NULL would most likely be implemented as a negative value (which by the standard is not in the valid tag range). If tags are implemented using unsigned int values, the implementation could set MPI_TAG_NULL to "huge(unsigned 0)" and MPI_TAB_UB to MPI_TAG_NULL-1. Either way it should not break existing implementations (famous last words, I know...). On Fri, Oct 22, 2021 at 3:02 PM Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Do I understand correctly, that this proposal must add an additional > lateny (internal if statement) to MPI_PROBE for *all* messages > and also in most implementations (that do not want to ignore the > error-checking > when MPI_TAG_NULL is passed) for *all* point-to-point messages, > but > it this new MPI_TAG_NULL feature may be rearely used and extremly rarely > used > in MPI_PROBE? > > ----- 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: "Nils Smeds" <nils.smeds(a)gmail.com> > > Sent: Friday, October 22, 2021 2:33:36 PM > > Subject: Re: [Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and > MPI_TAG_NULL, MPI_ADDRESS_NULL) > > > 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 > > > > > > > > " W hen 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): > > > > " W hen 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 > > [ mailto:[email protected] | danholmes(a)chi.scot ] > > > > > > > > > > > > > > On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments < [ > > mailto:[email protected] | > 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 > > [ mailto:[email protected] | > mpi-comments(a)lists.mpi-forum.org ] > > [ https://lists.mpi-forum.org/mailman/listinfo/mpi-comments | > > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments ] > > > > > > _______________________________________________ > > 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

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

22 Oct '21

Hi Rolf, I don’t think checking for MPI_TAG_NULL during MPI_PROBE (or during MPI_RECV, etc) is required to add latency that is not already present. — If, with today’s MPI libraries, I write an erroneous program that uses a tag value that is not in the permitted range (because, for example, I coded an integer literal of -101 in the argument list of an MPI_SEND procedure call), the MPI process that executes that send initialization procedure call can discover the error immediately/directly and call an appropriate error handler (fatal, or whatever) instead of transmitting the erroneous value to the destination process. MPI_PROBE will never see the erroneous value and is not required to check for, or handle, its presence. — If, with today’s MPI libraries, I write an erroneous program that transmits a tag value that is not in the permitted range (because, for example, I coded an integer literal of -101 in the argument list of an MPI_SEND procedure call and MPI chooses to transmit that bad value to the destination process), then the destination MPI process for that message envelope will discover the error (probably during a receive or probe procedure call) and call an appropriate error handler (fatal, or whatever). — If I replace the integer literal with a named constant set to the same value, the compiler will replace the named constant with the integer literal and no runtime code (at the source or the destination) will see any difference. If the MPI Standard codifies the named constant and the definition of it is added to the MPI header file(s) & Fortran module(s), again no difference will be seen at runtime. Existing MPI libraries must already be able to handle this problem. — A debug build of the MPI library might do more error checking of input arguments and data packets received from the network than a production build (which might assume that no such errors remain in the application code and consequently do little or no checking of this kind). Cheers, Dan. — Dr Daniel Holmes PhD Executive Director Chief Technology Officer CHI Ltd danholmes(a)chi.scot > On 22 Oct 2021, at 14:02, Rolf Rabenseifner via mpi-comments <mpi-comments(a)lists.mpi-forum.org> wrote: > > Do I understand correctly, that this proposal must add an additional > lateny (internal if statement) to MPI_PROBE for *all* messages > and also in most implementations (that do not want to ignore the error-checking > when MPI_TAG_NULL is passed) for *all* point-to-point messages, > but > it this new MPI_TAG_NULL feature may be rearely used and extremly rarely used > in MPI_PROBE? > > ----- 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: "Nils Smeds" <nils.smeds(a)gmail.com> >> Sent: Friday, October 22, 2021 2:33:36 PM >> Subject: Re: [Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL, MPI_ADDRESS_NULL) > >> 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 >> >> >> >> " W hen 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): >> >> " W hen 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 <mailto:[email protected]>> 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 >> [ mailto:[email protected] <mailto:[email protected]> | danholmes(a)chi.scot <mailto:[email protected]> ] >> >> >> >> >> >> >> On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments < [ >> mailto:[email protected] <mailto:[email protected]> | mpi-comments(a)lists.mpi-forum.org <mailto:[email protected]> ] > >> 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 >> [ mailto:[email protected] <mailto:[email protected]> | mpi-comments(a)lists.mpi-forum.org <mailto:[email protected]> ] >> [ https://lists.mpi-forum.org/mailman/listinfo/mpi-comments <https://lists.mpi-forum.org/mailman/listinfo/mpi-comments> | >> https://lists.mpi-forum.org/mailman/listinfo/mpi-comments <https://lists.mpi-forum.org/mailman/listinfo/mpi-comments> ] >> >> >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpi-comments <https://lists.mpi-forum.org/mailman/listinfo/mpi-comments> > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de <mailto:[email protected]> . > 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 <http://www.hlrs.de/people/rabenseifner> . > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments <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 Rolf Rabenseifner 22 Oct '21

22 Oct '21

Do I understand correctly, that this proposal must add an additional lateny (internal if statement) to MPI_PROBE for *all* messages and also in most implementations (that do not want to ignore the error-checking when MPI_TAG_NULL is passed) for *all* point-to-point messages, but it this new MPI_TAG_NULL feature may be rearely used and extremly rarely used in MPI_PROBE? ----- 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: "Nils Smeds" <nils.smeds(a)gmail.com> > Sent: Friday, October 22, 2021 2:33:36 PM > Subject: Re: [Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL, MPI_ADDRESS_NULL) > 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 > > > > " W hen 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): > > " W hen 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 > [ mailto:[email protected] | danholmes(a)chi.scot ] > > > > > > > On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments < [ > mailto:[email protected] | 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 > [ mailto:[email protected] | mpi-comments(a)lists.mpi-forum.org ] > [ https://lists.mpi-forum.org/mailman/listinfo/mpi-comments | > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments ] > > > _______________________________________________ > 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