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

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

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

07 Mar '08

Jeff: Re: [snip] > > 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

1 0

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

07 Mar '08

On Mar 6, 2008, at 11:58 AM, 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. I'm sure that that is true for some apps. But there are also wide classes of apps where Rainer's statements *are* true (that PMPI is only used in the development lifecycle, which is relatively short compared to the apps' production lifetime). > 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?). 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). 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. 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. -- Jeff Squyres Cisco Systems

1 0

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

06 Mar '08

Dries: While the question of an ABI is also important, it does not really address the primary reason that recompiling is bad. My issue is not that the applications have to be compiled the first time. It is that recompiling to use the profiling interface is an excessively high barrier for many applications. 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. Bronis On Thu, 6 Mar 2008, Dries Kimpe wrote: > > * Bronis R. de Supinski <bronis_at_[hidden]> [2008-03-06 08:58:37]: > > > 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; unless you are proposing link time inlining > > (possible but not without its pitfalls), 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. > > This might not be completely true. Since there is no ABI right now, every > MPI application needs to be recompiled before it can be used. Even though > the MPI library might be compiled already, the C header will contain > inline functions (they need to be in the header to have an effect) and > will thus be inlined into the application. The MPI library itself can > choose how far it goes with this inlining. (For example, all of MPI_Send > / MPI_Recv could be inlined if it wishes to do so). > > So it is NOT needed to recompile the MPI library, only the functions that > are part of mpi.h (and any headers it might include) will be recompiled, > and this is transparent to the application. > > The real issue is that an ABI and inline functions are not compatible, > unless the implementation of the inlined functions themselves is > considered part of the ABI. (this means all of the structures they use, > all of the functions they call, ...) > > Dries > >

1 0

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

06 Mar '08

* Bronis R. de Supinski <bronis_at_[hidden]> [2008-03-06 08:58:37]: > 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; unless you are proposing link time inlining > (possible but not without its pitfalls), 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. This might not be completely true. Since there is no ABI right now, every MPI application needs to be recompiled before it can be used. Even though the MPI library might be compiled already, the C header will contain inline functions (they need to be in the header to have an effect) and will thus be inlined into the application. The MPI library itself can choose how far it goes with this inlining. (For example, all of MPI_Send / MPI_Recv could be inlined if it wishes to do so). So it is NOT needed to recompile the MPI library, only the functions that are part of mpi.h (and any headers it might include) will be recompiled, and this is transparent to the application. The real issue is that an ABI and inline functions are not compatible, unless the implementation of the inlined functions themselves is considered part of the ABI. (this means all of the structures they use, all of the functions they call, ...) Dries *

1 0

Re: [Mpi3-subsetting] Subsetting slides for F2F meeting: please comment by EOD March 6, 2008
by unknown＠example.com 06 Mar '08

06 Mar '08

Wiki updated accordingly. ________________________________ From: Supalov, Alexander Sent: Thursday, March 06, 2008 5:17 PM To: 'MPI 3.0 Sub-setting working group' Subject: RE: [Mpi3-subsetting] Subsetting slides for F2F meeting: please comment by EOD March 6, 2008 Thanks. Details inside. ________________________________ From: mpi3-subsetting-bounces_at_[hidden] [mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of Richard Graham Sent: Thursday, March 06, 2008 4:57 PM To: MPI 3.0 Sub-setting working group Subject: Re: [Mpi3-subsetting] Subsetting slides for F2F meeting: please comment by EOD March 6, 2008 Thanks a lot for taking on the task of herding cats. Here are some comments: - Growing complexity does not have to mean worse performance. It really depends on where the complexity resides. I'll restore "may" here. - We have not at all agreed to formal recognition of optional parts of the standard. As a matter of fact, on the call there were more opinions expressed in favor of use of a subset in a certain instant, not optional sections. We may at the end conclude that for some features optional is the best way, but have not gone there yet. OK, I'll turn this into suggestion or drop it. - Optimization potential: don't get into too much detail. I am not convinced that all that is listed there is actually correct - implementation can do (and do) a lot to eliminate some of the things listed in the bulleted list. I'll consider this. - What did you have in mind with "mutually incompatible families" ? Several stable combinations of subsets may emerge that will cover different application areas well, but they (the subsets) will be mutually incompatible between each other. Rich On 3/6/08 10:27 AM, "Supalov, Alexander" <alexander.supalov_at_[hidden]> wrote: Hi everybody, Thanks for your comments. Now the slides are also in the Wiki, see http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/SubsettingWi kiPage/MPI-3%20subsetting.ppt . Note that I'm going to incorporate your feedback and remove the backup in the final version - we'll only have 5 minutes to present the WG results to the Forum. Best regards. Alexander ________________________________ From: Supalov, Alexander Sent: Wednesday, March 05, 2008 3:38 PM To: 'mpi3-subsetting_at_[hidden]' Subject: Subsetting slides for F2F meeting: please comment by EOD March 6, 2008 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. ________________________________ _______________________________________________ mpi3-subsetting mailing list mpi3-subsetting_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting --------------------------------------------------------------------- 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 06 Mar '08

06 Mar '08

Rainer: 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. 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. 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; unless you are proposing link time inlining (possible but not without its pitfalls), 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. 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. Bronis 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 >

1 0

Re: [Mpi3-subsetting] Subsetting slides for F2F meeting: please comment by EOD March 6, 2008
by unknown＠example.com 06 Mar '08

06 Mar '08

Thanks. Details inside. ________________________________ From: mpi3-subsetting-bounces_at_[hidden] [mailto:mpi3-subsetting-bounces_at_[hidden]] On Behalf Of Richard Graham Sent: Thursday, March 06, 2008 4:57 PM To: MPI 3.0 Sub-setting working group Subject: Re: [Mpi3-subsetting] Subsetting slides for F2F meeting: please comment by EOD March 6, 2008 Thanks a lot for taking on the task of herding cats. Here are some comments: - Growing complexity does not have to mean worse performance. It really depends on where the complexity resides. I'll restore "may" here. - We have not at all agreed to formal recognition of optional parts of the standard. As a matter of fact, on the call there were more opinions expressed in favor of use of a subset in a certain instant, not optional sections. We may at the end conclude that for some features optional is the best way, but have not gone there yet. OK, I'll turn this into suggestion or drop it. - Optimization potential: don't get into too much detail. I am not convinced that all that is listed there is actually correct - implementation can do (and do) a lot to eliminate some of the things listed in the bulleted list. I'll consider this. - What did you have in mind with "mutually incompatible families" ? Several stable combinations of subsets may emerge that will cover different application areas well, but they (the subsets) will be mutually incompatible between each other. Rich On 3/6/08 10:27 AM, "Supalov, Alexander" <alexander.supalov_at_[hidden]> wrote: Hi everybody, Thanks for your comments. Now the slides are also in the Wiki, see http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/SubsettingWi kiPage/MPI-3%20subsetting.ppt . Note that I'm going to incorporate your feedback and remove the backup in the final version - we'll only have 5 minutes to present the WG results to the Forum. Best regards. Alexander ________________________________ From: Supalov, Alexander Sent: Wednesday, March 05, 2008 3:38 PM To: 'mpi3-subsetting_at_[hidden]' Subject: Subsetting slides for F2F meeting: please comment by EOD March 6, 2008 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. ________________________________ _______________________________________________ mpi3-subsetting mailing list mpi3-subsetting_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting --------------------------------------------------------------------- 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] Subsetting slides for F2F meeting: please comment by EOD March 6, 2008
by unknown＠example.com 06 Mar '08

06 Mar '08

Thanks a lot for taking on the task of herding cats. Here are some comments: - Growing complexity does not have to mean worse performance. It really depends on where the complexity resides. - We have not at all agreed to formal recognition of optional parts of the standard. As a matter of fact, on the call there were more opinions expressed in favor of use of a subset in a certain instant, not optional sections. We may at the end conclude that for some features optional is the best way, but have not gone there yet. - Optimization potential: don¹t get into too much detail. I am not convinced that all that is listed there is actually correct  implementation can do (and do) a lot to eliminate some of the things listed in the bulleted list. - What did you have in mind with ³mutually incompatible families² ? Rich On 3/6/08 10:27 AM, "Supalov, Alexander" <alexander.supalov_at_[hidden]> wrote: > Hi everybody, > > Thanks for your comments. Now the slides are also in the Wiki, see > http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/SubsettingWikiP… > /MPI-3%20subsetting.ppt . > > Note that I'm going to incorporate your feedback and remove the backup in the > final version - we'll only have 5 minutes to present the WG results to the > Forum. > > Best regards. > > Alexander > > > From: Supalov, Alexander > Sent: Wednesday, March 05, 2008 3:38 PM > To: 'mpi3-subsetting_at_[hidden]' > Subject: Subsetting slides for F2F meeting: please comment by EOD March 6, > 2008 > > 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. > > > _______________________________________________ > mpi3-subsetting mailing list > mpi3-subsetting_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-subsetting *

1 0

Re: [Mpi3-subsetting] Subsetting slides for F2F meeting: please comment by EOD March 6, 2008
by unknown＠example.com 06 Mar '08

06 Mar '08

Hi everybody, Thanks for your comments. Now the slides are also in the Wiki, see http://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/SubsettingWi kiPage/MPI-3%20subsetting.ppt . Note that I'm going to incorporate your feedback and remove the backup in the final version - we'll only have 5 minutes to present the WG results to the Forum. Best regards. Alexander ________________________________ From: Supalov, Alexander Sent: Wednesday, March 05, 2008 3:38 PM To: 'mpi3-subsetting_at_[hidden]' Subject: Subsetting slides for F2F meeting: please comment by EOD March 6, 2008 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