[Mpi-forum] Discussion points from the MPI-<next> discussion today

[Jeff Squyres]

Process
- We need a better system for keeping notes / minutes / etc.

==========================================

Potential topics for MPI 3.1
----------------------------

- Scalable vector collectives (maybe?)

Point made: we don't have experience with 3.0 yet to know what the
errata are going to be yet.  Perhaps we should just gather errata over
the next 1-2 years and publish those as MPI-3.1.  Most of our time
will be spent on MPI-4.0.

Potential topics for MPI 4.0
----------------------------

Point made: perhaps we should just open up the topics and let groups
go do what they want for a little while.

This turned into a brainstorming session.  There's a LOT of topics
here.  Some feel research-ish.  We'll see what happens!

- Fault Tolerance (Aurelien)
- Hybrid <something>
  - Play nice with other systems: CUDA, OpenACC, Co-Array Fortran,
    OpenMP, UPC, ...etc. (Many)
  - Task-based parallelism: TBB, cilk+, etc. (Aurelien) (also listed
    in thread section)
  - Maybe impose some restrictions / conditions on the environment
    (OS, hardware, etc.) (Brian)
- Asyncrhonous file I/O (Dave)
- Fairness (Rolf)
- Non-blocking collectives: add tags?
  - If not, reply with reasons (e.g., symmetry w/ blocking, difficult
    to implement in hardware, etc.) (Jeff, from MPI Comments)
- Towards exascale:
  - Collate current complaints and formulate responses (similar to RMA
    WG analysis/response to Bonnechea's paper) (Brian)
  - Scalability issues (Christian)
  - Is MPI apppropiate? (Alexander)
  - What else...?
- Possible MPI_Count/MPI_Aint compatibiltiy problem with datatype
  constructors.  Aurelien will come up with the specific example. (Aurelien)
- Small group of minor Fortran things (Jeff)
- Persistent collectives (Christian)
- Examine possibilities of software defined networking (anything to
  standardize, or is this just an implementation issue) (Bill)
- Re-examine the definition of canceling a send: weird that it's a
  local operation with remote semantics (Brian)
- Is it possible to fix MPI_REQUEST_FREE to provide some kind of
  guarantee as to when the request has completed? (Rolf)
- Larger question: what do people need that MPI doesn't provide? (Brian)
  - E.g., point was made that much data is being stored in databases
    today. Should we define an interface to databases? (Alexander)
  - Things that <XYZ> should provide to support MPI well (e.g., XYZ =
    batch scheduler, or ...) (Brian)
- Bindings for higher-level languages?
  - C# bindings (Alexander)
  - Java bindings (Alexander)
  - Python bindings (Alexander)
  - ...Overall suggestions for higher level languages? (Alexander)
- Subsetting (e.g., standardized "MPI for <foo> subset") (Alexander)

- Non-technical topics:
  - Hyperlink Annex A function names (and handle types) to their
    prototypes (Bill)
  - Should we do this: for each MPI function, list which MPI standard
    version it appeared (Christian)

Point is made: challenging the basic assumptions of MPI (e.g.,
  fairness, guaranteed delivery, progress) is a good way to extend
  MPI. (Alexander)

Meta issue: threading issues and consistency

- Revisit whether "threads are dead": i.e., whether threads are too
  heavyweight to be used for a non-blocking operation (e.g., we put
  MPI_COMM_IDUP so that apps didn't have to spawn off threads to do
  this stuff) (Bill)
- Revisit progress rules (see above -- if we force apps to use threads
  to do things asynchronously, then perhaps we should also re-look at
  our progress rules) (Brian)
- Fix grequest (Jeff)
- Asyncrhonous dynamic process management:
  - Fix MPI_COMM_ACCEPT (Brian)
  - MPI_COMM_ISPAWN (Brian)
- Task-based parallelism: TBB, cilk+, etc. (Aurelien) (also listed in
  hybrid section)

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/