March 2008 - Mpi3-subsetting - mailman3.cels.anl.gov

MPI3: Proposal to remove PMPI-Requirement
by unknown＠example.com 05 Mar '08

05 Mar '08

Dear Alexander, dear all, at the previous Chicago meeting, some of us (Rich Graham, Jeff Squyres, Hubert Ritzdorf) have been discussing about the MPI-Standard's requirement to provide PMPI-functions for each MPI-Call into the library (except MPI_Wtime, MPI_Wtick). This is in my eyes a limitation: there could be some gains for the common case of large-scale applications: - Not using PMPI-based tools (dynamically loaded in) - Not using MPI_PROC_NULL - Not using MPI_STATUS_IGNORE So, if this proposal would fit Your definition of MPI3-Subsets, I would like to discuss the removal of the PMPI-function requirement, allowing inlining of MPI-functions and, based on that, pre-processor hints, e.g. MPI_HINT_NO_THREADS or MPI_HINT_NO_ANY_SOURCE, so the compiler might be able to eliminate several if-statements in the fast-path, allowing inlining, allowing dead code elimination. (of course, there is a whole lot of further issues involved, here -- please see the last section in the document). I have included some timings with NetPipe on Open MPI using these hints (further information section 4 -- Ompi Patch availble upon request, as its work in progress). Please take the timings with a grain of salt. I would like to get better figures on a more well-defined cluster environment. Any comments would be welcome. With best regards, Rainer -- ---------------------------------------------------------------- Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller HLRS Tel: ++49 (0)711-685 6 5858 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832 70550 Stuttgart email: keller_at_[hidden] Germany AIM/Skype:rusraink *

1 0

Re: [Mpi3-subsetting] mpi3-subsetting Digest, Vol 2, Issue 3
by unknown＠example.com 05 Mar '08

05 Mar '08

> Also, lots of people seem to like the idea of getting rid of MPI_ANY_SOURCE > in a subset. I am one of these people. MPI_ANY_SOURCE is a problem. The > difficulty is that the master in a master worker algorithm is likely to > find MPI_ANY_SOURCE and MPI_PROBE useful. This issue captures a (the?) key decision that this group must make imo. Is the goal of the sub-setting to provide a performance boost, or to address the "mpi is too big" concern? In some sense the concerns overlap, but here is a big example of where they often don't. Many of the applications I've worked with use it in setting up communication (esp. in amr codes). And many of these people asked for an mpi-subset. Interesting to note that for many of these codes, actual performance of the send/recv is _not_ an issue - the work associated with preparing and managing messages for those sorts of codes, as well as the work imbalances, overwhelm the performance issues. (But note these code teams may _say_ mpi performance is an issue, but a complete view of their communication requirements does not support that claim.) However, they also require MPI_ALL_REDUCE, and at the peta-scale, so performance there is critical. MPI_ANY_SOURCE is found in many libraries I use, but library developers seem to make significant use of mpi functionality, without complaint. All this said, admittedly counter-claims and examples may be produced. However, as Dick stated for the Master/worker model, a large segment of users "require" MPI_ANY_SOURCE" somewhere in their code. I'm not saying a decision needs to be reached quickly, but I do believe we should keep this issue clearly in view in order to keep the discussions on-track. Richard -- Richard Barrett Future Technologies Group, Computer Science and Mathematics Division, and Scientific Computing Group, National Center for Computational Science Oak Ridge National Laboratory http://ft.ornl.gov/~rbarrett

1 0

Subsetting slides
by unknown＠example.com 05 Mar '08

05 Mar '08

One argument for subsetting is that MPI is somehow not well suited to massive master-worker applications. It does seem reasonable to me that pure master-worker applications have little use for many of MPI's features. Most communication may be point to point because workers are not expected to cooperate or communicate among themselves. Groups, topologies, new communicators, MPI-IO etc are not very useful. In the simple case, the master hands each worker a piece of work to do and the worker runs on its own until the work is done. As a worker finishes, it sends an answer to the master and waits to be handed another piece of work. Some pieces of work are brief and some are not so workers are not synched with each other and the master does not know who will have an answer next. My impression is that the biggest problem with MPI for this model is that with one master and many workers, it is not hard to make an application that can survive the loss of one or more workers. The master just hands out the lost work assignment again. MPI is not an ideal fit because the loss of one member of MPI_COMM_WORLD will probably bring down the job. A simple subset will not resolve this. An Fault Tolerant subset could be considered if this is an important rationale for a subset. Also, lots of people seem to like the idea of getting rid of MPI_ANY_SOURCE in a subset. I am one of these people. MPI_ANY_SOURCE is a problem. The difficulty is that the master in a master worker algorithm is likely to find MPI_ANY_SOURCE and MPI_PROBE useful. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 *

1 0

Subsetting slides for F2F meeting: please comment by EOD March 6, 2008
by unknown＠example.com 05 Mar '08

05 Mar '08

Hi everybody, Here come the promised draft slides for the subsetting presentation at the MPI Forum. I put this into our corporate template, I hope everybody is OK with this. Your comments will be most appreciated. I would like to finalize the slides on Friday, so please send your feedback by EOD your time on Thursday, March 6, 2008. Sorry for the message size. I cannot upload this file to the Wiki due to file size limitation there. I work this with Rich in background. 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. *

1 0