[Mpi-comments] Semantic meaning of 'rank' throughout the MPI standard
Mor, Omri
omrimor2 at illinois.edu
Tue May 28 00:43:20 CDT 2019
Hello MPI-Forum:
Before submitting an issue to the MPI Forum’s GitHub repository, I’d like to garner some initial feedback.
This proposal reaches across a number of WGs, though is likely most relevant to the Semantic Terms WG.
Currently, MPI specifies a ‘rank’ argument (such as sources, destinations, roots, and targets) as either an ‘integer’ or a ‘non-negative integer’. This varies by chapter: Point-to-Point Communication, Collective Communication, and ‘Groups, Contexts, Communicators, and Caching’ exclusively uses ‘integer’, while One-Sided Communications uses ‘non-negative integer’ exclusively. The Process Topologies chapter confusingly uses both.
Compounding this confusion is how different calls interacts with the null process MPI_PROC_NULL, defined in §3.11. It is unclear, for instance, whether the null process is only permitted in point-to-point communication calls as its definition inside that chapter might imply, or whether it is intended to be more general. That the null process is implemented as a negative integer in all major MPI implementations I am aware of means only worsens the situation.
My proposal is then thus: to first define as a semantic term ‘rank’ with the meaning ‘any integer from 0 to N in a group of size N or communicator whose group is size N, along with the integer constant MPI_PROC_NULL’.
Most calls with a rank argument can then simply define it as a rank integer. Receive calls additionally need to specify that it can be MPI_ANY_SOURCE.
Communication calls with a null process succeed and return as soon as possible, not modifying any arguments to the call. Whether a collective call with a null root process is required to be called by all processes in the group of the communicator before the call returns is unspecified, but collective calls must still be issued in the same order to be correct.
Besides implementations possibly needing to implement communication with null processes for a wider range of operations, are there any issues with this proposal? Doing so should be pretty trivial, though it does require an additional branch.
As an alternative, it is possible to restrict the use of null processes to point-to-point communication while still merging the definitions of process ranks.
For additional comments on the particular use case of null processes in graph topologies, see #87 in the mpi-issues repository. This proposal is both broader as well as not necessarily requiring the support for null processes outside of point-to-point communication; the general purpose is to clarify what values are allowed for rank arguments throughout the MPI standard.
Thank you,
Omri Mor
More information about the mpi-comments
mailing list