Cisco Blogs

The last new things in MPI-3

March 28, 2012 - 0 Comments

I know we’ve been talking about new MPI-3 things for forever.  But this is the last list of new things.

I promise.


I can say this with certainly because the Forum’s March meeting was the deadline for all new proposals to make it into the MPI-3 standard.  Anything else will have to be in MPI-<next> (where <next> may be 3.1, or 4, or …11.  Shrug).

Because of the deadline, we had a blizzard of proposals finally get into shape to be presented to the entire Forum.  Let’s talk about some of the more interesting ones…

#217: Hybrid MPI+threads proposal. This proposal is also related to #310 (explicitly describing multiple MPI processes in a single address space, which has long-since been allowed, but is being formalized with this proposal) and #311, which adds the ability to migrate MPI processes between threads in the same address space.

These three proposals all add more clarity with regards to how threads interact with MPI, and add a few new definitions.  While, in general, clarifying thread behavior in MPI is a Good Thing, the readings for these were somewhat contentious.  It’s not entirely clear to me what’s going to happen to them.

#281: Remove the MPI C++ bindings. Note that MPI-2.2 deprecated the MPI C++ bindings (so no new C++ bindings have been added for all new MPI-3 functions), but did not actually remove them.  This ticket actually removes all the MPI C++ bindings from the MPI-3 specification.  MPI implementations will still be allowed to have C++ bindings, of course, for backwards compatibility (I don’t imagine that any MPI implementation will remove its C++ bindings any time soon).

This proposal is also related to #303, which moves all the other deprecated MPI functions (some of which have been deprecated for 15 years) into a separate “Deleted Interfaces” chapter.  Just like the C++ bindings, it means that these functions are no longer officially part of MPI, but they can still be included in MPI implementations for backwards compatibility.

#323: New fault tolerance proposal, which later got split into multiple parts (#326#327).  This is a wholly-new, totally-different-than-prior proposals from the fault tolerance working group.  In short: it’s much smaller and simpler than prior fault tolerance proposals.  It aims to define relatively simple semantics for what happens when a process dies, and provide a small number of primitives for recovering consistent state.  I encourage all application developers to read the PDF attached to #323.

There are others, of course, and they’re all important, but these are the “interesting” (to users) ones, IMNSHO.

Keep in mind that there’s no guarantee that the above proposals will all make it into MPI-3; they haven’t even had a first vote yet.  We’ll see what happens to them over the coming months…


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.