Subject: Re: MPI Goals and Scope: More Details Please?

From: L J Clarke <[email-masked]>
Date: Wed, 10 Mar 93 01:45:05 GMT

Hi all

There seems to be something to be discussed in what Tom is saying.  Here
is my 2 pennies worth.  Please understand my multicomputer world bias,
or flame me for it, whichever your prefer. 

> > > We feel that the MPI standard should provide enough information to
> > > specify an entire, source-code portable program.  
> > > Bill & Rusty
> 
> > I agree.

This is going to sound awful picky, but I'm afraid I gotta say that I
disagree with this.  It's a grand ambition, and its also a grand
challenge, in fact I conjecture that MPI is implicitly incapable of
completing the stated mission even given arbitrary time, and that it is
not a valid goal for MPI.  The goal requires MPI to describe a whole
raft of issues which are outwith MPI. 

I reckon John Flowers could spend the rest of his MPI time telling us
about his experiences in Parasoft and Express with the issues that MPI
cannot address!

So MPI needs a more restricted mission.  I'm too sleepy to try right now
to find a suitable modification of the above sentence which might serve
as a better mission for MPI. 

> 
> At the last meeting a straw vote lead to the adoption of "one processor can do 
> standard I/O".  If we do this, then users will use vendor-supplied 
> "parallel I/O" routines to get decent performance.  We cannot claim that the 
> MPI standard provides enough information to specify an entire, source-code 
> portable program unless we include I/O.  I think that there is general 
> agreement that "parallel I/O" will not be included in MPI-1.  

Don't you think it will be some time before the world is ready to even
think about standardisation of "parallel I/O".  I can't imagine trying
to do such a thing at the moment. 

> Maybe we could 
> re-state the portability goal:  

>   The ultimate goal of the MPI standardization effort is to provide enough 
>   information to specify an entire, source-code portable program.  

I have the same problem with this mission as that above.

> I certainly won't use MPI unless I believe that this will happen with some 
> version of MPI.  

I reckon you will, actually, because although it won't give you the
portability asked for above, it will be your best way of getting some
portability. 

> I think we should re-examine the scope of the MPI effort and write down what 
> we want to accomplish with MPI-1, MPI-2, etc. in much more detail than is 
> currently in the draft introduction.  

I concur, in an ambivalent fashion.  The introduction is vague, I'll
agree with that.  I think we are currently working out what we should be
doing, in a rather ad hoc fashion. 

> John Flower has proposed one 
> prioritization.  Here's another (from my perspective as a user):  

I'm going to walk down this list and give marks out of ten, with ten as
highest priority and 0 as lowest priority, from my point of view, and
some justification, from my point of view. 

> 1)   Static process creation and identification (and associated environmental 
>      inquiry routines).  

10 - bare minimum MPI can acheive without being complete waste of time.

> 2)   Contexts.  

9  - can get away with just tags but would impede library development.

> 3)   Heterogeneous communication semantics (I think we already have this).  
>      All communication routines should support heterogeneous communication.  

6  - static SPMD programs are most sensible in homogeneous machines.

> 4)   Blocking send and receive, contiguous data.  

10 - bare minimum MPI can acheive without being complete waste of time.

> 5)   Non-blocking send and receive, contiguous data (status(), wait(), 
>      cancel()?).  

10 - bare minimum MPI can acheive without being complete waste of time.

> 6)   Creation/destruction of "static" groups (by "static" I mean processes 
>      cannot join/leave an existing group).  Grid/toroidal process topology 
>      would go here if we decide to include it.  

8  - can get away with just tags but would impede library development.

> 7)   Blocking collective communication, contiguous data (broadcast, 
>      multiple-broadcast, concatenate, barrier, etc.).  

10 - bare minimum MPI can acheive without being complete waste of time.

> 8)   "Simple" commonly used blocking collective operations (sum, max, min, 
>      etc.).  

10 - bare minimum MPI can acheive without being complete waste of time.

> 9)   Blocking send and receive, strided data.  

8  - useful, but not essential.

> 10)  Non-blocking send and receive, strided data.  

8  - useful, bit not essential.

> 11)  Blocking collective communication, strided data.  

5  - makes collective communications too big.

> 12)  Blocking send and receive with buffer-descriptor.  

8  - useful, but not essential.

> 13)  Non-blocking send and receive with buffer-descriptor.  

8  - useful, but not essential.

> 14)  Blocking collective communication with buffer-descriptor.  

5  - makes collective communications too big.

> 15)  "User-defined" blocking collective operations (Express "excombine()"
>      style).  

10 - bare minimum MPI can acheive without being complete waste of time.

> 16)  Probe (and associated "precv()" routines, if necessary).  

0 (boy, am I biased! :-)

> 17)  Non-blocking collective communication, contiguous data, strided data, and 
>      buffer-descriptor (and "multi-cancel()"?).  

5  - makes collective communication to big, and has technical complications.

> 18)  Definition of parallel I/O.  

2  - too early to think about standardisation.

> 19)  Blocking parallel I/O.  

2  - too early to think about standardisation.

> 20)  Non-blocking parallel I/O.  

2  - too early to think about standardisation.

> 21)  Additional environmental inquiry and "setting" routines for performance 
>      optimization (suggestions for system buffering, relative 
>      node/interconnect performance, etc.).  

2  - useless without better knowledge of how to use them.

> 22)  Dynamic process creation and identification.  

6  - process group creation and resize is tractable model

> 23)  Dynamic groups (processes can join/leave an existing group).  

2  - asynchronous join/leave very experimental

6  - process group creation and resize is tractable model

> 24)  "Safe" send and receive.  

10  - bare minimum MPI can acheive without being complete waste of time.

> 25)  Ready-send and ready-receive.  

0   - what benefit except for some old machines?

> 26)  General process topologies.  

8   - if we have topologies at all, then should do this.

> 27)  Even more neat stuff.  

?   - ???

[stuff deleted]

I think you can see what my staged schedule would be from the above.

> 
> I share John Flower's "EXTREME concern" about the complexity of the current 
> design.  I believe that the MPIF must agree on SOME prioritization list and 
> explicitly decide what is going to be in MPI-1 as soon as possible.

I concur, ambivalently, as I think that it will yet take a little time
for a strong consensus to emerge.

I applaude efforts to generate such a consensus.

> I also 
> feel strongly that we should decide what will be in future MPI versions to 
> give potential users some confidence that MPI will eventually be useful for 
> developing source-code portable programs.   

I am again ambivalent.  I think it important to identify what items
should be suitable for future MPI, but I'm not at all confident that it
will be practical to commit ourselves to a schedule for trying to
standardise such items. It will be harder to agree on standards for the
items which are deferred.

Best Wishes
Lyndon

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

---

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

I'd like to clarify what we mean by

 > specify an entire, source-code portable program.  

This is NOT intended to mean that MPI must provide a way to specify ANY (or
even most) source-code portable parallel program.  Rather, given restrictions
strong enough to satisfy a 2/3rds majority ( :) ), a way to specify at least
one source-code portable program.  In the spirit of extensibility, whatever
mechanism is proposed for this simple interface should not preclude non-MPI
solutions for more demanding situations.
Bill