Hi everybody,
Thanks for your time today. Here's what we discussed (I
captured what I could, please add/modify):
Present: Richard Graham, David Gingold, Keith
Underwood, Alexander Supalov
- Opens
- Complexity needs to be defined. Discussion on
the aspects:
- Many people only use a few calls,
don't need the rest; difficulty of learning is related to
this
- Sheer mass of the number of calls
expected in MPI-3 may make complexity unmanageable, requires
hierarchy
- Performance implications are not
considered primary motivation for subsetting, but removing them may
help
- E.g., extra cache effects may be induced by complexity (e.g.,
communicators)
- This can
in principle be defeated by prioritization of the hottest data
fields
- We'll add the existing laundry list of
things that may affect performance
- Inviting people to quantify
the performance benefits may help to identify promising
areas
- We may need hard facts to
gauge potential performance gains
- We may
need "fast stuff" subset people will safely be able to use
- Making parts of the standard
optional may be easier with subsets
- Dynamic processes seem to be a
good example - some may disagree
- You may wait for the
pull or create it; anyway, there's no big pull on this in the volume market
yet
- High end users are
starting to use dynamic processes, though
- Selection at compile- link-, and
runtime
- Compiler time is a little
controversial, but there are already some measurements that quantify
this
- Link time comes in 3
forms
- Static linker is smart
and will pull out of the .a only those components the program
uses
- Dynamic linker is not
smart, but there's chance to either
- Do dlopen
from within MPI to load extra modules (not everyone's favorite),
or
- Switch
on/off parts of functionality in a bigger library - this is where runtime comes
in
- Runtime (MPI_Init and/or
per-communicator basis)
- E.g., disabling
MPI_ANY_SOURCE on a communicator may speed up processing
- Should a program that runs on a subset also
run on a full MPI implementation? Probably, yes
- There's need to convince the community
that subsetting is a good idea, and portability will help
- There should be one standard but
flexibility for MPI to adapt to a particular set of
applications
- If applications are portable
across MPI, they won't actually care of the rest of MPI
- The shape of MPI-3 may be strongly influenced
by subsets
- The whole of the standard may be
split into subsets, some of which might be optional
- Vocal opponents may wrack subsets;
we need hard data before we bring this matter up
- Should subsets be predefined or should MPI
provide a mechanism to define them
- Think error handling: mechanism is
there, as are several predefined handlers; this model works
- Danger of proliferation of
multiple mutually incompatible subsets will increase with the mechanism
definition
- Next steps
- Alexander will add the description
of the complexity matter upfront to make readers see their favorite pain
points
- Alexander will add the existing
laundry list of controllable features and ask for associated
perf/footprint data
- Alexander create two query pages
- For users - what their minimum subset would look like (functionality,
performance)
- For
implementors - what they can profit from
(performance, footprint)
- Alexander will
prepare to participate in the MPI-3 structure discussion at the
meeting
Best regards.
Alexander
Hi everybody,
This is a reminder: the
subsetting telecon will be held
on Wednesday, April 9, 8:00 am PDT/10:00 CDT/12:00 EDT/17:00 CEST. The
bridge details are as follows:
Outside Intel: +1-916-356-2663, Inside
Intel: 8-356-2663, Bridge: 5, Passcode: 2603880
The primary goal will be to
go thru the draft proposal available in the
Wiki (see http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Subsets),
and to see what we can report to the
Forum end of April. Please send to me additional agenda items you want to
discuss.
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.