Subject: Resend of unofficial "opinion survey"

From: [email-masked] (Tom Henderson)
Date: Mon, 29 Mar 93 16:00:29 MST

Hi everyone,

Some folks have requested that the unofficial "MPI Opinion Survey" be 
distributed again.  Here it is.  Please ignore if you don't need to see it 
again!  :-)

Tom

-----------------------------------------------------------------------------

Hi all,

Steve Huss-Lederman writes:

> I would like to propose that we have a meeting of all participants at
> the start of the next meeting to settle the issue of what MPI-1 will
> cover.  Several mail messages have expressed concern that we cannot
> conclude by June if we try to incorporate everything that everyone
> wants.  Since the scope and time frame will effect most of the other
> discussions I think it would be best to begin with this.  My only
> concern is that it will take too long to decide the global picture.
> I would hope it could be done in 1-2 hours and help to refocus the
> group.

I fully support this idea.  Here's a proposal for an opinion survey that could 
shorten and focus the discussion.  This proposal originated with Jon Flower 
and has had input from Ian Glendinning, Steve Huss-Lederman, Leslie Hart, 
myself, and others.  If you think this is a good idea, please complete the 
survey and return to me at:  

    [email-masked]

If you think this is a bad idea, please say so!  We will collect responses and 
distribute a summary via email before the next meeting if there is sufficient 
interest.  

Tom Henderson

-----------------------------------------------------------------------------

                     MPI PRIORITIES OPINION SURVEY

Several MPI committee members have expressed concern about the current and 
future directions of MPI.  The MPI committee began discussion using an 
existing document (Dongarra et al) as a starting point.  This document 
contains background rationale and a statement of direction for the MPI 
standardization effort.  Since these issues were consistent with the original 
MPI proposal, they have not recently been discussed in detail by the MPIF.  

The current MPI proposals are very different from the original MPI document.  
As a result, we feel that the original rationale and direction need to be 
re-examined.  In particular we need to prioritize and limit the issues that 
MPI will try to resolve so that 

    o the initial MPI standard document ("MPI-1") is delivered in a timely 
      fashion 
and 
    o the functions that it defines can (and will) be implemented
      on major platforms within a reasonable time frame.

To get discussion of these issues started, we propose an informal, email 
"opinion survey".  The objective of the survey is to find out which MPI 
features are most important.  High-priority features would be included in 
MPI-1.  Lower-priority features might be deferred to a later version of MPI.  
Some features might never be included.  The compiled results of this survey 
could be used as a basis for discussion at the next MPI meeting.  

***
This survey is in no way binding and is a completely unofficial "straw
poll" arranged by its authors for their own personal information.  It is not 
intended to distract attention from the current proposals.  Any data collected 
will be made available to the group at large if requested.  
***

Following is a ballot containing possible MPI features and goals.  Please rate 
each item (or sub-item) using the following rating scheme:  

  0        This feature should not appear in any version of MPI ever.  
  1-2      MPIF should consider including this feature in some future version 
           of MPI (after MPI-1).  
  3-4      This feature should be included as an Annex to MPI-1 for possible 
           inclusion in a future version of MPI.  
  5-6      This feature should be included as an Annex to MPI-1 for definite 
           inclusion in a future version of MPI.  
  7-10     This feature should be included in MPI-1.  

In this context an "Annex" is a part of the standard document that will not
be required by a conforming implementation of MPI.  Rather it should be
taken as a recommendation by the MPIF to vendors for the way in which
particular features should be implemented, if they are implemented at all.
This way features that are not usefully implementable on particular hardware
can be eliminated while machines that do support these features do so in
a portable manner.

When replying to the survey, please use the response form attached to the end 
of this message.  (This will make compilation of the results a lot less 
painful!)  :-)

          +-------------------------------------------------------+
          | POSSIBLE FEATURES FOR INITIAL AND FUTURE MPI VERSIONS |
          +-------------------------------------------------------+

