<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof ContentPasted0">
> OMPI has been doing this for years and no users complained, because it is good practice.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof ContentPasted0">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof ContentPasted0">
Well, Lisandro just wished <span id="🙂">🙂</span>. 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. <span id="🙂">🙂</span>
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof ContentPasted0">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof ContentPasted0">
-- <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof ContentPasted0">
Hui<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> George Bosilca <bosilca@icl.utk.edu><br>
<b>Sent:</b> Monday, February 20, 2023 12:13 PM<br>
<b>To:</b> Jeff Hammond <jeff.science@gmail.com><br>
<b>Cc:</b> Zhou, Hui <zhouh@anl.gov>; mpiwg-abi@lists.mpi-forum.org <mpiwg-abi@lists.mpi-forum.org><br>
<b>Subject:</b> Re: [mpiwg-abi] Tuesday (20 February 2023) meeting agenda</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Mon, Feb 20, 2023 at 12:08 PM Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Mon, Feb 20, 2023 at 6:53 PM Zhou, Hui <<a href="mailto:zhouh@anl.gov" target="_blank">zhouh@anl.gov</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt"> >> While it works and means I can avoid predefined handle translations
<br>
in the forward direction, I still have it in the backwards direction, <br>
and it's not exactly simple to resolve all the symbols.<br>
> <br>
> Can you elaborate a bit on the backward translation? I'm not sure I <br>
understand what you mean by that.</span></font></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
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.</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>MPI_GROUP_EMPTY is the valid output for all group manipulation functions (they do not return MPI_GROUP_NULL).</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
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."<span style="font-family:CMR10; font-size:11pt"> </span><br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt">>> The second question is whether to #define MPI_HANDLE_NULL
<br>
(MPI_Handle*)0. Lisandro argues for this, and it would make a lot of <br>
things easy.</span></font></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt"><br>
</span></font></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt">> <font size="2"><span style="font-size:11pt">I believe OMPI uses special null objects for nearly all its null handles
<br>
to avoid checking for NULL on every call.</span></font><br>
</span></font></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt"><br>
</span></font></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt">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.</span></font></div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div> George.</div>
<div><br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
</div>
<div>Indeed. It would be nice to have zero initialization be equivalent to null handle initialization.</div>
<div><br>
</div>
<div>Jeff </div>
<div><br>
</div>
<div> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt"></span></font></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt">-- <br>
</span></font></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
<font size="2"><span style="font-size:11pt">Hui<br>
</span></font></div>
<div id="x_m_6997744840926869277m_8042892687275752636appendonsend"></div>
<hr style="display:inline-block; width:98%">
<div id="x_m_6997744840926869277m_8042892687275752636divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> mpiwg-abi <<a href="mailto:mpiwg-abi-bounces@lists.mpi-forum.org" target="_blank">mpiwg-abi-bounces@lists.mpi-forum.org</a>>
on behalf of Joseph Schuchart <<a href="mailto:schuchart@icl.utk.edu" target="_blank">schuchart@icl.utk.edu</a>><br>
<b>Sent:</b> Monday, February 20, 2023 8:53 AM<br>
<b>To:</b> <a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a> <<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a>><br>
<b>Subject:</b> Re: [mpiwg-abi] Tuesday (20 February 2023) meeting agenda</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>Jeff,<br>
<br>
You said:<br>
<br>
> While it works and means I can avoid predefined handle translations <br>
in the forward direction, I still have it in the backwards direction, <br>
and it's not exactly simple to resolve all the symbols.<br>
<br>
Can you elaborate a bit on the backward translation? I'm not sure I <br>
understand what you mean by that.<br>
<br>
> The second question is whether to #define MPI_HANDLE_NULL <br>
(MPI_Handle*)0. Lisandro argues for this, and it would make a lot of <br>
things easy.<br>
<br>
I believe OMPI uses special null objects for nearly all its null handles <br>
to avoid checking for NULL on every call. A null request handle for <br>
example is a valid input into `MPI_WAIT` and we can get the empty status <br>
from the null request just like we do from any other request. NULL <br>
function pointers (MPI_TYPE_NULL_DELETE_FN) can point to an empty <br>
function that we can simply invoke. NULL pointers require special <br>
treatment, which is tedious and error prone and has UB lurking around <br>
the corner. With null objects, we will never receive (or hand out) an <br>
invalid pointer, which is safe engineering.<br>
<br>
I'm curious what the benefits are from an application's (or middleware) <br>
standpoint?<br>
<br>
Cheers<br>
Joseph<br>
<br>
On 2/20/23 03:55, Jeff Hammond wrote:<br>
> For the meeting tomorrow, I would like you all to consider the following:<br>
><br>
> There is consensus regarding the following to get type safety:<br>
> typedef struct MPI_ABI_Handle * MPI_Handle;<br>
><br>
> We have two choices for predefined handles:<br>
><br>
> Option 1:<br>
> #define MPI_INT (MPI_Datatype)0x3<br>
><br>
> Option 2:<br>
> #define MPI_INT (MPI_Datatype)&MPI_ABI_INT<br>
><br>
> Option 1 relies on implementation defined behavior regarding the <br>
> casting of integers to pointers, but it is safe. Gonzalo and I had a <br>
> long discussion of this, and the only issue is that (intptr_t)MPI_INT <br>
> == 0x3 is not guaranteed to be true, but (intptr_t)MPI_INT == <br>
> (intptr_t)(void*)0x3 is. Both MPICH and Open-MPI already rely on this <br>
> technique for MPI_IN_PLACE, among others.<br>
><br>
> The advantage of Option 1 - assuming we use a sensible set of <br>
> integer values - is that ABI compatibility layers can do translation <br>
> via a table. This is most useful for datatypes, where there are ~100 <br>
> predefined handles, and to a lesser extent ops. For all other <br>
> handles, there are no more than 3 predefined handles (IIRC).<br>
><br>
> Option 2 allows run-time resolution of predefined handles, which I <br>
> thought was good until I implemented it in <br>
> <a href="https://github.com/jeffhammond/mukautuva" target="_blank">https://github.com/jeffhammond/mukautuva</a>. While it works and means I
<br>
> can avoid predefined handle translations in the forward direction, I <br>
> still have it in the backwards direction, and it's not exactly simple <br>
> to resolve all the symbols. I think Hui also implemented this in his <br>
> compatibility layer, although I don't know if he hates it as much as I do.<br>
><br>
> The second question is whether to #define MPI_HANDLE_NULL <br>
> (MPI_Handle*)0. Lisandro argues for this, and it would make a lot of <br>
> things easy.<br>
><br>
> I hope that we can decide these two questions today. For the second <br>
> meeting, we will address predefined integer constants.<br>
><br>
> Jeff<br>
><br>
> -- <br>
> Jeff Hammond<br>
> <a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br>
> <a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a><br>
><br>
<br>
-- <br>
mpiwg-abi mailing list<br>
<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi</a><br>
</div>
</span></font></div>
</div>
-- <br>
mpiwg-abi mailing list<br>
<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi</a><br>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">Jeff Hammond<br>
<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br>
<a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div>
-- <br>
mpiwg-abi mailing list<br>
<a href="mailto:mpiwg-abi@lists.mpi-forum.org" target="_blank">mpiwg-abi@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi</a><br>
</blockquote>
</div>
</div>
</div>
</body>
</html>