Subject: Context proposals overview

From: "Marc Snir" <[email-masked]>
Date: Tue, 23 Mar 93 13:10:01 EST

Reference:  Attached note from [email-masked]

Reply

*************** Forwarded Note ***************

Date: Tue, 23 Mar 93 15:39:41 GMT
From: [email-masked] (James Cownie)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Context proposals overview
Content-Length: 5160

Jim's initial summary/comments on the Contexts proposals

Gentlemen, here is my summary and initial comclusions on the three
extant Contexts proposals received via Lyndon. Since I have probably
misunderstood or misrepresented some of the proposals, please correct
me as appropriate.

Proposal I (Marc Snir)
----------------------
Key points :
A group and a context are identical.
All communication (including point to point) is addressed by group and
rank.
The receiver MUST be a member of the same group as the sender, and
explicitly give the group as an argument to the receive function.

Group descriptors are not passable to other processors.

Creation of a new context involves creation of a new group which is a
group synchronising operation.

For:
Simplicity, it's easy to explain and understand (and probably
implement).

Insisting on a group for all addressing gives the 0..n-1 rank model
for subgroups which aids in importing libraries.

Against:
The receiver of a message has to both know the group of the sender,
and be a part of it. This feels like it makes servers hard, but may be
ok. If you keep having to go into the ALL group, then the security
which was the whole point of a context is lost.

>>> One can, of course, have several distinct contexts that include
>>> all processes.

The argument that contexts can be checked at the sender is incorrect
because a single process can be in many different groups/contexts, and
therefore the group/context must be transferred to ensure correct
matching. (Maybe this wasn't the intent of the comments anyway...)

>>> group/context need be transfered in the message.  The point I was
>>> trying to make is that one can make sure that a message with a
>>> given context tag will be sent only to a process that "knows" about
>>> this context.  This allows some relaxations: e.g., context names
>>> need not be system-wide unique, only locally unique at each process;
>>> handling of "illegal context" errors is simplified.

I don't understand how to build a group/context using only point to
point messages. I still seem to have the bootstrap problem that I need
the new context to safely receive the message which will tell me what
the new context is.

>>> Well, we have an existential proof, since we support dynamic group
>>> creation in our system.  A new context is created within an old,
>>> preexisting context; so ALL need to be there from start.

Proposal V (Rik Littlefield)
----------------------------
Key points :
A desire to have caching of arbitrary library (or even user) defined
entities on the groups.

Point to point communication is expected to be addressed by TID and
Context. TIDs have global scope, they can be passed around
arbitrarily.

There is explicit translation from (group,rank) to TID.

Group descriptors are local objects, but can be passed around through
special mechanisms.

Contexts are globally unique, (and expected to be allocated locally
through one of the normal bit space partitioned schemes. i.e.
processor number // identifier. There appears to be an expectation
that the identifiers are managed closely), and can be passed
transparently in messages (? is this true ?).

Contexts are created inside groups, creating a context is a barrier
synchronisation (? is this true ?).

For:
The caching is good idea, but orthogonal to all the other issues, it
could be added just as easily to any of the other proposals

The use of TIDs in the point to point removes any issues of group
membership from these functions. There is thus a way to achieve any
inter group communication which is required (even if it is unpleasant).

Against:
The complexity of the "paired exact match criterion" is non trivial to
explain.

Proposal VI (Lyndon Clarke)
---------------------------

Key points:
ALL descriptors (process, group, context) are process local, but may
be sent elsewhere through special mechanisms.

Contexts are created inside groups, and are bound to them. The context
can be used to refer (indirectly) to the owning group.

Creating a context is a barrier synchronisation of the group.

Three different forms of process address are discussed for point to
point messaging. (Ouch !)

For:
Can be made to address complex inter group communications

Against:
The complexity of the whole proposal.

The passing of opaque entities with translation is rather unpleasant
for people with homogeneous machines. Before this we could ignore all
of the type info, now we have to check some of it and take special
actions.

Jim's initial conclusions...
----------------------------

1) Marc's approach of insisting that all communications occur inside a
group has some simplifying effects. In particular it easily gives the
base shift for sub-groups, so that they "think" their processors are
numbered 0..n-1. It has the disadvantage that there is an extra
translation required on ALL communications. This will add to the
latency at the most fundamental level (though not much if we expect to
consume space linear in the group size).

2) Creating a new group for each context may be expensive, though Marc
suggests an implementation which makes this relatively cheap.
Adding Rik's caching ideas here could also defer the cost until it was
required. (e.g. there is no need to build a broadcast tree in a group
until the first broadcast is performed. [Fundamental optimisation 0:
"Don't do it until you need to, you might never have to do it at
all"])

At the moment I favour Marc's with added caching. Can anyone explain
where the big gain is from the added complexity of the others ?

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

---

From: L J Clarke <[email-masked]>
Date: Tue, 23 Mar 93 19:33:41 GMT

> Proposal I (Marc Snir)

Sure, I see, if there are M distinct services then you create M contexts
which are replicates of the ALL context and messages for each service
are protected from one another. 

Of course this is ignoring the nagging realisation that the client has
to remember which rank within the all group the server has, when the
expressive way of doing this is actually to describe a SERVER context
and a CLIENT context, forget about the ALL context, and let the clients
send messages to the server context and the server send messages to the
client context. 

Well, actually this is only part of the story, because we should think
about the CLIENT as being a concerted entity (a parallel client process)
and allow there to me multiple distinct clients.  Don't things look
rather bad for this proposal now. 

Well, again we left something out of the story, because the SERVER
itself could compose multiple processes acting as a concerted entity (a
parallel server process).  Now it's just getting a bit messy for the
client to remember the set of server indices? It's worse for the server
remembering the set of client indices.  You bet the programmer ends up
implementing inter-context communication by hand. 

Finally, are we in good shape when the parallel server for service X is
the parallel client for service Z, which has a parallel server? I
suggest not.  Okay, well this is beginning to get a wee bit
hypothetical, I don't know of anyone programming at this final level of
complexity quite yet. But, I do know of people programming at the
parallel servers - parallel clients level.

> >>> preexisting context; so ALL need to be there from start.

There is an implementation of this kind of group creation in your system
- existence proof that this is implementable - but if your system does
not use the point-to-point facilities of MPI then this may not be an
existence proof that this is implementable with the point-to-point
facilities of MPI. 

This doesn't bother me, personally.  I cannot bring myself to being an
advocate that the group and context constructors and destructors have to
be implementable using the point-to-point section of MPI.  This just
seems to have the effect of restricting the contructors and
desctructors.  The argument is not the same as the similar argument for
collective communications -- there should be few constructors and
destructors whereas there may be many collective communications. 

Best Wishes
Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/