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 > [email protected] > http://jeffhammond.github.io/ >

-- mpiwg-abi mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi -- mpiwg-abi mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

-- Jeff Hammond [email protected] http://jeffhammond.github.io/

-- Jeff Hammond [email protected] http://jeffhammond.github.io/