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

Re: [Mpi3-subsetting] Subsetting WG telecon: dates/time, proposal draft to write
by unknown＠example.com 31 Mar '08

31 Mar '08

Supalov, Alexander wrote: > Hi everybody, > > It's time for us to meet again virtually and discuss how to move > forward on the subsetting. Here's a list of dates/times that are free > in my schedule in the coming two weeks. Please let me know whether you > can make any of the following slots: > > Wednesday, April 2, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 CET > yes/no/plan B Yes > Wednesday, April 2, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B Yes > Thursday, April 3, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 > CET yes/no/plan B Yes > Wednesday, April 9, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 CET > yes/no/plan B Conflict but possibly doable > Wednesday, April 9, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B Conflict but possibly doable > Thursday, April 10, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 > CET yes/no/plan B No > > I hope that the transition to summer time is over next week, and we > can count on the usual time difference as indicated above. > > A discussion of the subsetting relation to the structure of the MPI-3 > standard is likely to come up again at the April Forum meeting, so we > better start writing something up prior to the meeting. I will put > together a first draft by early next week for starters and will ask > everybody to contribute. > > 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. > > ------------------------------------------------------------------------ > > _______________________________________________ > mpi3-subsetting mailing list > mpi3-subsetting_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting >

1 0

Re: [Mpi3-subsetting] Subsetting WG telecon: dates/time, proposal draft to write
by unknown＠example.com 31 Mar '08

31 Mar '08

Dear Alexander, On Friday 28 March 2008 17:16, Supalov, Alexander wrote: > It's time for us to meet again virtually and discuss how to move forward > on the subsetting. Here's a list of dates/times that are free in my > schedule in the coming two weeks. Please let me know whether you can > make any of the following slots: > > Wednesday, April 2, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 CET > yes/no/plan B > Wednesday, April 2, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B > Thursday, April 3, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B These would be fine. > Wednesday, April 9, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 CET > yes/no/plan B > Wednesday, April 9, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B > Thursday, April 10, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B April 10 would be plan B but doable. Thanks, 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] Subsetting WG telecon: dates/time, proposal draft to write
by unknown＠example.com 31 Mar '08

31 Mar '08

April 2nd and 3rd will not work for me. Either the 9th or the 10th WILL work for me. Thanks, Rich On 3/28/08 12:16 PM, "Supalov, Alexander" <alexander.supalov_at_[hidden]> wrote: > Hi everybody, > > It's time for us to meet again virtually and discuss how to move forward on > the subsetting. Here's a list of dates/times that are free in my schedule in > the coming two weeks. Please let me know whether you can make any of the > following slots: > > Wednesday, April 2, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 CET > yes/no/plan B > Wednesday, April 2, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B > Thursday, April 3, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B > Wednesday, April 9, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 CET > yes/no/plan B > Wednesday, April 9, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B > Thursday, April 10, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET > yes/no/plan B > > I hope that the transition to summer time is over next week, and we can count > on the usual time difference as indicated above. > > A discussion of the subsetting relation to the structure of the MPI-3 standard > is likely to come up again at the April Forum meeting, so we better start > writing something up prior to the meeting. I will put together a first draft > by early next week for starters and will ask everybody to contribute. > > 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. > > > _______________________________________________ > mpi3-subsetting mailing list > mpi3-subsetting_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting *

1 0

Re: [Mpi3-subsetting] Subsetting WG telecon: dates/time, proposal draft to write
by unknown＠example.com 31 Mar '08

31 Mar '08

On Mar 28, 2008, at 12:16 PM, Supalov, Alexander wrote: > Hi everybody, > > It's time for us to meet again virtually and discuss how to move > forward on the subsetting. Here's a list of dates/times that are > free in my schedule in the coming two weeks. Please let me know > whether you can make any of the following slots: > > Wednesday, April 2, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 > CET yes/no/plan B > Wednesday, April 2, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 > CET yes/no/plan B > Thursday, April 3, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 > CET yes/no/plan B All of the above are ok with me. > Wednesday, April 9, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 > CET yes/no/plan B Difficult for me, but do-able if necessary. > Wednesday, April 9, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 > CET yes/no/plan B I have a conflict. > Thursday, April 10, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 > CET yes/no/plan B Difficult but do-able if necessary. -- Jeff Squyres Cisco Systems

1 0

Subsetting WG telecon: dates/time, proposal draft to write
by unknown＠example.com 28 Mar '08

28 Mar '08

