Subject: MPI directions & priorities

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

----- End Included Message -----

---

From: [email-masked] (Tom Henderson)
Date: Wed, 10 Mar 93 11:18:54 MST

Steve writes,

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

I'd like to stick to 6 months for MPI-1.  I'm willing to have less 
functionality in MPI-1 as long as there is a plan for further upgrade.  

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

Good question.  :)

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

Yes and Yes.  

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

Maybe next year we meet again for MPI-2?  We should have some experience with 
MPI-1 by then.  (...wait a minute, I only signed on for a six-month tour...)

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

Me too.  

> Steve

Tom Henderson
NOAA Forecast Systems Laboratory
[email-masked]

---

From: [email-masked] (Leslie Hart)
Date: Wed, 10 Mar 93 11:24:00 MST

> We need to weigh this against the possibility that MPI will become too complex

I agree with Bill, I think whatever we produce for MPI-1 should be extensible.  I
think we should consider carefully our semantics and syntax to not prohibit 
extensibility.  An approach that has been proposed by us (Tom Henderson and myself)
as well as by other people is opaque messages.  This allows an initial implementation
to support a relatively simple to use subset while allowing vendor extensions and 
future upgrades to MPI-1.  We could perhaps specify some core of MPI-1 (not a new
idea) as well as provide semantic and syntatical guidance to vendors for their 
extensions (e.g. a clue about MPI-2 if you will).  The opaque message object allows
these extensions to be put in place without an explosion of syntax.

Leslie Hart ([email-masked])

P.S  This may fit into Rusty & Bill's Level 1 or Level 2 proposal neatly.

---

From: [email-masked] (Leslie Hart)
Date: Wed, 10 Mar 93 11:34:13 MST

> From: Tony Skjellum <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: Re: MPI directions & priorities
> Cc: [email-masked]
> 
> We must agree to reconvene about extensions in future.  I also agree
> that it would be preferable to specify a whole portable program, but I
> think the I/O subject is hard to address right now...
> 
> - Tony

I also understood that the process would be ongoing and hope that it
will continue to track existing practice.  I think some parts of the 
I/O subject are hard to address right now, but there is some existing
common practice.  Parasoft, Intel, nCUBE and TMC all have some sort of
parallel I/O specification.  There are ways to force the effect of
a printf or of an fseek/fread/fwrite to be deterministic.  I believe that
the common practice could be standardized, maybe not in the time frame for
MPI-1 but probably for MPI-2 (which is where it appeared in Tom's posting).

Regards,
Leslie

---

From: [email-masked]
Date: Wed, 10 Mar 93 12:27:21 PST

> think the I/O subject is hard to address right now...

I presume that Tony speaks of parallel I/O.  

I agree that parallel I/O is too hard for now.

But I think that we have to specify at least some minimum
serial I/O capability.  

I would buy off on something as simple as

 . there exists one process that can do serial I/O in the standard
   fashion for the language (e.g., printf() or WRITE(*,*) )

 . the tid of that process can be obtained from MPI (in any process)

Example:

   if (mytid == MPI_IOROOT())
   {  printf ("I'm the designated serial I/O process\n");
   }

--Rik Littlefield