Subject: MPI directions & priorities

From: [email-masked] (Steve Huss-Lederman)
Date: Wed, 10 Mar 93 08:13:18 EST

I was in the process of composing a note to the committee about what
MPI-1 should compose and was letting it sit overnight when Tom sent
out his message.  Since he has done a nice job I will shorten my
comments.

At the last meeting there were several group and private discussions
about the growing complexity of MPI.  Al has posted his feeling that
point-to-point and collective communications get complex and untested
ideas added but other areas such as dynamic processes are not
considered.  Jon posted about the complexity and now Tom has started a
list of priorities.

I add my voice to these concerns.  I have been hesitant to post
because I don't want it to seem that I think MPI is hopeless.
However, I think it is clear that we cannot adequately complete all
the current proposals in 3 more meetings.  I would propose that we
continue the discussion concerning priorities via e-mail and begin the
next meeting with a whole group meeting to set our course.  At the
higher level we need to decide:

1) How long will the MPI-1 process be allowed to take?  Are we going
to stick to the 6 month deadline or try and extend it?

2) What is going to be in MPI-1?

3) Of the things we leave out of MPI-1 are they going to be proposed
for a later version of MPI?  Should we make sure that MPI-1 is
compatible with the future goals so that major changes in the base
routines is not needed later?

4) If we want to have MPI-#, what mechanism and time scale will be
used to get it done.

I think it is past time to find the forest for the trees.  Global
planning to focus our efforts now could significantly reduce our
discussions and efforts in the short term as deadlines approach.
Furthermore, with a global blueprint we might see a more even handed
approach to different aspects of the standard.  These are just some
thoughts.  I hope the discussion will continue.

Steve

---

From: William Gropp <[email-masked]>
Date: Wed, 10 Mar 93 09:13:13 CST

One approach that we could take is to describe a set of MPI that is extensible
to the more elaborate facilities but does not yet specify them.  For example,
we could keep the goal of being "thread-safe" and resolve (at least in an
extensible way) the group/context/process-id issues, and then settle on, for
example, somethine like what Rusty and I have called level 3, plus some
collective communication routines.  This would not have everything that I would
want or even consider important, but would be a usable set for casual use.

This is a very different process than just defining a simple set of operations;
it MUST be possible to extend, in a consistent way, MPI to meet new needs.
I'd like to point out that many of the so-called new features are ones that
are in use in some (usually only one) system; in most cases they fulfill
a perceived need.  For MPI to be successful, it must not be incompatible with
these needs.  

I realize that the other side of this is that, by specifying only a subset of
desired functionality, there is the danger of mutually incompatible extensions.
We need to weigh this against the possibility that MPI will become too complex
to be accepted.

Bill