Subject: My two cents worth on process numbering.

From: [email-masked] (Al Geist)
Date: Thu, 28 Jan 93 09:11:39 -0500

>To summarize, I think that process ids in the range 0..n are the right
>approach for ensuring portability of applications.

With the ability to have multiple groups each with processes numbered 0...p
then no process can be uniquely identified by a single integer [0,1,...n].
The above  process naming scheme will require some group context information
down in the point to point routines.
It can be explicit as in a (group_id, rank) pair
which I prefer because it makes codes more readable and easier to debug,
or it can be implicit as in the original MPI draft.

Peter Rigsbee is correct in noting that on large MPP systems looking up
this mapping of 0-p to real process location and id can be expensive
in both time and memory. If the high priests want to be efficient and go fast
then Peter's suggestion of having a more sophisticated task naming
should be considered seriously.

Al Geist

---

From: [email-masked] (James Cownie)
Date: Thu, 28 Jan 93 14:56:47 GMT

(Come on Al give us the whole $1 worth !)

Al asserts that
> Peter Rigsbee is correct in noting that on large MPP systems looking
> up this mapping of 0-p to real process location and id can be
> expensive in both time and memory.

I disagree that this is necessarily expensive, for the following reasons :-

1) At some level the system has to know the lowest level
   address, otherwise it cannot send the data. (I know this could be a
   route, rather than an absolute address, but it comes to the same thing)
   So it's a cost you have to pay somewhere.	

2) In the worst case the cost is constant in time and linear in number
   of nodes in memory. (Just index into an array of low level
   addresses). How bad is this really ? Suppose you have a 16K node
   machine with 128 bit low level addresses (4 32bit words) this
   occupies 256K bytes, which doesn't seem so bad. 

3) You can trade off the store requirement against a larger time cost.
   Rather than holding all of the destination addresses you implement
   an address cache (using standard symbol table technology), and fill
   in the addresses as you use them. (Of course you need a distributed
   scalable lookup to find them the first time). This then requires
   store which depends on the working set of targets for
   communication, and whatever CPU time is taken in the lookup.
   (Should be logarithmic in number of processors if you use a tree).
	
The issue I'd like to clarify here is what is actually being asked for
by Peter ?

Is he asking that the user deal with genuine low level addresses
(which are potentially of arbitrary size, and certainly different on
different vendors machines) ?

or

Is he asking that users deal with integer identifiers, but these are
opaque in the sense that modifying then makes no sense ?

The former seems extremely unattractive (especially in Fortran !), and
if it's the latter, then you still have to do a translation somewhere
to get to the real low level address, so why not let the user have
what they really wanted (i.e. 0..N) ?

-- 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]