The meeting is tomorrow, Tuesday, April 4, 17-18 Helsinki time, 8-9 AM New York time.
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 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
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
--