Hi everybody, Due to scheduling constraints, we're not going to have a special subset slot during the coming MPI Forum meeting. For that we'll have about 2 hours to discuss MPI-3 structure where subsets should figure prominently. If there's interest to talk subsets beyond this opportunity, I suggest that we meet as a group at one of the dinners or 1:1 as we bump into each other. Now, the action items from the last telecon. I need your help on one of them: - Create two query pages - For users - what their minimum subset would look like (functionality, performance) - For implementors - what they can profit from (performance, footprint) I remember someone at the telecon had a very good suggestion about how to formulate this. Can you take over this task now? I'm about to engage on the following three and the final MPI-2.1 review: - 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 will prepare to participate in the MPI-3 structure discussion at the meeting Best regards. Alexander ________________________________ From: Supalov, Alexander Sent: Wednesday, April 09, 2008 6:23 PM To: 'MPI 3.0 Sub-setting working group' Subject: RE: telecon, Wednesday, April 9, 8:00 am PDT/10:00 CDT/11:00 EDT/17:00 CEST 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 - Discussion of the proposal (see http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Subsets) - 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 ________________________________ From: Supalov, Alexander Sent: Tuesday, April 08, 2008 5:26 PM To: 'MPI 3.0 Sub-setting working group' Subject: telecon, Wednesday, April 9, 8:00 am PDT/10:00 CDT/11:00 EDT/17:00 CEST 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. *