Ordering is for convenience only.  This list is not meant to suggest any 
priority.  

    GENERAL FEATURES

1)  Routines for static process creation:
    A) Same program in every node.  
    B) Host-node programming model in which there is one "special node".  
    C) Static model but with potentially different programs in different groups 
       of nodes.
    D) Static model with a way to create more than one process per 
       processor. (Heavy duty processes, not threads).

2)  Routines for identification of statically created processes.
  
3)  Associated environmental inquiry routines.  

4)  Some way of avoiding message tag conflicts between independently 
    developed libraries and user code (contexts).  

5)  Heterogeneous communication.  
    A)  All communication routines should support heterogeneous 
        communication.  
    B)  A special set of communication routines should support heterogeneous 
        communication.  

6)  Creation/destruction of "static" groups (processes cannot join/leave an 
    existing group).  Groups are used to limit the scope of collective 
    operations.  
    A)  No logical process topology is associated with a group.  
    B)  Grid/toroidal process topology is associated with a group at the time 
        the group is created.  (The default "ALL" group has a default 
        topology.)  
    C)  General graph topology is also supported.  
    D)  Provide access to all relevant information (via topological 
        environmental inquiry routines) to allow users to define custom 
        topologies.  

7)  Support for communication between processes in different groups without 
    reference to the "ALL" group.  

8)  Dynamic groups (processes can join/leave an existing group while the total 
    number of processes remains static.)  

9)  Dynamic process creation and identification.  

10) Additional environmental inquiry and "setting" routines for performance 
    optimization.  
    A)  Inquire/suggest system buffering resource allocation.  
    B)  Inquire relative node performance.  
    C)  Inquire relative interconnect performance.  

11) Termination of programs.
    A)  Kill all others nodes.
    B)  Wait for all the other nodes to complete.
    C)  Automatically de-allocate resources.

12) Standard organization.
    A)  "Multi-level" organization of routines (users may use simple features 
        without having to understand all of MPI).  
    B)  Simple "core" standard with (optional) Annexes.
    C)  Simple "core" standard without Annexes.
    D)  Should an MPI "subset" be defined that can be quickly implemented as 
        a layer on top of existing systems?  (This question was inspired by 
        section 1.5 of Bill and Rusty's "A Test Implementation of the MPI 
        Draft Message-Passing Standard", ANL-92/47.)  

13) Should there be future version(s) of MPI (MPI-2, etc.) (yes/no)?  

    POINT-TO-POINT COMMUNICATION

14) Blocking send and receive.  
    A)  Contiguous data.  
    B)  Strided data.  
    C)  Buffer-descriptor (multiple data locations, multiple data types).  

15) Non-blocking receive.  
    A)  Contiguous data.  
    B)  Strided data.  
    C)  Buffer-descriptor (multiple data locations, multiple data types).  
    D)  Check for completion (status()).  
    E)  Wait for completion (wait()).  
    F)  Cancel operation (cancel()).  

16) Non-blocking send.  
    A)  Contiguous data.  
    B)  Strided data.  
    C)  Buffer-descriptor (multiple data locations, multiple data types).  
    D)  Check for completion (status()).  
    E)  Wait for completion (wait()).  
    F)  Cancel operation (cancel()).  

17) Low-level functionality (from Marc Snir's proposal) visible to users.  
    A)  Initialize.  
    B)  Start.  
    C)  Complete.  
    D)  Free.  

18) "SECURE" versions of send and receive as proposed by Lyndon Clarke on 
    3/3/93.  (Correct programs using SECURE routines are guaranteed to work 
    regardless of system buffering resources.)  

19) Ready-send.  

20) Ready-receive.  

21) Message handlers (a la iNTEL hrecv, TMC active messages, Express 
    exhandle).  
    A)  Simple definition sufficient to support anticipated MPI 
        requirements and make a self-consistent system.  
    B)  More advanced routines for remote procedure calls, etc...  

