[mpiwg-abi] Tuesday (20 February 2023) meeting agenda
Jeff Hammond
jeff.science at gmail.com
Tue Feb 21 11:29:24 CST 2023
Thanks to everyone who joined our nearly 2 hour meeting today. There were
12-15 people in attendance (I can produce the details if compelled).
We made the following decisions, which are of course not final in any
sense, but will be reflected in the latest proposal once I have time to
update it, and is the basis of the implementation work that Hui and I are
doing.
0. MPI handles should be incomplete struct pointers. This guarantees type
safety. Compilers will notice if users pass MPI_Comm instead of MPI_Group,
for example. Some users and the Open-MPI developers have made this a high
priority. A corollary to this is that the name of the struct becomes part
of the ABI.
For example, we will specify:
typedef struct MPI_ABI_Comm * MPI_Comm;
and *all* of this will become part of the ABI. Rust, for example, needs to
know the struct name.
1. MPI predefined handle constants should be constant integer expressions,
not addresses to a named location in the implementation. While the debate
was heated, the poll was unanimous in favor of this choice.
For example, this means that we have:
#define MPI_INT (MPI_Datatype)0x3;
This is legal in C and C++, and relies on implementation defined behavior
that is already assumed in MPI (e.g. MPI_IN_PLACE) and known to work
everywhere.
The reasons for this decision are:
a. Using link-time constant addresses as constant initializers is not
completely portable. For example, it does not work on Windows, and
Open-MPI does not support Windows because of this.
b. We can do efficient encoding of predefined handles if they are integer
values. More on this below...
c. Compile-time constants will make it easier to standardize a Fortran ABI
that uses the exact same handle values as C so there is zero overhead from
Fortran (F08/F18). Fortran does not allow link-time resolution of
initializer expressions, which implies overhead for implementations that do
not have compile-time constants for the C handle constants (e.g. Open-MPI).
d. It makes it easier to define/use predefined handle constants from
binary, which was raised as a use case from a tool perspective (e.g. Dynist
and Papi).
The arguments against this decision were:
e. We will need to state and reserve the integer values used for this. In
practice, this is portable because of the zero page, but is otherwise
implementable because implementations can just verify that allocated
handles do not conflict with the predefined ones.
2. MPI_<HANDLE>_NULL should not be 0 (i.e. NULL).
The arguments in favor of this were:
f. It makes it clear when uninitialized handles are used, as this will
always be erroneous.
g. MPI_COMM_NULL has a name and is thus not the same thing as NULL would
imply.
The arguments in against this decision were:
h. Zero initialization is common and some consider it convenient to have
this cause handles to be automatically initialized to MPI_<HANDLE>_NULL.
3. We will attempt to Huffman encode predefined handles into a unique set
of values, rather than have each set of handles be a sequence of integers.
Arguments in favor:
i. Unique numbers for every handle help debugging.
j. We can encode useful information in handles, especially for datatypes,
which allows optimizations similar to what MPICH does today.
Arguments against:
k. A sequence of integers means that a translation layer can use an array
to translate from application handles to implementation handles
4. Non-decision: we discussed but made no decision about symbol
visibility. We will address this later.
In the next meeting, to be scheduled later, I will propose values for a
bunch of constants and we can argue about them. In cases where MPICH and
Open-MPI today agree, I will propose that we use those values. Most of
this activity will happen on GitHub and the meeting will be to argue about
any controversies.
A copy of these minutes will be uploaded to GitHub shortly.
Jeff
> >
> > 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/
>
>
--
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230221/9dbe9ad2/attachment.html>
More information about the mpiwg-abi
mailing list