Hi everybody, It's time for us to meet again virtually and discuss how to move forward on the subsetting. Here's a list of dates/times that are free in my schedule in the coming two weeks. Please let me know whether you can make any of the following slots: Wednesday, April 2, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 CET yes/no/plan B Wednesday, April 2, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET yes/no/plan B Thursday, April 3, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET yes/no/plan B Wednesday, April 9, 8:00 am PDT/10:00 CDT/12:00 pm EDT/17:00 CET yes/no/plan B Wednesday, April 9, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET yes/no/plan B Thursday, April 10, 9:00 am PDT/11:00 CDT/ 1:00 pm EDT/18:00 CET yes/no/plan B I hope that the transition to summer time is over next week, and we can count on the usual time difference as indicated above. A discussion of the subsetting relation to the structure of the MPI-3 standard is likely to come up again at the April Forum meeting, so we better start writing something up prior to the meeting. I will put together a first draft by early next week for starters and will ask everybody to contribute. 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

Re: [Mpi3-subsetting] MPI3: Proposal to remove PMPI-Requirement
by unknown＠example.com 09 Mar '08

09 Mar '08

On Mar 7, 2008, at 10:20 AM, Bronis R. de Supinski wrote: >> Additionally, I'm always wary of the term "real applications" -- what >> a "real" application is to a US DOE lab is very different than what a >> "real application" is to, say, someone in the oil and gas >> industry. :-) The scale difference alone is enough to make the >> latency gains by inlining select MPI functions important (meaning: >> non- >> US-DOE-labs tend to run at [much] smaller scale; fabric latency may >> be >> constrained to a single switch, and therefore *can* see benefit from >> inlining). >> >> As I understand Rainer's proposal, the inlining aspects also >> predicated on apps that enter production and are never changed. >> Perhaps this is not a pattern used much at DOE labs, but it is a >> pattern I see with many customers. > > I'm not going to get into a pissing match with you over what > applications do what. You seem to almost be using "US DOE lab" > pejoratively. Not at all. All I'm trying to say is that there are many different types of apps out there and many different usage scenarios. What is appropriate for one kind of app run in one kind of scenario is not necessarily appropriate for another. > What I can say without the slightest hesitation > is that recompilation is often a significant barrier to tool > acceptance for application users and those users are NOT > limited to one site or even one type of site (yes, I know users > who are not at "DOE labs"). > > My opposition to changes that would force tools to require > recompilation is borne from experience. I agree with that point. I, too, have some reservations against macro- based optimizations, but I would think that if someone *chooses* to use them, they they have implicitly agreed to forego some classes of tools and other kinds of features that would be incompatible with said optimizations. -- Jeff Squyres Cisco Systems

1 0

agenda items for March 11 WG meeting?
by unknown＠example.com 08 Mar '08

08 Mar '08

Hi everybody, Please send me any agenda items you want to cover when we meet 5:45 pm - 7:15 pm on March 11. At the moment I'd propose the following: - Opens - Scope and direction of the WG - Standard modularization to better fit different application areas - 2.Performance advantages for reasonable module combinations - 3.Influence upon the overall shape of the MPI-3 standard - Discussion - 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? - PMPI: subset or not? - <add extra topics> - Next steps - Getting started on the proposal - Division of labor 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

Re: [Mpi3-subsetting] MPI3: Proposal to remove PMPI-Requirement
by unknown＠example.com 07 Mar '08

07 Mar '08

