[Mpi3-subsetting] Subsetting scope: a POV

[Bronis R. de Supinski]

Alexander:

Re:
> We start this activity because:
>
> 1) Certain industrial customers complain about MPI complexity and
> inadequacy

While this is a legitimate concern, it cannot be allowed to
cause the standard to devolve into a fractured morass that
removes the portability of MPI programs that has been a key
aspect in the success of MPI.

> 2) Complexity is going to grow in MPI-3

True. And it is not clear that many of the proposed extensions
are required for portable programming. In fact, they could be
designed with the idea that they are optional in mind.

> 3) Growing complexity may have growing performance implications
>
> As a result of the above, customers drift away from the MPI to
> home-grown libraries, usually based on sockets. This effectively
> eliminates fast networks from their scope, unless they can profit from
> fast IP emulation layers. Moreover, this customer drift, if continued,
> may make MPI irrelevant in some HPC areas and lead to creation of
> alternative interfaces there.
>
> The main purpose of the Forum, as well as the subsetting WG, is thus to
> react to customer demand and make MPI faster and easier to use,
> especially in those areas that are subjected to the increasing customer
> drift (think, e.g., massive master-slave computations).
>
> Basing on these premises, the subsetting, in my mind, should try to:
>
> 1) Make MPI standard modular. This may include:
>     a) Splitting the standard functionality into coherent groups that
> users will be able to select/deselect at init time
>     b) Making implementation of some modules/functionality optional
> (think dynamic process support) as they are anyway now

The key issue will de defining what is optional. Clearly, dynamic
process support is a good candidate since it already effectively is.
However, most of the functions from MPI-1 are not (there may be some
concepts/features that can be -- perhaps wild cards and topologies)
but the main communication functions (particularly the full set of
collectives) are not; nor is the profiling interface (in fact one
could argue that the profiling interface could subsetted in corrspondence
to the user level subsetting; it's not clear anything else makes sense).

>     c) Addressing not only functional groups but also certain aspects of
> the standard that may not be needed in certain use cases (think
> communicator management, message tagging, derived datatypes,
> MPI_ANY_SOURCE support, non-blocking communication, etc.)
>
> 2) As part of the modularization, optionally identify the minimum
> functional MPI subset. This may be:
>     a) Those 6 calls (Init, Rank, Size, Send, Recv, Finalize), possibly
> w/o communicator management and derived datatypes.

This may be a reasonable set. One thing that needs to be stated
is that the minimal subset should not be the only non-optional one.
If you do that, then portability is lost.

>     b) A more flexible combination of modules actually needed by the
> user
>
> 3) Connect subsetting with other MPI-3 activities (FT, ABI, collectives,
> etc.)
>
> As a result of modularization, we should strive to achieve
>
> 1) Simplification of the standard for the newcomers
> 2) Performance advantages for reasonable module combinations
> 3) Influence upon the overall shape of the MPI-3 standard
>
> There are certainly quite a few concerns here:
>
> 1) We may end up complicating the standard and its implementation even
> further
> 2) We may facilitate a split of the standard into several mutually
> incompatible implementation "families"

Yes, this probably the most significant concern. You can
certainly subset the standard without making it more complicated
but the obvious way to do it easily results in this problem.

> 3) We may cause some valid MPI-3 applications break if they use optional
> modules not available in the implementation involved

A publish/subscribe query interface is clearly a minimal
part of what needs to be provided.

Bronis

> 4) We may get carried away by academic considerations and miss the
> actual customer demands in the process
> 5) We may be engaging into a lost battle because the MPI standard is way
> too rigid by design/purpose to be simplified
>
> To guard against all this, we need to work closely with other WGs and
> the Forum as a whole, define our goals as early as possible, and solicit
> extensive Forum and customer feedback.
>
> >From all this, by the time of the Forum meeting in March, we should have
> at least a couple of slides reflecting our intentions and plans.
>
> Best regards.
>
> Alexander
>
> --
> Dr Alexander Supalov
> Intel GmbH
> Hermuelheimer Strasse 8a
> 50321 Bruehl, Germany
> Phone:          +49 2232 209034
> Mobile:          +49 173 511 8735
> Fax:              +49 2232 209029
>
> ---------------------------------------------------------------------
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen Germany
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
> Registergericht: Muenchen HRB 47456 Ust.-IdNr.
> VAT Registration No.: DE129385895
> Citibank Frankfurt (BLZ 502 109 00) 600119052
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>