I apologize for my incompetence with meeting scheduling and attendance this week. Hopefully this time I am able to get the timing correct
and also attend.
The topics / decisions of interest are:
A. Integer constants
We have constants that must be powers of two (mode constants), constants that must have a < relationship (error codes and thread levels),
constants that should be negative to avoid conflicting with e.g. ranks, and constants that can be anything.
I have a proposal for constants here: https://github.com/mpiwg-abi/specification-text-draft/blob/main/IntegerConstants.md.
I have not yet implemented Dan's suggestion to make constants unique (presumably, for the aforementioned categories that allow it).
I would like feedback on the following:
1. Are the values of MPI_MAX_*** acceptable? In all cases, I chose the greater of MPICH and OMPI. For MPI_BSEND_OVERHEAD, I used 512
to be safe. Is that too large? Is 128 better?
2. Are there any opponents to Dan's suggestion that all the constants are unique, within reason? If the consensus favors this, I'll redo
all the constants accordingly.
3. Are there any other integer constant values that bother people? I have very little attachment to any of them, and it is trivial to
change them now.
B. Handle constants
I implemented a Huffman code for these (https://github.com/mpiwg-abi/specification-text-draft/blob/main/HandleConstants.md).
I made a Python code that implements it, and the program dumps all the values, and can be modified easily
to generate mpi_abi.h.
Does anyone oppose the idea of a Huffman code? I know Hui is indifferent, which is obviously fine. One can ignore the Huffman code and
just view the results as some random values I chose :-)
If you like Huffman codes, but dislike mine, then please complain soon. There are some parts that I do not love. For example, fixed size
types are handled consistently and encode their size (as the log_2 of bytes) in bits 3:5, while language default types are on a different branch and encode their size in bits 8:10. I can makes those consistent, but it means the code branches aren't sequential
in the bit indices. I think that's fine, but I am new to Huffman codes.
An alternative to the above is to say that in mpi_abi.h, that MPI_INT, MPI_LONG and MPI_LONG_LONG are aliased to MPI_INTn_T according to
the ABI definition, and do not exist on their own. This has some appeal, but will change the results of MPI_Type_get_name. What do people think about this?
The good news is there is lots of free space in the Huffman code for new handle types and new constants. I am not worried about running
out of space. Already, I have reserved space for a bunch of types that are likely to exist in C and C++ in the near future, so those will be trivial to add later.
Finally, as noted on Slack, we have to figure out whether we reserve space for or standardize some types that OMPI defines today in the
MPI_ namespace. This is the lowest priority for me right now, so if we don't address it this week, that is fine.
Thanks,
Jeff
________________________________________________________________________________
Microsoft Teams meeting
Join on your computer, mobile app or room device
Meeting ID:
252 426 152 185
Passcode:
s23ETu
Join with a video conferencing device
teams@vc.nvidia.com
Video Conference ID:
114 591 421 4
Or call in (audio only)
+1 949-570-1120,,525452510#
United States, Irvine
Phone Conference ID:
525 452 510#
________________________________________________________________________________