Subject: Re: mpi-context: Why scarce contexts?

From: L J Clarke <[email-masked]>
Date: Fri, 9 Apr 93 18:31:38 BST

Dear Mark

First, apologies for getting the proposal number wrong.

> 
> Lyndon asks why I think context values will be a scarce resource.
>

[stuff deleted]

> I think there are several reasons. The first is that a context
> requires underlying resources in the implementation (e.g. queues)
> which may be limited. A message arrives at a process, it goes
> into a queue matching the assigned context value in the
> envelope. Both support for the queue and the matching function
> take some effort. (16 queues is not too bad; 1000 is a lot.)
> One way to limit the effort required is to
> limit the number of supported contexts.

What you seem to be asking in this argument is that each process should
use a limited number of contexts, which is different to asking that the
system as a whole should use a limited number of contexts. Okay, that is
just perhaps a subtle point.

You are assuming details of an implementation of context.  For example,
in a different approach there could be just one queue which is searched
through (in some fashion) in receive for a matching message, testing for
context in no different way to testing for tag and sender.  In that
implementation contexts do not require resource, and the number of
contexts is bounded only by the bit length of the context identifier. 

I imagine that you must have good reasons for the assumed implementation
of context.  Please do let me/us know why you make the assumption, I am
sure that I am not alone in my concern that the number of contexts
should be so scarce, but perhaps you know of very good reasons why they
should so be. 

> Second, the bits in the envelope that support the context value
> have to come from somewhere, probably the existing tag field. If
> the tag field is only 16 bits to begin with (for argument's sake),
> then taking more than 4 bits for a context value might have a
> large impact.

I must be missing something here again.  This seems to say that the bit
length of the envelope is fixed to some number of bits and the more
fields we want to cram into the envelope the shorter the bit lengths of
fields must be.  Is there a good reason why the bit length of the
envelope shoud be fixed in this fashion, or perhaps are you arguing
that the bit length of the envelope should be as short as possible?

> This is a question vendors might answer: how many
> context values and tag values are you willing to support on future
> platforms and how many are you willing to back fit on existing ones?
> 

Yes, this would be a good question for the vendors indeed.  

VENDORS - PLEASE PLEASE PLEASE DO ADVISE US ON THIS ONE. 

> Last, I don't see a need for billions of contexts. My model calls
> for most programs to use handfuls, not thousands.

Yes, your model demands that programs use a handfull, the concern which
I have is that complex and highly modular software will not be able to
conform with your model, inhibiting the development of third party
software. 

> I would also like to
> think (this is a hopeless cause, but here goes) that much of
> MPI could be implemented in hardware, not just the communications
> part but the part that we now think of as overhead. This would
> greatly extend the class of programs that could benefit from
> parallelization, and I oppose for this reason things which add
> unnecessary complexity to the communications process. 

I am sure that vendors do take very seriously the possibility of
implementing relevant parts of MPI in hardware. 

Best Wishes
Lyndon

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