Subject: Re: Jon's suggestion

From: [email-masked] (Al Geist)
Date: Thu, 11 Mar 93 11:21:24 -0500

Jon writes:
> 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

I do not reject this in fact I applaud your suggestion.
This may be the only way we can get MPI-1 off the ground.
I am a big advocate of maximizing ease of use
this is only way to get the large user base necessary
for MPI to become a standard.

Al Geist

---

From: [email-masked] (Leslie Hart)
Date: Thu, 11 Mar 93 10:32:53 MST

> for MPI to become a standard.

I also agree.  I think that there is significant concern regarding
the near term and long term success of MPI.  I think some of the
concern can be aleviated if we settle on a goal that can be reached
by this summer.  It may be wise to set up some sort of electronic
straw poll procedure to help get us past some of the issues regarding
what should be in the first MPI, what are our goals for MPI-1, is there
going to be MPI-N (for N>1), what features are most important for MPI-1, etc.  
Perhaps we can use similar rules to those agreed upon in the first meeting.  
You must have been in Dallas for 2 of the last three meetings (1 of the 
first 2, I guess).  Calls for vote should be made through the committee 
chair (or someone appointed by the committee chair).  The votes will be 
counted over a three day period by the comittee chair (or the designee) 
and reported. (Only your "last" vote counts :-).  These will, of course, 
be straw polls and will be reported again at the beginning of the next 
Dallas meeting.

Regards,
Leslie Hart ([email-masked])

P.S. We may wish to use a separate mail list for voting (mpi-vote??) which 
     includes those eligible to vote via the voter elibibilty rules.
     Of course, votes for a particular topic should be clearly identified and
     the sense of the vote should be clear (i.e  yes or no).  The suggestion
     of electronic votes is important to me, but the mechanics is not
     that important.

---

From: Ian Glendinning <[email-masked]>
Date: Thu, 11 Mar 93 18:16:58 GMT

> From: [email-masked] (Leslie Hart)

> going to be MPI-N (for N>1), what features are most important for MPI-1, etc.  
I agree.  Just when I thought things were converging there's been a flurry
of alternative proposals.  For example, can we please agree *not* to address
concurrent I/O in MPI1, else we'll never get finished within the allotted
timescale.  On the other hand, I do think that we should decide to have an
MPI2, and that that would be the proper way to deal with such issues.  I
don't think concurrent I/O is an intractible problem, its just that to do a
reasonable job on will require more time than we've got right now.  Another
case in point is dynamic vs static process creation.  My vote is for static
now, dynamic later.  If we can agree that there will definitely be an MPI2,
then maybe we can keep everyone happy in the sense that their favourite
features *will* all be included, but in a staged fashion.
   Ian
--
[email-masked]        Ian Glendinning
Tel: +44 703 593368                  Dept of Electronics and Computer Science
Fax: +44 703 593045                  University of Southampton SO9 5NH England