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

[Jeff Hammond]

RMA)

I would like nonblocking variants of all the collective operations in
the RMA chapter, particularly MPI_Win_{create,allocate}.  I already
provided justification for this to the RMA working group but there
wasn't time to deal with it for 3.0.

P2P)

I would like MPI_(I)RECV_REDUCE, which - as you might guess - does a
reduction to the receive buffer instead of a simple write.  This
allows one to avoid having to manually buffer incoming messages to be
reduced at the receiver.  Torsten and I have discussed it and it seems
there are at least a few use cases.

Environment)

Previously posted minor changes to stipulate thread-safety of
functions like MPI_Initialized, MPI_Finalized and MPI_Thread_level (?)
in all MPI_THREAD_XXX modes, which was +1'd by Jeff S.  I think these
changes are more of the MPI 3.1 variety than MPI 4.0.

Jeff

On Thu, Sep 20, 2012 at 10:54 AM, Jeff Squyres <jsquyres at cisco.com> wrote:
> 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/
>
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum



-- 
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond