[mpiwg-abi] Tuesday (20 February 2023) meeting agenda

Mon Feb 20 12:37:16 CST 2023

> OMPI has been doing this for years and no users complained, because it is good practice.

Well, Lisandro just wished 🙂. MPICH also doesn't use NULL for NULL handles, so I am not standing one-side or another. But I question this kind of reasoning. I am pretty sure that if MPI standardized to use NULL for NULL handles, no one would've complained either and maybe less wishes from users. 🙂

--
Hui
________________________________
From: George Bosilca <bosilca at icl.utk.edu>
Sent: Monday, February 20, 2023 12:13 PM
To: Jeff Hammond <jeff.science at gmail.com>
Cc: Zhou, Hui <zhouh at anl.gov>; mpiwg-abi at lists.mpi-forum.org <mpiwg-abi at lists.mpi-forum.org>
Subject: Re: [mpiwg-abi] Tuesday (20 February 2023) meeting agenda

On Mon, Feb 20, 2023 at 12:08 PM Jeff Hammond <jeff.science at gmail.com<mailto:jeff.science at gmail.com>> wrote:

On Mon, Feb 20, 2023 at 6:53 PM Zhou, Hui <zhouh at anl.gov<mailto:zhouh at anl.gov>> wrote:
 >> While it works and means I can avoid predefined handle translations
in the forward direction, I still have it in the backwards direction,
and it's not exactly simple to resolve all the symbols.
>
> Can you elaborate a bit on the backward translation? I'm not sure I
understand what you mean by that.

I think Jeff meant for output parameters such as in MPI_Comm_create. I believe all handle constants are input only except for NULL handles.

MPI_GROUP_EMPTY is the valid output for all group manipulation functions (they do not return MPI_GROUP_NULL).

Yeah, NULL handle outputs, but also MPI_Type_get_contents, because "If these were predefined datatypes, then the returned datatype is equal to that (constant) predefined datatype and cannot be freed."

>> The second question is whether to #define MPI_HANDLE_NULL
(MPI_Handle*)0.  Lisandro argues for this, and it would make a lot of
things easy.

> I believe OMPI uses special null objects for nearly all its null handles
to avoid checking for NULL on every call.

From the user's point of view, using 0 as NULL is convenient. Uninitialized static variables are zero-filled. It is also convenient to zero-fill an array.

Convenient but error prone. If users want a NULL object they need to set it clearly, not rely on assumptions about zero-filled memory regions. OMPI has been doing this for years and no users complained, because it is good practice.

  George.

Indeed.  It would be nice to have zero initialization be equivalent to null handle initialization.

Jeff

--
Hui
________________________________
From: mpiwg-abi <mpiwg-abi-bounces at lists.mpi-forum.org<mailto:mpiwg-abi-bounces at lists.mpi-forum.org>> on behalf of Joseph Schuchart <schuchart at icl.utk.edu<mailto:schuchart at icl.utk.edu>>
Sent: Monday, February 20, 2023 8:53 AM
To: mpiwg-abi at lists.mpi-forum.org<mailto:mpiwg-abi at lists.mpi-forum.org> <mpiwg-abi at lists.mpi-forum.org<mailto:mpiwg-abi at lists.mpi-forum.org>>
Subject: Re: [mpiwg-abi] Tuesday (20 February 2023) meeting agenda

Jeff,

You said:

 > While it works and means I can avoid predefined handle translations
in the forward direction, I still have it in the backwards direction,
and it's not exactly simple to resolve all the symbols.

Can you elaborate a bit on the backward translation? I'm not sure I
understand what you mean by that.

 > The second question is whether to #define MPI_HANDLE_NULL
(MPI_Handle*)0.  Lisandro argues for this, and it would make a lot of
things easy.

I believe OMPI uses special null objects for nearly all its null handles
to avoid checking for NULL on every call. A null request handle for
example is a valid input into `MPI_WAIT` and we can get the empty status
from the null request just like we do from any other request. NULL
function pointers (MPI_TYPE_NULL_DELETE_FN) can point to an empty
function that we can simply invoke. NULL pointers require special
treatment, which is tedious and error prone and has UB lurking around
the corner. With null objects, we will never receive (or hand out) an
invalid pointer, which is safe engineering.

I'm curious what the benefits are from an application's (or middleware)
standpoint?

Cheers
Joseph

On 2/20/23 03:55, Jeff Hammond wrote:
> For the meeting tomorrow, I would like you all to consider the following:
>
> There is consensus regarding the following to get type safety:
> typedef struct MPI_ABI_Handle * MPI_Handle;
>
> We have two choices for predefined handles:
>
> Option 1:
> #define MPI_INT (MPI_Datatype)0x3
>
> Option 2:
> #define MPI_INT (MPI_Datatype)&MPI_ABI_INT
>
> Option 1 relies on implementation defined behavior regarding the
> casting of integers to pointers, but it is safe.  Gonzalo and I had a
> long discussion of this, and the only issue is that (intptr_t)MPI_INT
> == 0x3 is not guaranteed to be true, but (intptr_t)MPI_INT ==
> (intptr_t)(void*)0x3 is.  Both MPICH and Open-MPI already rely on this
> technique for MPI_IN_PLACE, among others.
>
> The advantage of Option 1 - assuming we use a sensible set of
> integer values - is that ABI compatibility layers can do translation
> via a table.  This is most useful for datatypes, where there are ~100
> predefined handles, and to a lesser extent ops.  For all other
> handles, there are no more than 3 predefined handles (IIRC).
>
> Option 2 allows run-time resolution of predefined handles, which I
> thought was good until I implemented it in
> https://github.com/jeffhammond/mukautuva. While it works and means I
> can avoid predefined handle translations in the forward direction, I
> still have it in the backwards direction, and it's not exactly simple
> to resolve all the symbols.  I think Hui also implemented this in his
> compatibility layer, although I don't know if he hates it as much as I do.
>
> The second question is whether to #define MPI_HANDLE_NULL
> (MPI_Handle*)0.  Lisandro argues for this, and it would make a lot of
> things easy.
>
> I hope that we can decide these two questions today.  For the second
> meeting, we will address predefined integer constants.
>
> Jeff
>
> --
> Jeff Hammond
> jeff.science at gmail.com<mailto:jeff.science at gmail.com>
> http://jeffhammond.github.io/
>

--
mpiwg-abi mailing list
mpiwg-abi at lists.mpi-forum.org<mailto:mpiwg-abi at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi
--
mpiwg-abi mailing list
mpiwg-abi at lists.mpi-forum.org<mailto:mpiwg-abi at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/
--
mpiwg-abi mailing list
mpiwg-abi at lists.mpi-forum.org<mailto:mpiwg-abi at lists.mpi-forum.org>
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230220/16641033/attachment-0001.html>