Subject: MPI task identifiers

From: [email-masked]
Date: Thu, 28 Jan 1993 15:16:01 +0100

During the last two days there was an interesting discussion about
the naming of processes in MPI. I just want to throw some thoughts into
the discussion.

If we number the processes in a group from 0 to n-1, I see two benefits:
1. The applications programmer immediately knows how to address the
   other processes in the same group, instead of first having to look
   up some strange id numbers. Sure, the translation to the underlying
   (h/w) or network addresses has to be done somewhere, but it's not
   necessarily the applications programmer who wants to do this.
2. The 0,...,n-1 ranking of processes provides a natural order for
   collective communications, like gather.

Without nicely ordered id numbers, almost every reasonable MPI
program would have to use the virtual topologies. If you look at the
proposal of the PTOP subcommittee, you will find no assumption
about the definition of the process identifiers in a group. All ordering
and addressing of processes is provided by the topologies.

So, as a proponent of virtual topologies I could be happy with that
solution. At the Dallas meeting somebody already suggested that there
be always a topology associated with a process group. At group creation
this would be just a linear ordering. Since topologies can be
overwritten, this default could be changed by the user at any time.

Note that this would not mean that the pid numbers are arranged as
0,..,n-1. A process would use the topology look-up functions to get
the pids of its neighbors, whereas the pid numbers could have any value
(as Peter Ringsbee proposes).

I think we have to choose between:

 a. We force programmers to use the topology functions in virtually all
    applications. The pid numbers can then have any values. The default
    topology of a group is a linear ordering. The mapping of processes
    to processors causes some (usually small) overhead at group
    creation.

 b. The pid numbers are numbered as 0,..,n-1. This does not mean the
    processes are mapped in a kind of nearest-neighbor fashion to the
    processors. It is rather a (random) enumeration of the processes
    in a group, in order to get benefits 1. and 2. (see above).
    If one wants to have a good mapping, one should use the
    virtual topology functions (which I recommend, of course).
    On the other hand, this introduces another level of address
    indirection.

I tend towards alternative b., although there are some tricky problems.
For example: when a topology is assigned to a group, does this then
change the pid numbers? If not, then the buffer structure in collective
operations will not be aligned with the topology. On the other hand,
changing the pid number of a process looks ugly to me. Perhaps it helps
if we avoid the word "pid" alltogether, and only refer to the "rank" of
a process, as David Walker suggests.

I suggest that at the next Dallas meeting we have a session in which
the subcommittees for collective communication and process topologies
meet together. To me this seems to be the ideal forum where we can
try to solve the problem.

Rolf Hempel