From: [email-masked] (Jon Flower)
Date: Wed, 10 Mar 93 10:55:34 PST

To: [email-masked]
Re: A way of prioritizing?

Something Bill said seemed to strike a chord in my mind:

> 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 also have the feeling that a lot of the things that we're
trying to put in MPI are really only based on experience
(or even need) on a single machine. Sometimes that machine
may even be "pre-history".

My question is: Is incorporating into MPI a feature that is
only based on a single machine any better than allowing a 
vendor-specific extension on that machine?

Take "ready-receive", for example. Adding this to MPI means
that users can justifiably put it in their portable codes. If
they do, however, what should they assume about it? That it's
faster or slower than the non-ready receive? I assume that
there will be systems in which it's slower than the non-ready
recv. because of the extra protocol that the application might
need to ensure that the ready-recv.'s don't crash. In this
case, are we expecting users to put code in their applications 
that can switch between ready-recv, and non-ready-recv semantics 
based on the hardware they're running on? Although I think 
there are some users who will do this (and I would encourage 
library developers to do so) I think this is far beyond the 
lengths that most users will go to.

So what am I suggesting? 

---------------------------------------------------------
My suggestion (which I expect to be roundly rejected) is 
that the MPI document ONLY contain the stuff that is current
practice. This includes EVERYTHING required to run at least
a common class of programs - i.e., MPI_INIT or some such.

These things should be designed to maximize ease of use and
learning and encourage portability.  By this I am including 
performance level portability. I would like to not have
things in the spec. that run well on some machines and 
poorly on others. I would include a requirement that a
conforming implementation include either documents or 
(preferably) programs from which a user could assess 
the performance of the various routines.

All the other things that are off-shoots of requirements 
for odd-machines or otherwise more advanced should go in
Appendices or "Annexes" (Ada notation(!)) ***AND WOULD NOT
BE REQUIRED BY A CONFORMING IMPLEMENTATION OF MPI ***.
---------------------------------------------------------

The effect I am after is that the core MPI standard is simple,
effective and encourages users to write code. The annexes 
essentially say to vendors; "If you want to support an 
advanced feature that will really help on your machine, 
please do it this way so that my programs that use it 
will be portable."

This is similar to Bill & Rusty's multi-level scenario except 
that I wouldn't make the lower levels compulsory.

My hope is that two things will happen if we adopt this
strategy:

    a) Details of things that go in Annexes can be 
       postponed or left vague, or even left to specially
       interested groups to define, but we will definitely
       have something that could be used by an application
       developer at the end of the six months.
    b) The MPI core would be smaller which will encourage
       users/vendors to make implementations, and to optimize
       the #$%$% out of them.

If this concept is acceptable I would suggest that someone
prepare a list of topics, in quite great detail, and we 
all give them grades out of ten (via e-mail), just as 
Lyndon did. Someone with experience with statistics 
could analyze the results and give us weighted rankings
at the next meeting. 

We could then prioritize according to this list and 
also make guided decisions as to what should go in the Annexes.
I would then suggest that we go back to the small sub-committee
approach to putting the Annexes together rather than our current
"committee-of-the-whole" style which seems to encourage hour-long
"arguments" followed by 35-0 votes!

	Jon Flower

p.s. Having suggested a pile of work I should say who's going to
     do it. In the absence of any volunteers I might be persuaded
     to come up with a list of issues on which we should score. I'm
     not sure my statistical skills amount to anything much more 
     that simple averages, so someone else could certainly do better
     than I.

     I would be very interested in working with a group/sub-committee
     trying to get up a set of MPI-compliant performance evaluation 
     standards.