Hi
everybody,
In the
run-up to our kick-off, here's my POV on the subsetting and its possible
scope/role in the MPI-3. Your comments and suggestions are most
welcome.
We
start this activity because:
1)
Certain industrial customers complain about MPI complexity and
inadequacy
2)
Complexity is going to grow in MPI-3
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
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.
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"
3) We
may cause some valid MPI-3 applications break if they use optional modules not
available in the implementation involved
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.