22) Additional point-to-point primitives.
    A)  Exchange between two processors.
    B)  "Shift-exchange":  read from one, send to another (superset of "A").
    C)  Contiguous data.  
    D)  Strided data.  
    E)  Buffer-descriptor (multiple data locations, multiple data types).  
    F)  Non-blocking versions?
    G)  Check for completion (status()).  
    H)  Wait for completion (wait()).  
    I)  Cancel operation (cancel()).  

    COLLECTIVE OPERATIONS

23) Blocking collective communication.  
    A)  Broadcast.  
    B)  Concatenate.  
    C)  Barrier.  
    D)  Sum.  
    E)  Extrema (max, min).
    F)  Average.  
    G)  Sum of squared differences (error).  
    H)  Should strided data be allowed for these operations?  
    I)  Should buffer-descriptor be allowed for these operations?  

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

25) Non-blocking collective communication, collective operations, and 
    user-defined operations (if this is desired, detailed ranking can be done 
    later).  

26) If any non-blocking collective operations are supported, what should 
    completion/cancel options be?  
    A)  Check for completion (status()).  
    B)  Wait for completion (wait()).  
    C)  "Multiple cancel" operation (cancel()).  

27) Should status()/wait()/cancel() syntax be consistent across all types of 
    non-blocking operations?  

    OTHER COMMUNICATION OPERATIONS

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

    I/O

29) Standard I/O is supported in the standard fashion for the language on one 
    process (no file I/O).  This process can be identified by an environmental 
    inquiry routine.  (This is the current proposal.)  

30) Serial I/O is supported in the standard fashion for the language on one 
    process.  This process can be identified by an environmental inquiry 
    routine.  (Rik Littlefield's proposal.)  

31) Multiplexed I/O similar to that currently provided in systems such as
    CMMD (TMC), VERTEX (nCUBE) and Express (ParaSoft).  Basically a way of
    defining the behavior of multi-node I/O statements which interact
    with a sequential device.  No special considerations for parallel I/O
    channels.

32) Blocking parallel I/O.  Intended to take advantage of parallel I/O
    channels, where available.

33) Non-blocking parallel I/O.  Intended to take advantage of parallel
    I/O channels, where available.

LANGUAGE BINDINGS

34) Ada

35) C

36) C++

37) Fortran 77

38) Fortran 90

39) Other

IMPLEMENTATION PERIOD 

There will be a delay between the generation of the standard and its 
implementation on various platforms.  If this delay is too long users will 
continue to rely more and more heavily on vendor routines and specialized 
calls and MPI will become less and less attractive, particularly if new 
technology such as Fortran 90/HPF becomes effective.

40) What is the maximum delay that you think MPI can stand and 
    still succeed (please feel free to comment if you wish)?

----------------------------------------------------------------------------

SURVEY RESPONSE FORM

1)  A)  
    B)  
    C)  
    D)  

2)  

3)  

4)  

5)  A)  
    B)  

6)  A)  
    B)  
    C)  
    D)  

7)  

8)  

9)  

10) A)  
    B)  
    C)  

11) A)  
    B)  
    C)  

12) A)  
    B)  
    C)  
    D)  

13) (yes/no)

14) A)  
    B)  
    C)  

15) A)  
    B)  
    C)  
    D)  
    E)  
    F)  

16) A)  
    B)  
    C)  
    D)  
    E)  
    F)  

17) A)  
    B)  
    C)  
    D)  

18) 

19) 

20) 

21) A)  
    B)  

22) A)  
    B)  
    C)  
    D)  
    E)  
    F)  
    G)  
    H)  
    I)  

23) A)  
    B)  
    C)  
    D)  
    E)  
    F)  
    G)  
    H)  
    I)  

24) 

25) 

26) A)  
    B)  
    C)  

27) 

28) 

29) 

30) 

31) 

32) 

33) 

34) 

35) 

36) 

37) 

38) 

39) 

40) (free form):  

Comments?