[Mpi3-subsetting] agenda for subsetting kickoff telecon ww09

Thu Feb 28 12:04:32 CST 2008

Hi  everybody,

Thank you for your time today. It was a very good discussion. Here's
what I captured (please add/modify what I may have missed):

Present: Leonid Meyerguz (Microsoft), Rich Graham (ORNL), Richard
Barrett (ORNL), Torsten Hoefler (ISU), Alexander Supalov (Intel)

- Opens & introductions 

- Scope of the effort 
  - Rich
    - Minimum subset consistent with the rest of MPI, for
performance/memory footprint optimization
    - Danger of splitting MPI, hence against optional features in the
standard
    - Both blocking & nonblocking belong to the core
  - Torsten
    - Some collectives may go into selectable subsets
    - MPI_ANY_SOURCE considered harmful
  - Leonid
    - Flexible support for optional features, means for choosing and
advertising level of compliance/set of features
  - See enclosed email for Alexander's POV

- General discussion snapshots
  - Support of subsets: some or all? If some, possible linkage problems
in static apps (or dead calls). If all, where's the gain?
  - Optional: really optional (may be not present) or selectable (are
present but may be unused)?
  - Performance penalty for unused subsets: implementation matter or
standard choice?
  - Portability may be limited to certain class of applications (think
FT, master-slave runs)
  - All we design needs to be implementable, complexity needs to be
controlled
  - An ability to use certain set of subsets should not preclude pulling
in other modules if necessary
  - Whatever we do, it should not conflict with the ABI efforts
  - Need to stay nice and be nicer wrt to the libraries (think
threading) and keep things simple
  - The simplification argument, if put first, may not be liked by some

- Next steps
  - Please comment on these minutes, and add/modify what I may have
missed
  - I'll prepare a couple of slides by next week summarizing our
discussion so far; again, your feedback will be most welcome
  - At the meeting, it may be great to meet F2F briefly and discuss any
eventual loose ends before the presentation at the Forum; I'll see to
this

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.

<strong>attached mail follows:</strong>

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

* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi3-subsetting/attachments/20080228/673bb604/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi3-subsetting/attachments/20080228/673bb604/attachment-0001.html>