Subject: mpi-context: Why scarce contexts?

From: L J Clarke <[email-masked]>
Date: Fri, 9 Apr 93 17:20:03 BST

Dear MPI Colleagues.

This question is primarily directed at Mark Sears.  

Mark, in Proposal VII you say that contexts will be a scarce resource,
in fact you suggest 16 which is in my mind very scarce indeed. 

Why do you say this? It will help me/us if I/we understand, I am sure. 
Please reply. 

Best Wishes
Lyndon

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

---

From: [email-masked]
Date: Fri, 09 Apr 93 11:06:58 MST

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

First, we don't have any right now, so that is a data point :-)

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.

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. 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?

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

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. 

Mark Sears
Sandia National Laboratories

P.S. My proposal is VIII, not VII.