Rainer: There are two kinds of optional. In the paragraph you were responding to, I meant that the user would be explicitly required to include the profiling interface. This requirement is generally a bad idea. Recompilation is a huge barrier to tool adoption. As I have tried to make clear in my comments, requiring recompilation is not a good solution. You would have to demonstrate that the performance benefits are significant across a range of architectures and implementations to justify it. I do not believe that you can demonstrate that since most implementations would eventually make some function call. Eliminating the API level call would not provide much benefit in that case; you could instead inline everything below the API and not make anything public. That solution comes at no cost. Alternatively, linking to a non-standard library is reasonable solution for the rare case when it does make a difference (and the code is not constantly in development, as is the case for MOST large scale applications). Bronis On Fri, 7 Mar 2008, Rainer Keller wrote: > Hello Bronis, > thanks for Your comments. > > On Thursday 06 March 2008 17:58, Bronis R. de Supinski wrote: > > There are some significant problems with this proposal. > > The premise that the profiling interface is only used > > early in the development is not correct. The PMPI interface > > is useful at almost every stage of the application's life > > time. One of the things that makes it successful is that > > it is always available and does not require recompilation. > > Making it optional would destroy that. > This would not make it optional. It still is required by the standard. > However, if the user wishes to do so, he may ask the implementation to inline > functions (and on top of that specify some characterstics of his/her app). > > > > I can tell you that one of the biggest problems for OpenMP > > has been the lack of a profiling interface. We recently > > had one sanctioned by the OpenMP ARB but that took a lot > > of effort since it is very hard to add it in after the fact. > > Your proposal would not be as drastic as eliminating the > > interface but the effect would be almost as catastrophic. > Hmm, I do follow Your argument on OpenMP that is a real issue... > However fail to see, why it's so dramatic in our case (see above). > > > Perhaps just as importantly to the general need of the > > interface, the idea that inlining of MPI will provide > > substantial benefits is inaccurate. MPI is a library > > interface. Many implementations are distributed only in > > binary form; > They do provide at least one header file, now. > They could provide other header files. > They could provide obviouscated header files which call into specialized > functions, that do not check for any_source ,-] > > > > unless you are proposing link time inlining (possible but not without its > > pitfalls), > No. > > > they will not gain any benefit from this. Even if we consider only open > > source MPI implementations, the VAST majority of users do NOT > > want to compile the MPI library. The possible performance > > gain is far too small for them to take on this task. > Errr, they do not need to compile the MPI library at all? > They just > #define MPI_HINT_INLINE > #include "mpi.h" > > and the magic happens. > > > A properly designed subsetting approach will NOT try to > > partition the profiling interface into its own subset. > Yeah, that was probably the biggest misunderstanding. Please see the other > mail ,-] > > > Instead, the interface must be partitioned into different > > subsets, with each PMPI function in the same subset as the > > corresponding MPI function. > Yes. > > > Thanks, > Rainer > > > > On Wed, 5 Mar 2008, Rainer Keller wrote: > > > 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 > > > > _______________________________________________ > > mpi3-subsetting mailing list > > mpi3-subsetting_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting > > -- > ---------------------------------------------------------------- > 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: Proposal to remove PMPI-Requirement
by unknown＠example.com 07 Mar '08

07 Mar '08

