[Mpi-comments] Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL, MPI_ADDRESS_NULL)

Fri Oct 22 08:41:00 CDT 2021

Dan and Nils, I agree to you both - therefore no objection from my side.

----- Original Message -----
> From: "Nils Smeds" <nils.smeds at gmail.com>
> To: "Comments on the MPI Standard" <mpi-comments at lists.mpi-forum.org>
> Cc: "Rolf Rabenseifner" <rabenseifner at 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 at 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 at lists.mpi-forum.org>
>> > To: "Comments on the MPI Standard" <mpi-comments at lists.mpi-forum.org>
>> > Cc: "Nils Smeds" <nils.smeds at 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 at 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:danholmes at chi.scot | danholmes at chi.scot ]
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments < [
>> > mailto:mpi-comments at lists.mpi-forum.org |
>> mpi-comments at 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:mpi-comments at lists.mpi-forum.org |
>> mpi-comments at 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 at lists.mpi-forum.org
>> > https://lists.mpi-forum.org/mailman/listinfo/mpi-comments
>>
>> --
>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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 at 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) .