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

[George Bosilca]

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

>
>
> On Mon, Feb 20, 2023 at 6:53 PM Zhou, Hui <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> on behalf of
>> Joseph Schuchart <schuchart at icl.utk.edu>
>> *Sent:* Monday, February 20, 2023 8:53 AM
>> *To:* mpiwg-abi at lists.mpi-forum.org <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
>> > http://jeffhammond.github.io/
>> >
>>
>> --
>> mpiwg-abi mailing list
>> 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
>> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi
>>
>
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
> --
> mpiwg-abi mailing list
> 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/969c41db/attachment.html>