Hello Bronis, the idea was not to eliminate PMPI per se. But rather allow in the standard a well-defined approach, with which function calls (due to the PMPI-requirement) can be macroized and additionally allowing the user to pass more information to the library. This should enable the compiler to do "a better job"... - The users that do not want it, do not specify the pre-processor flag and may happily use PMPI-based tools. - The users that do care, may specify it -- and depending on the implementation/hardware may see performance improvements. If the MPI-implementation does not yet process these macros, well so be it. Therefore I see this approach as the last step before deployment of an application. The proposed approach is just for discussion and by no means was meant to be solution for "the subset" -- however it may be a starting point and pre-processor based information a valid way, that goes hand-in-hand with other (MPI_Info-based?) subset-approaches... Thanks, Rainer On Friday 07 March 2008 17:20, Bronis R. de Supinski wrote: > > > A properly designed subsetting approach will NOT try to > > > partition the profiling interface into its own subset. > > > Instead, the interface must be partitioned into different > > > subsets, with each PMPI function in the same subset as the > > > corresponding MPI function. > > > > I'm not sure that I understand your rationale here (perhaps we can > > discuss more in Chicago?). > > Sure, we can discuss it in Chicago. However, The rationale is > simple enough. The user of a subset wants to be able to profile > the functionality in a given subset. > > > In my view of the world, at least one way to effect subsetting could > > be something that is dynamically loaded (or not) at run-time. Hence, > > you could have PMPI or not, depending on options given to mpirun (for > > example). I'm obviously waving my hands a bit here, but that's the > > premise I was assuming (details TBD, of course). > > I have no objection to your premise. However, this proposal > is specifically designed to prevent dynamic expansion of the > feature set to include the PMPI calls (or at least to doing > so effectively since there are no MPI calls between which > the tool could interpose). In fact, the ability to change > the subset dynamically is beyond what I was requiring (but > is desirable). All I stated was that the expansion should > not require recompilation in order to include the profiling > interface for what is included in the subset. > > If you (or anyone else) can design a mechanism that allows > using the macros that Rainer wants to enable without precluding > that interposition dynamically then I offer no opposition to > the idea. However, I would also suggest that such a mechanism > does not need any change to the standard; it is already compliant. > > > From your later mail: > > > Also, while I see your point that only a small set of > > > stuff needs to be placed into mpi.h, that does not > > > address the real question: What is the actual application > > > level benefit? Why do I care if I can get MPI_Comm_size > > > or MPI_Comm_rank inlined? Good programming practice > > > does not call them frequently enough for any performance > > > gain to matter. Alternatively, suppose I can squash some > > > stuff out of the MPI_Send call path. Will it really matter > > > to real applications? It seems unlikely, particularly > > > relative to the cost of lost flexibility for understanding > > > communication behavior and performance. > > > > Rainer's proposal came from joint discussions with NEC where (correct > > me if I'm wrong, Hubert) select functions *are* [optionally?] inlined > > in mpi.h because the cost of function calls on their platform is so > > high. > > While one can argue whether the standard should avoid precluding > the exploitation of as yet unbuilt clever hardware mechanisms, > it seems pretty clear that it is not the job of the standard to > accommodate poorly designed hardware. If the cost of function > calls is so excessively high that ONE prevents effective use of > the hardware then the vendor needs to reconsider their design. > > In any event, it appears that you are stating that a solution was > found: offer a non-compliant alternative implementation. This is > a far more appropriate solution in this case. Since I don't believe > Rainer was proposing that the PMPI interface should be optional > (just somehow not included in a base subset), the implementor > still must support it. That means no implementation effort is > saved by saying they could have a compliant implementation that > does not always support the interface (but always offers the > option to include that support). The implementor is always free > to offer non-compliant alternatives; it is up the users whether > they want to build with it. > > > Additionally, I'm always wary of the term "real applications" -- what > > a "real" application is to a US DOE lab is very different than what a > > "real application" is to, say, someone in the oil and gas > > industry. :-) The scale difference alone is enough to make the > > latency gains by inlining select MPI functions important (meaning: non- > > US-DOE-labs tend to run at [much] smaller scale; fabric latency may be > > constrained to a single switch, and therefore *can* see benefit from > > inlining). > > > > As I understand Rainer's proposal, the inlining aspects also > > predicated on apps that enter production and are never changed. > > Perhaps this is not a pattern used much at DOE labs, but it is a > > pattern I see with many customers. > > I'm not going to get into a pissing match with you over what > applications do what. You seem to almost be using "US DOE lab" > pejoratively. What I can say without the slightest hesitation > is that recompilation is often a significant barrier to tool > acceptance for application users and those users are NOT > limited to one site or even one type of site (yes, I know users > who are not at "DOE labs"). > > My opposition to changes that would force tools to require > recompilation is borne from experience. > > Bronis > _______________________________________________ > mpi3-subsetting mailing list > mpi3-subsetting_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting -- ---------------------------------------------------------------- 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: Proposal to remove PMPI-Requirement
by unknown＠example.com 07 Mar '08

07 Mar '08

Hello Bronis, thanks for Your comments. On Thursday 06 March 2008 17:58, Bronis R. de Supinski wrote: > There are some significant problems with this proposal. > The premise that the profiling interface is only used > early in the development is not correct. The PMPI interface > is useful at almost every stage of the application's life > time. One of the things that makes it successful is that > it is always available and does not require recompilation. > Making it optional would destroy that. This would not make it optional. It still is required by the standard. However, if the user wishes to do so, he may ask the implementation to inline functions (and on top of that specify some characterstics of his/her app). > I can tell you that one of the biggest problems for OpenMP > has been the lack of a profiling interface. We recently > had one sanctioned by the OpenMP ARB but that took a lot > of effort since it is very hard to add it in after the fact. > Your proposal would not be as drastic as eliminating the > interface but the effect would be almost as catastrophic. Hmm, I do follow Your argument on OpenMP that is a real issue... However fail to see, why it's so dramatic in our case (see above). > Perhaps just as importantly to the general need of the > interface, the idea that inlining of MPI will provide > substantial benefits is inaccurate. MPI is a library > interface. Many implementations are distributed only in > binary form; They do provide at least one header file, now. They could provide other header files. They could provide obviouscated header files which call into specialized functions, that do not check for any_source ,-] > unless you are proposing link time inlining (possible but not without its > pitfalls), No. > they will not gain any benefit from this. Even if we consider only open > source MPI implementations, the VAST majority of users do NOT > want to compile the MPI library. The possible performance > gain is far too small for them to take on this task. Errr, they do not need to compile the MPI library at all? They just #define MPI_HINT_INLINE #include "mpi.h" and the magic happens. > A properly designed subsetting approach will NOT try to > partition the profiling interface into its own subset. Yeah, that was probably the biggest misunderstanding. Please see the other mail ,-] > Instead, the interface must be partitioned into different > subsets, with each PMPI function in the same subset as the > corresponding MPI function. Yes. Thanks, Rainer > On Wed, 5 Mar 2008, Rainer Keller wrote: > > 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 > > _______________________________________________ > mpi3-subsetting mailing list > mpi3-subsetting_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting -- ---------------------------------------------------------------- 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