Meeting Minutes 6 April 2023

Here is a summary of the meeting and related Slack discussion.

During the meeting, I presented my proposal for integer and handle constants. However, in response to feedback, I made significant changes to it, which I will describe below.

There was some debate about using the Huffman code directly versus a table. Joseph wants a table, and one that is smaller than 1024 entries. I have changed the Huffman code so that the maximum table size is not large, and is furthermore amenable to a two-level table that is even smaller, if someone wants to trade time for space.

We also discussed integer constants, particularly the ones that have interesting positive values, e.g. MPI_BSEND_OVERHEAD. Dan and I agree that we should have a way to query the exact value, which is less than the ABI value, which needs to be an upper bound on all implementations. Dan and I disagree on how to do this. I am going to propose attributes similar to MPI_TAG_UB. Dan or others may propose info or something else. I encourage everyone to look at https://github.com/mpiwg-abi/specification-text-draft/blob/main/IntegerConstants.md and complain about things they don't like.

After some pondering, I concluded that we should not encode the size of types into handles if the types are not strictly fixed-size by the language. Consider MPI_LONG, for example. Once we fix the platform ABI, e.g. LP64, we know sizeof(long) and thus can encode it in MPI_LONG. However, this would cause two problems. First, the value of MPI_LONG would not be a strict constant and second, third-party languages would need to know the behavior of C to compute the value of MPI_LONG. Lisandro made the point that we create problems for heterogeneous MPI (i.e. ILP32 on one end and LP64 on another) and related activities, and I do not want to break that. Thus, implementations will need to figure out the size of MPI_LONG and related. Fortunately, message rate benchmarks almost always use MPI_CHAR, which is a fixed-size type.

The latest version of the Huffman code is in https://github.com/mpiwg-abi/specification-text-draft/pull/6/files, and it has the following features:

• I made minor changes to the MPI_Op path, because I want to be consistent that MPI_*_NULL is always the zero bit pattern other than the handle type part.
• Fixed-size datatypes are slightly changed, and exist in the range [576,747].
• Other datatypes changed a lot, because many C/C++ types are not actually fixed-size. These types are also more table-friendly, as they only span the range [512,572].

There are a few different implementations that make sense here:

1. All handles in a single table of 1024 entries (where values is whatever the implementation uses internally: MPICH -> int; OMPI -> pointer), which is ~90% sparse. The worst case storage requirement is 8KiB, which is not onerous.
2. Datatypes fit into a table of 236 entries, which can be compressed by using an 8-bit hash (internal = table[indirection[ handle & 0b11111111]]) into a table of ~71 entries.
3. Datatypes use a mostly dense table of 60 entries for non-fixed-size types and something else for the fixed-size types.
4. The Huffman code is used directly, which requires a handful of register bit mask/shift ops to lookup internal handle values.

There is an open question about whether we should make the buffer address constants equivalent to zero when they have the same effect as C NULL, or whether we should give them distinct values for debugging purposes.

I am inclined to make all of the following zero except MPI_IN_PLACE, MPI_UNWEIGHTED and MPI_WEIGHTS_EMPTY, but I am happy to hear feedback to the contrary.

MPI_STATUS_IGNORE = 0
MPI_STATUSES_IGNORE = 0
MPI_ERRCODES_IGNORE = 0
MPI_ARGV_NULL = 0
MPI_ARGVS_NULL = 0
MPI_IN_PLACE != MPI_BOTTOM = 0
MPI_WEIGHTS_EMPTY != MPI_UNWEIGHTED != 0