As of March 7, 2012, the new “use mpi_f08” bindings have been officially voted in to the MPI-3 standard.
A few other minor corrections made it into MPI-3 at the same meeting, but they’re boring / not worth discussing.
What is worth discussing, however, are some proposals that passed their first (of two) formal votes to make it into MPI-3 at that same meeting:
- Ticket #284: Allocate a shared memory window
- Ticket #168: Nonblocking Communicator Duplication
- Ticket #286: Noncollective Communicator Creation
Let’s give a few details on each of these…
#284: MPI has long stayed away from defining anything to do with locality — with good reason. One of the major goal of MPI is to abstract above the network and physical layers. However, there are some solid use cases when applications can be “smarter” if they have at least some knowledge of the underlying system — or at least indicate their intent so that the MPI implementation can map it to the underlying system in an efficient manner.
Proposal #284 is in that spirit. It introduces the MPI_WIN_ALLOCATE_SHARED function (and MPI_WIN_QUERY_SHARED), which, as its name implies, allocates an MPI window that happens to exist in shared memory between the processes that created it (note, however, that it is the application’s responsibility to figure out what processes can share memory).
All the (new) MPI(-3) one-sided semantics remain with regards to the allocated window, but the fact is that it can be used as a “normal” shared memory segment.
#168: Introduces MPI_COMM_IDUP — a non-blocking version of MPI_COMM_DUP. The rationale is that it’s useful for libraries that dup MPI_COMM_WORLD behind the scenes to be able to do this in a non-blocking fashion, particularly for large communicators, or applications with many different communicators (since allocating a new, unique communicator context may be an expensive operation).
And yes, the Forum decided that we wanted the “I” before “DUP”, not before “COMM”. We decided the same “I” placement for other new MPI-3 non-blocking functions, too — this is a consistency issue.
#286: Introduces MPI_GROUP_COMM_CREATE — a way to make a communicator that is not collective over an entire parent communicator. Such functionality is useful if you want to make a new communicator that is only a small subset of a parent communicator (e.g., for a halo distribution, or somesuch). Why block the whole parent communicator when only a small portion of it will actually need a new communicator?
Note that there were many proposals that had their first formal reading at this meeting, too. By the Forum’s rules and planned timeline, all of these proposals are the last ones that are eligible to make it into MPI-3.
I’ll discuss some of the more interesting proposals in my next post.