Subject: Task Indentifers

From: [email-masked] (David Walker)
Date: Wed, 27 Jan 1993 08:37:15 -0500

I assume that "task" in Peter's proposal are the same as "processes"
elsewhere in the MPI discussion.

I think there is some confusion over the terms "PID" and "rank".
If PIDS do not convey any information to the application then as Peter says:

       "users writing portable applications should not make any decisions
	about nor perform any operations based on [task identifiers]."

In fact there's almost no point in having task identifiers accessible
to an application. Instead applications typically use what was referred to at 
the Dallas meeting as the "rank", which is a one-to-one mapping of PIDs to the
integers 0,1,2,...n-1. The user needs ranks so s/he can say things like,

	if ( myID() .EQ. 0 ) output(data)

PID (or task ID if you like) and rank are synonymous in MPI1 since we could see
no reason for distinguishing them. Note that "rank" is essentially an arbitrary
enumeration of processes, and contains no information about relative
placement of processes on physical processors. A ranking is the same as a
1-D topology. MPI does not currently address how a topology is mapped to
physical processors, in fact the whole topic of process creation has so far
been avoided.

I guess my main question with Peter's proposal is :

"If an application shouldn't make any decisions about nor perform any 
 operations based on task IDs, then why does an application even need to
 know about task IDs?"

---

From: [email-masked] (James Cownie)
Date: Wed, 27 Jan 93 13:59:32 GMT

I tend to agree with David here.

It is clear that the underlying system level identification of a
process can potentially be arbitrarily complex, and will almost
certainly require at least a (node,process within node) tuple. 

However, this is not the way the user wants to think about her
program. She wants to think about a set of processors with an obvious
mapping onto the positive integers. (Fortran programmers would
probably prefer that to read "strictly positive integers" ...).

At the user level we shouldn't be exposing the internals of the
system's process mapping scheme, since it will likely be different on
each machine. (On a net doubtless there will be whole ip addresses
kicking around, and so on).

I would suggest that we let the user think about a simple enumeration
of processors, but stipulate that this is a random enumeration (in
other words there is no guarantee whatever that an N to N+1
communication is faster than an N to N+x communication). The system
can then use a simple table lookup to translate from the user's
process number into the system address. Most of the time this will be
necessary anyway (on all systems which need more than this simple
numbering scheme), and in any case it's only a single (unsigned)
compare followed by one store access.

If the user needs to have guarantees of "nearness", then she should
use the virtual topologies mechanism to obtain a good process
enumeration. 

If we were feeling mean, then we'd add an implementation
recommendation that the intial mapping should be random, so that
people get an incentive to use the virtual topology mechanisms even to
implement a straight line of processes.

-- Jim
James Cownie 
Meiko Limited			Meiko Inc.
650 Aztec West			Reservoir Place
Bristol BS12 4SD		1601 Trapelo Road
England				Waltham
				MA 02154

Phone : +44 454 616171		+1 617 890 7676
FAX   : +44 454 618188		+1 617 890 5042
E-Mail: [email-masked]   or    [email-masked]