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

[Jeff Hammond]

>>>> 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.
> 

Can you give an example of how it’s error prone? What errors is OMPI catching because it’s not null?

Jeff


>   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/0ddbd370/attachment.html>