May 2008 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] MPI_INIT assertions
by unknown＠example.com 06 May '08

06 May '08

In my view, each assertion we define in the standard should be justified by a good explanation of how it allows an MPI implementation to be more efficient and what cost/risk it adds In effect, a cost/benefit analysis. No plausible rationale - no assertion. An assertion is a statement about the application. It is not a request for libmpi to "provide something". In my proposal, an application that correctly uses some assertion must still be written to work on an MPI implementation that ignores that assertion. An application that incorrectly uses some assertion can fail or give wrong answers. You can picture an assertion as the application author granting libmpi permission to "NOT provide something" at the MPI implementors discretion. In MPI 2 we maintained a careful distinction between hints and assertions. The MPI implementation is not allowed to give wrong results or error messages when an application provides an incorrect hint. If an application could provide a hint that it would not use MPI_CANCEL on a particular communicator and then called MPI_CANCEL, it would be OK for libmpi to use a really slow CANCEL protocol but not OK for it to issue a fatal error or ignore the CANCEL. That means that the freedom to "exploit" a hint in libmpi is very limited and less care is required of the user in providing hints. Much of what is being proposed should be treated as hints and could use a different and extensible mechanism. We can consider extending the MPI_Info usage in MPI-3 to address information passing that is hint-like. The MPI standard intends applications to be platform agnostic and source level portable and we should not break that. An assertions interface for making statements about the application will not limit this kind of portability. If there are no MPI_CANCEL calls today, there are no MPI_CANCEL calls after recompilation for a new platform. If we add features for platform tuning (like how many tasks per node or eager threshhold) we could damage portability. In my first outline, I threw in MPI-IO and MPI-1SC without any rationale for how they are useful. You added: "No communicator & group management", "No non-blocking communication", "No message tagging" and "No derived datatypes". It is not clear to me they are all useful so a decent rationale would be needed for each. That makes 6 bits that may be free. The thread support level parameter in MPI_INIT_THREAD is a request to the MPI library to provide some level of thread support and I question how cleanly that maps into the "assertions" model. The assertions model may only require one bit for "MPI_NO_THREAD_CONTENTION". That frees 3 more of the bits you suggest are already taken. If we conclude that all 4 thread support options are really useful it may be best to add the assertions flag to MPI_INIT_THREAD and keep the thread support controls as they are. Even the MPI_NO_THREAD_CONTENTION bit frees up then. My original thought was that we would add a new function that adds a parameter to MPI_INIT_THREAD. I am convinced that the number of assertions defined by the MPI standard should be very limited because each brings some risk and complicates life for library writers. If we end up with as many as 32 assertions I will apologize for having offered the idea in the first place and probably advocate a no vote. If MPI 2.2 provided only MPI_NO_EAGER_THROTTLE, MPI_NO_SEND_CANCEL, MPI_NO_REQUEST_MIX, MPI_NO_ANY_SOURCE and MPI_NO_REDUCTION_ORDER I would be content and debate about adding more could wait for MPI 3.0. The assertion that the application does not try to match persistent send/recv with nonpersistent recv/send would be a nice 2.2 bonus. That accounts for 6 bits. The query function could be something as simple as: MPI_Query_assertions(int *stated, int *exploited) The author of libfred could code in his Init_fred routine: int stated_by_app, exploited_by_lib; MPI_Query_assertions( &stated_by_app, &exploited_by_lib) if (exploited_by_lib & MPI_NO_SEND_CANCEL) fatal_error("Assertion MPI_NO_SEND_CANCEL is not compatable with Fred Lib") else if (stated_by_app & MPI_NO_SEND_CANCEL) warn("Assertion MPI_NO_SEND_CANCEL is not compatable with Fred Lib. It is not exploited by your MPI but your application will not port to an MPI that does exploit MPI_NO_SEND_CANCEL"); If Fred is really cautious he can code If (stated_by_app != 0) fatal_error("Fred does not like assertions") and see if anybody asks for some assertion to be tolerated in the next release of FredLib. You mention "No eager buffering" which is different than what I proposed and is not logically an "assertion". MPI applications should not depend semantically on eager buffering today and the standard is clear that a MPI implementation which has no eager buffering can still be 100% compliant. The standard requires that IF an MPI implementation provides an eager protocol as a performance enhancement, it must also provide a safety feature which can be expensive. Many (perhaps most) applications can benefit from an eager protocol but do not need the safety feature because the application is self regulating. These applications could assert: "I do not require the safety feature." which would allow them the benefit of eager protocol without the costs of the safety feature. I can see a rationale for some kind of hints related to eager protocol buffer space and threshhold. There are many other kinds of granular "hint" support that may be useful but all that should be kept distinct from this proposal (In my opinion). Regards - 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 mpi-22-bounces_at_[hidden] wrote on 05/06/2008 07:26:03 AM: > Dear Dick, > > Thanks. What about passing more verbose information to and from an > MPI implementation? Say, eager threshold value, if it's meaningful? > There are many less controversial examples, for example, to let the > caller know how many processes are placed onto the node, etc. Simple > assertions won't work in this case. > > Back to assertions. I thought we might consider > MPI_Initialized_subset(*flag,required,*provided) or something. > Setting "required" to 0 would return the set of provided assertions > in "provided". Setting "required" to something else will also set > the "flag" to true or false, depending on whether there's a match. > > The special MPI_Init_subset(*argc,***argv,required,*provided) would > complement this. > > Regarding 32 bits, let's count (I'm taking the joint list from the > subset proposal that includes your earlier points): > > 0,1,2,3 - MPI_THREAD_SINGLE, FUNNELED, SERIALIZED, MULTIPLE > 0x00000004 - No dynamic process support > 0x00000008 - No file I/O > 0x00000010 - No one-sided ops > 0x00000020 - No communicator & group management > 0x00000040 - No non-blocking communication > 0x00000080 - No message cancellation > 0x00000100 - Persistent ops on both sides > 0x00000200 - No heterogeneity > 0x00000400 - No derived datatypes (especially those with holes) > 0x00000800 - No MPI_ANY_SOURCE > 0x00001000 - No message tagging > 0x00002000 - No reduction order > 0x00004000 - No eager buffering > 0x00008000 - No mixed request types in wait/test > > We have 16 bits left. Note that there may be some predefined masks > for well defined combinations of the above (e.g., MPI-1 = no dynamic > processes, no file I/O, no threads, etc.). > > Best regards. > > Alexander > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > bounces_at_[hidden]] On Behalf Of Richard Treumann > Sent: Monday, May 05, 2008 11:53 PM > To: MPI 2.2 > Subject: [Mpi-22] MPI_INIT assertions > I changed the subject to be meaningful - it had been "Re: [Mpi-22] > mpi-22 Digest, Vol 2, Issue 7" > > I do think this proposal is within the scope of the MPI 2.2 rules so > I am pleased to hear this is being considered. > > I am 100% convinced that a query function should be part of this > proposal, probably with 2 query flavors. One flavor of the query > would respond with the set of assertions the application > MPI_INIT_xxx call had provided and another would respond with the > set of assertions the MPI implementation is actually exploiting. > > One library author may decide he will use if/else logic based on how > the MPI implementation will behave. The application may assert > MPI_NO_yyy but if the MPI implementation does not exploit MPI_NO_yyy > then the library can still use the code that depends on yyy. Another > library author may depend unconditionally on yyy. On an MPI > implementation that does not exploit MPI_NO_yyy he may want to issue > a warning that assertion MPI_NO_yyy is non-portable but let the job > run. On one that does exploit MPI_NO_yyy he would abort the job. Or, > he may decide to simply abort any job that asserts MPI_NO_yyy to > avoid having the library suddenly quit working when the customer > upgrades to an MPI implementation that does exploit MPI_NO_yyy. > > I think 32 assertions is probably more than enough > > Even a handful of defined assertions can raise testing costs. For > simple cases like MPI_NO_ANY_SOURCE it is easy for a user to judge > whether a piece of code is OK but if we begin to add subtle or > narrow semantic assertions it gets harder. Some library providers > will be tempted to say "I cannot proof read and test my code to a > degree that will allow me to accept 28 specific assertions and > forbid 4. I will simply forbid every subtle assertion I cannot > afford to test." > > I predict that for large applications developed by teams and for > community open source efforts the design leads will consider > requiring that all parts be written to live within a few carefully > chosen assertions. The design leads will not want to provide a list > of 26 subtle or narrow assertions and require that everyone respect > all 26 in the code they contribute. > > Many distinct assertions also could become a big test cost for MPI > implementors and customers who must qualify an MPI implementation > before trusting their business to it. If there were 64 or more > assertions, how would a tester decide what combinations of > assertions must be tested and then create suitable test cases? > > 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 > > > mpi-22-bounces_at_[hidden] wrote on 05/05/2008 01:28:06 PM: > > > Dear Dick, > > > > Thank you. We can actually introduce what you propose, possibly with > > a query function to make it still easier to live with, as early as > > in MPI 2.2, as a subset precursor. Judging by the discussion in > > Chicago, subsets may not need much more than that in the end, > > possibly with a little more flags and semantics added in MPI-3. > > > > The reservation against 32- (or for that matter, 64-) bit limitation > > is the only one I have at the moment. Not being able to attach > > assertions to communicators, etc. may be missed by some advanced > > programmers, but here we need to be pragmatic: who will ever want to > > go that deep? > > > > Best regards. > > > > Alexander > > > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > > bounces_at_[hidden]] On Behalf Of Richard Treumann > > Sent: Monday, May 05, 2008 7:18 PM > > To: MPI 2.2 > > Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > > > Hi Alexander > > > > I have no objection to citing my "assertions" proposal in the > > subsetting discussions. I do want to keep it clear that this > > proposal is intended to be as simple as practical to implement, exploit and > > live with. > > > > "Live with" applies to 3rd party library authors or anyone else who > > must write MPI code but does not know and control the structure of > > the entire application. That guy must "live with" the decisions made > > by whoever coded the MPI_INIT piece. "Live with" also applies to > > whoever must test or certify a specific MPI implementation. > > > > Thanks - 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 > > > > [image removed] "Supalov, Alexander" <alexander.supalov_at_[hidden]> > > > > > > > "Supalov, Alexander" <alexander.supalov_at_[hidden]> > > Sent by: mpi-22-bounces_at_[hidden] > > 04/26/2008 04:03 AM > > > > Please respond to > > "MPI 2.2" <mpi-22_at_[hidden]> > > > > [image removed] > > To > > > > [image removed] > > "MPI 2.2" <mpi-22_at_[hidden]> > > > > [image removed] > > cc > > > > [image removed] > > > > [image removed] > > Subject > > > > [image removed] > > Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > > > > [image removed] > > > > [image removed] > > > > > > Dear Dick, > > > > Thank you. Would you mind if I cite your proposal in the subsets > > discussion? Yours looks like a good alternative to the thinking of > > some of us that subsets might be very rich and mutable, and to > > Jeff's proposal on hints I've already cited there with his permission. > > > > Best regards. > > > > Alexander > > > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > > bounces_at_[hidden]] On Behalf Of Richard Treumann > > Sent: Thursday, April 24, 2008 6:16 PM > > To: MPI 2.2 > > Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > > 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 > > > > > > mpi-22-bounces_at_[hidden] wrote on 04/24/2008 11:33:42 AM: > > > > > Hi, > > > > > > Note that this is an argument for making the assertions optional: those > > > who don't care don't have to use them. Those who care should use them > > > correctly or else. As usual. > > > > > > Best regards. > > > > > > Alexander > > > > > > > Hi Alexander > > > > The assertions are optional in this proposal. If this is added to > > the MPI standard the minimal impacts (day one impacts) are: > > > > == > > To application writers (none) - MPI_INIT and MPI_INIT_THREAD still > > work. MPI_INIT_THREAD_xxx can be > > passed 0 (zero) as the assertions bit vector. > > > > To MPI Implementors (small) - subroutine MPI_INIT_THREAD_xxx can be > > a clone of MPI_INIT_THREAD under the covers. If the Forum decides > > the query function is for asking what assertions are being honored, > > the implementation can just return "none" to every query. If there > > is also a query for what assertions have been made then there are a > > few more lines of code the implementor must write to preserve the > > value so it can be returned(maybe 10 lines) > > > > Writers of opaque libraries (small) - call the query function at > > library init time and if any assertions are found, issue an error > > message and kill the job. This is awkward for a library that wants > > to support every MPI whether it has implemented the new query > function or not. > > == > > > > As MPI implementations begin to take advantage of assertions there > > is more work for the MPI implementor and the library author must > > begin to think about whether his customer will be upset if the > > library simply outlaws all assertions. > > > > The library author will never be wrong if he simply forbids > > assertions forever. If they become valuable he will feel the > > pressure to work it out. > > > > The MPI implementor will never be wrong if he adds the API but > > simply ignores assertions forever. If they become valuable he will > > feel the pressure to honor some at least. > > --------------------------------------------------------------------- > > 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. > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > --------------------------------------------------------------------- > > 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. > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > 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. > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Re: [Mpi-22] Call for MPI 2.2 agenda items
by unknown＠example.com 06 May '08

06 May '08

Hi, May be we add a couple of calls to pass data back and forth between the client and MPI? Either assertions proposed by Dick Treumann, or more extensible (MPI_Info based?) approach proposed by Jeff Squyres? That's admittedly connected to subsets, but this is only an addition, no backward incompatible change. MPI 2.2? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rajeev Thakur Sent: Monday, May 05, 2008 10:36 PM To: mpi-forum_at_[hidden]; mpi-22_at_[hidden] Subject: [Mpi-22] Call for MPI 2.2 agenda items Now that MPI 2.1 is close to completion, it is time to look at issues for MPI 2.2. Please send any items you may have for 2.2 to mpi-22_at_[hidden] and/or upload them to the wiki (and let us know). I had made a note of the following items from the last meeting that were deferred to 2.2: * support for long long in maxloc, minloc * fix meaning of first two sentences in intercommunicator barrier * Ex 5.8 uses old style MPI_UB * Many functions say "integer" instead of "nonnegative integer" * const in C++ bindings * IN, OUT, and INOUT handle types broken * MPI_CHAR, MPI::CHAR should be signed char or char? * Need 64-bit sizes for count in messages * Sizes of MPI_Aint and MPI_Offset should not be different * New predefined types MPI_AINT and MPI_OFFSET * New predefined types corresponding to new types in C99, Fortran 2003, and C++ some year _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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: [Mpi-22] MPI_INIT assertions
by unknown＠example.com 06 May '08

06 May '08

Dear Dick, Thanks. What about passing more verbose information to and from an MPI implementation? Say, eager threshold value, if it's meaningful? There are many less controversial examples, for example, to let the caller know how many processes are placed onto the node, etc. Simple assertions won't work in this case. Back to assertions. I thought we might consider MPI_Initialized_subset(*flag,required,*provided) or something. Setting "required" to 0 would return the set of provided assertions in "provided". Setting "required" to something else will also set the "flag" to true or false, depending on whether there's a match. The special MPI_Init_subset(*argc,***argv,required,*provided) would complement this. Regarding 32 bits, let's count (I'm taking the joint list from the subset proposal that includes your earlier points): 0,1,2,3 - MPI_THREAD_SINGLE, FUNNELED, SERIALIZED, MULTIPLE 0x00000004 - No dynamic process support 0x00000008 - No file I/O 0x00000010 - No one-sided ops 0x00000020 - No communicator & group management 0x00000040 - No non-blocking communication 0x00000080 - No message cancellation 0x00000100 - Persistent ops on both sides 0x00000200 - No heterogeneity 0x00000400 - No derived datatypes (especially those with holes) 0x00000800 - No MPI_ANY_SOURCE 0x00001000 - No message tagging 0x00002000 - No reduction order 0x00004000 - No eager buffering 0x00008000 - No mixed request types in wait/test We have 16 bits left. Note that there may be some predefined masks for well defined combinations of the above (e.g., MPI-1 = no dynamic processes, no file I/O, no threads, etc.). Best regards. Alexander ________________________________ From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: Monday, May 05, 2008 11:53 PM To: MPI 2.2 Subject: [Mpi-22] MPI_INIT assertions I changed the subject to be meaningful - it had been "Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7" I do think this proposal is within the scope of the MPI 2.2 rules so I am pleased to hear this is being considered. I am 100% convinced that a query function should be part of this proposal, probably with 2 query flavors. One flavor of the query would respond with the set of assertions the application MPI_INIT_xxx call had provided and another would respond with the set of assertions the MPI implementation is actually exploiting. One library author may decide he will use if/else logic based on how the MPI implementation will behave. The application may assert MPI_NO_yyy but if the MPI implementation does not exploit MPI_NO_yyy then the library can still use the code that depends on yyy. Another library author may depend unconditionally on yyy. On an MPI implementation that does not exploit MPI_NO_yyy he may want to issue a warning that assertion MPI_NO_yyy is non-portable but let the job run. On one that does exploit MPI_NO_yyy he would abort the job. Or, he may decide to simply abort any job that asserts MPI_NO_yyy to avoid having the library suddenly quit working when the customer upgrades to an MPI implementation that does exploit MPI_NO_yyy. I think 32 assertions is probably more than enough Even a handful of defined assertions can raise testing costs. For simple cases like MPI_NO_ANY_SOURCE it is easy for a user to judge whether a piece of code is OK but if we begin to add subtle or narrow semantic assertions it gets harder. Some library providers will be tempted to say "I cannot proof read and test my code to a degree that will allow me to accept 28 specific assertions and forbid 4. I will simply forbid every subtle assertion I cannot afford to test." I predict that for large applications developed by teams and for community open source efforts the design leads will consider requiring that all parts be written to live within a few carefully chosen assertions. The design leads will not want to provide a list of 26 subtle or narrow assertions and require that everyone respect all 26 in the code they contribute. Many distinct assertions also could become a big test cost for MPI implementors and customers who must qualify an MPI implementation before trusting their business to it. If there were 64 or more assertions, how would a tester decide what combinations of assertions must be tested and then create suitable test cases? 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 mpi-22-bounces_at_[hidden] wrote on 05/05/2008 01:28:06 PM: > Dear Dick, > > Thank you. We can actually introduce what you propose, possibly with > a query function to make it still easier to live with, as early as > in MPI 2.2, as a subset precursor. Judging by the discussion in > Chicago, subsets may not need much more than that in the end, > possibly with a little more flags and semantics added in MPI-3. > > The reservation against 32- (or for that matter, 64-) bit limitation > is the only one I have at the moment. Not being able to attach > assertions to communicators, etc. may be missed by some advanced > programmers, but here we need to be pragmatic: who will ever want to > go that deep? > > Best regards. > > Alexander > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > bounces_at_[hidden]] On Behalf Of Richard Treumann > Sent: Monday, May 05, 2008 7:18 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > Hi Alexander > > I have no objection to citing my "assertions" proposal in the > subsetting discussions. I do want to keep it clear that this > proposal is intended to be as simple as practical to implement, exploit and > live with. > > "Live with" applies to 3rd party library authors or anyone else who > must write MPI code but does not know and control the structure of > the entire application. That guy must "live with" the decisions made > by whoever coded the MPI_INIT piece. "Live with" also applies to > whoever must test or certify a specific MPI implementation. > > Thanks - 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 > > [image removed] "Supalov, Alexander" <alexander.supalov_at_[hidden]> > > > "Supalov, Alexander" <alexander.supalov_at_[hidden]> > Sent by: mpi-22-bounces_at_[hidden] > 04/26/2008 04:03 AM > > Please respond to > "MPI 2.2" <mpi-22_at_[hidden]> > > [image removed] > To > > [image removed] > "MPI 2.2" <mpi-22_at_[hidden]> > > [image removed] > cc > > [image removed] > > [image removed] > Subject > > [image removed] > Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > > [image removed] > > [image removed] > > > Dear Dick, > > Thank you. Would you mind if I cite your proposal in the subsets > discussion? Yours looks like a good alternative to the thinking of > some of us that subsets might be very rich and mutable, and to > Jeff's proposal on hints I've already cited there with his permission. > > Best regards. > > Alexander > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > bounces_at_[hidden]] On Behalf Of Richard Treumann > Sent: Thursday, April 24, 2008 6:16 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > 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 > > > mpi-22-bounces_at_[hidden] wrote on 04/24/2008 11:33:42 AM: > > > Hi, > > > > Note that this is an argument for making the assertions optional: those > > who don't care don't have to use them. Those who care should use them > > correctly or else. As usual. > > > > Best regards. > > > > Alexander > > > > Hi Alexander > > The assertions are optional in this proposal. If this is added to > the MPI standard the minimal impacts (day one impacts) are: > > == > To application writers (none) - MPI_INIT and MPI_INIT_THREAD still > work. MPI_INIT_THREAD_xxx can be > passed 0 (zero) as the assertions bit vector. > > To MPI Implementors (small) - subroutine MPI_INIT_THREAD_xxx can be > a clone of MPI_INIT_THREAD under the covers. If the Forum decides > the query function is for asking what assertions are being honored, > the implementation can just return "none" to every query. If there > is also a query for what assertions have been made then there are a > few more lines of code the implementor must write to preserve the > value so it can be returned(maybe 10 lines) > > Writers of opaque libraries (small) - call the query function at > library init time and if any assertions are found, issue an error > message and kill the job. This is awkward for a library that wants > to support every MPI whether it has implemented the new query function or not. > == > > As MPI implementations begin to take advantage of assertions there > is more work for the MPI implementor and the library author must > begin to think about whether his customer will be upset if the > library simply outlaws all assertions. > > The library author will never be wrong if he simply forbids > assertions forever. If they become valuable he will feel the > pressure to work it out. > > The MPI implementor will never be wrong if he adds the API but > simply ignores assertions forever. If they become valuable he will > feel the pressure to honor some at least. > --------------------------------------------------------------------- > 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. > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > 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. > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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: [Mpi-22] Call for MPI 2.2 agenda items
by unknown＠example.com 05 May '08

05 May '08

* Rajeev Thakur <thakur_at_[hidden]> [2008-05-05 15:36:01]: > * MPI_CHAR, MPI::CHAR should be signed char or char? In C and C++, char, signed char and unsigned char are all distinct types. (And in C++, wchar_t is yet another type; In C it is a typedef and thus not a new type but an alias) Char can either be signed or unsigned and this is platform/compiler dependent. So MPI_CHAR and MPI::CHAR should be whatever the compiler/platform thinks and cannot be fixed in the standard to be signed or unsigned. Dries *

1 0

MPI_INIT assertions
by unknown＠example.com 05 May '08

05 May '08

I changed the subject to be meaningful - it had been "Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7" I do think this proposal is within the scope of the MPI 2.2 rules so I am pleased to hear this is being considered. I am 100% convinced that a query function should be part of this proposal, probably with 2 query flavors. One flavor of the query would respond with the set of assertions the application MPI_INIT_xxx call had provided and another would respond with the set of assertions the MPI implementation is actually exploiting. One library author may decide he will use if/else logic based on how the MPI implementation will behave. The application may assert MPI_NO_yyy but if the MPI implementation does not exploit MPI_NO_yyy then the library can still use the code that depends on yyy. Another library author may depend unconditionally on yyy. On an MPI implementation that does not exploit MPI_NO_yyy he may want to issue a warning that assertion MPI_NO_yyy is non-portable but let the job run. On one that does exploit MPI_NO_yyy he would abort the job. Or, he may decide to simply abort any job that asserts MPI_NO_yyy to avoid having the library suddenly quit working when the customer upgrades to an MPI implementation that does exploit MPI_NO_yyy. I think 32 assertions is probably more than enough Even a handful of defined assertions can raise testing costs. For simple cases like MPI_NO_ANY_SOURCE it is easy for a user to judge whether a piece of code is OK but if we begin to add subtle or narrow semantic assertions it gets harder. Some library providers will be tempted to say "I cannot proof read and test my code to a degree that will allow me to accept 28 specific assertions and forbid 4. I will simply forbid every subtle assertion I cannot afford to test." I predict that for large applications developed by teams and for community open source efforts the design leads will consider requiring that all parts be written to live within a few carefully chosen assertions. The design leads will not want to provide a list of 26 subtle or narrow assertions and require that everyone respect all 26 in the code they contribute. Many distinct assertions also could become a big test cost for MPI implementors and customers who must qualify an MPI implementation before trusting their business to it. If there were 64 or more assertions, how would a tester decide what combinations of assertions must be tested and then create suitable test cases? 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 mpi-22-bounces_at_[hidden] wrote on 05/05/2008 01:28:06 PM: > Dear Dick, > > Thank you. We can actually introduce what you propose, possibly with > a query function to make it still easier to live with, as early as > in MPI 2.2, as a subset precursor. Judging by the discussion in > Chicago, subsets may not need much more than that in the end, > possibly with a little more flags and semantics added in MPI-3. > > The reservation against 32- (or for that matter, 64-) bit limitation > is the only one I have at the moment. Not being able to attach > assertions to communicators, etc. may be missed by some advanced > programmers, but here we need to be pragmatic: who will ever want to > go that deep? > > Best regards. > > Alexander > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > bounces_at_[hidden]] On Behalf Of Richard Treumann > Sent: Monday, May 05, 2008 7:18 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > Hi Alexander > > I have no objection to citing my "assertions" proposal in the > subsetting discussions. I do want to keep it clear that this > proposal is intended to be as simple as practical to implement, exploit and > live with. > > "Live with" applies to 3rd party library authors or anyone else who > must write MPI code but does not know and control the structure of > the entire application. That guy must "live with" the decisions made > by whoever coded the MPI_INIT piece. "Live with" also applies to > whoever must test or certify a specific MPI implementation. > > Thanks - 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 > > [image removed] "Supalov, Alexander" <alexander.supalov_at_[hidden]> > > > "Supalov, Alexander" <alexander.supalov_at_[hidden]> > Sent by: mpi-22-bounces_at_[hidden] > 04/26/2008 04:03 AM > > Please respond to > "MPI 2.2" <mpi-22_at_[hidden]> > > [image removed] > To > > [image removed] > "MPI 2.2" <mpi-22_at_[hidden]> > > [image removed] > cc > > [image removed] > > [image removed] > Subject > > [image removed] > Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > > [image removed] > > [image removed] > > > Dear Dick, > > Thank you. Would you mind if I cite your proposal in the subsets > discussion? Yours looks like a good alternative to the thinking of > some of us that subsets might be very rich and mutable, and to > Jeff's proposal on hints I've already cited there with his permission. > > Best regards. > > Alexander > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > bounces_at_[hidden]] On Behalf Of Richard Treumann > Sent: Thursday, April 24, 2008 6:16 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 > 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 > > > mpi-22-bounces_at_[hidden] wrote on 04/24/2008 11:33:42 AM: > > > Hi, > > > > Note that this is an argument for making the assertions optional: those > > who don't care don't have to use them. Those who care should use them > > correctly or else. As usual. > > > > Best regards. > > > > Alexander > > > > Hi Alexander > > The assertions are optional in this proposal. If this is added to > the MPI standard the minimal impacts (day one impacts) are: > > == > To application writers (none) - MPI_INIT and MPI_INIT_THREAD still > work. MPI_INIT_THREAD_xxx can be > passed 0 (zero) as the assertions bit vector. > > To MPI Implementors (small) - subroutine MPI_INIT_THREAD_xxx can be > a clone of MPI_INIT_THREAD under the covers. If the Forum decides > the query function is for asking what assertions are being honored, > the implementation can just return "none" to every query. If there > is also a query for what assertions have been made then there are a > few more lines of code the implementor must write to preserve the > value so it can be returned(maybe 10 lines) > > Writers of opaque libraries (small) - call the query function at > library init time and if any assertions are found, issue an error > message and kill the job. This is awkward for a library that wants > to support every MPI whether it has implemented the new query function or not. > == > > As MPI implementations begin to take advantage of assertions there > is more work for the MPI implementor and the library author must > begin to think about whether his customer will be upset if the > library simply outlaws all assertions. > > The library author will never be wrong if he simply forbids > assertions forever. If they become valuable he will feel the > pressure to work it out. > > The MPI implementor will never be wrong if he adds the API but > simply ignores assertions forever. If they become valuable he will > feel the pressure to honor some at least. > --------------------------------------------------------------------- > 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. > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > 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. > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Call for MPI 2.2 agenda items
by unknown＠example.com 05 May '08

05 May '08

Now that MPI 2.1 is close to completion, it is time to look at issues for MPI 2.2. Please send any items you may have for 2.2 to mpi-22_at_[hidden] and/or upload them to the wiki (and let us know). I had made a note of the following items from the last meeting that were deferred to 2.2: * support for long long in maxloc, minloc * fix meaning of first two sentences in intercommunicator barrier * Ex 5.8 uses old style MPI_UB * Many functions say "integer" instead of "nonnegative integer" * const in C++ bindings * IN, OUT, and INOUT handle types broken * MPI_CHAR, MPI::CHAR should be signed char or char? * Need 64-bit sizes for count in messages * Sizes of MPI_Aint and MPI_Offset should not be different * New predefined types MPI_AINT and MPI_OFFSET * New predefined types corresponding to new types in C99, Fortran 2003, and C++ some year

1 0

Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7
by unknown＠example.com 05 May '08

05 May '08

Woops... Read "dynamic processes" rather than "one-sided". Partial update, sorry. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, May 05, 2008 7:54 PM To: MPI 2.2 Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 Hi, We may want to see whether communicator-bound restriction will help down there. For example, even one communicator with dynamic processes enabled may "taint" the progress engine enough to make any saving from the absence of one-sided elsewhere disappear. On the other hand, attaching attributes to the MPI_COMM_WORLD, although not fully clean and properly timed, might be a way to spread the assertions across the job, and let libraries cut their proper part out. Same with windows and files, by the way. How and when will this pass down to the progress engine? I don't know. Do you? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Monday, May 05, 2008 7:31 PM To: MPI 2.2 Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 On May 5, 2008, at 1:28 PM, Supalov, Alexander wrote: > Thank you. We can actually introduce what you propose, possibly with > a query function to make it still easier to live with, as early as > in MPI 2.2, as a subset precursor. Judging by the discussion in > Chicago, subsets may not need much more than that in the end, > possibly with a little more flags and semantics added in MPI-3. > > The reservation against 32- (or for that matter, 64-) bit limitation > is the only one I have at the moment. Not being able to attach > assertions to communicators, etc. may be missed by some advanced > programmers, but here we need to be pragmatic: who will ever want to > go that deep? Libraries that build on top of MPI may want to. This was one of the prime motivations for communications, right? (private/safe communications) As Quincy stated in Chicago and on the mailing list (IIRC), what if a top-level app sets an assertion that a library using MPI can't live with? Being able to set them per-communicator might alleviate that issue. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7
by unknown＠example.com 05 May '08

05 May '08

Hi, We may want to see whether communicator-bound restriction will help down there. For example, even one communicator with dynamic processes enabled may "taint" the progress engine enough to make any saving from the absence of one-sided elsewhere disappear. On the other hand, attaching attributes to the MPI_COMM_WORLD, although not fully clean and properly timed, might be a way to spread the assertions across the job, and let libraries cut their proper part out. Same with windows and files, by the way. How and when will this pass down to the progress engine? I don't know. Do you? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Monday, May 05, 2008 7:31 PM To: MPI 2.2 Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 On May 5, 2008, at 1:28 PM, Supalov, Alexander wrote: > Thank you. We can actually introduce what you propose, possibly with > a query function to make it still easier to live with, as early as > in MPI 2.2, as a subset precursor. Judging by the discussion in > Chicago, subsets may not need much more than that in the end, > possibly with a little more flags and semantics added in MPI-3. > > The reservation against 32- (or for that matter, 64-) bit limitation > is the only one I have at the moment. Not being able to attach > assertions to communicators, etc. may be missed by some advanced > programmers, but here we need to be pragmatic: who will ever want to > go that deep? Libraries that build on top of MPI may want to. This was one of the prime motivations for communications, right? (private/safe communications) As Quincy stated in Chicago and on the mailing list (IIRC), what if a top-level app sets an assertion that a library using MPI can't live with? Being able to set them per-communicator might alleviate that issue. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7
by unknown＠example.com 05 May '08

05 May '08

On May 5, 2008, at 1:28 PM, Supalov, Alexander wrote: > Thank you. We can actually introduce what you propose, possibly with > a query function to make it still easier to live with, as early as > in MPI 2.2, as a subset precursor. Judging by the discussion in > Chicago, subsets may not need much more than that in the end, > possibly with a little more flags and semantics added in MPI-3. > > The reservation against 32- (or for that matter, 64-) bit limitation > is the only one I have at the moment. Not being able to attach > assertions to communicators, etc. may be missed by some advanced > programmers, but here we need to be pragmatic: who will ever want to > go that deep? Libraries that build on top of MPI may want to. This was one of the prime motivations for communications, right? (private/safe communications) As Quincy stated in Chicago and on the mailing list (IIRC), what if a top-level app sets an assertion that a library using MPI can't live with? Being able to set them per-communicator might alleviate that issue. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7
by unknown＠example.com 05 May '08

05 May '08

Dear Dick, Thank you. We can actually introduce what you propose, possibly with a query function to make it still easier to live with, as early as in MPI 2.2, as a subset precursor. Judging by the discussion in Chicago, subsets may not need much more than that in the end, possibly with a little more flags and semantics added in MPI-3. The reservation against 32- (or for that matter, 64-) bit limitation is the only one I have at the moment. Not being able to attach assertions to communicators, etc. may be missed by some advanced programmers, but here we need to be pragmatic: who will ever want to go that deep? Best regards. Alexander ________________________________ From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: Monday, May 05, 2008 7:18 PM To: MPI 2.2 Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 Hi Alexander I have no objection to citing my "assertions" proposal in the subsetting discussions. I do want to keep it clear that this proposal is intended to be as simple as practical to implement, exploit and live with. "Live with" applies to 3rd party library authors or anyone else who must write MPI code but does not know and control the structure of the entire application. That guy must "live with" the decisions made by whoever coded the MPI_INIT piece. "Live with" also applies to whoever must test or certify a specific MPI implementation. Thanks - 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 "Supalov, Alexander" <alexander.supalov_at_[hidden]> "Supalov, Alexander" <alexander.supalov_at_[hidden]> Sent by: mpi-22-bounces_at_[hidden] 04/26/2008 04:03 AM Please respond to "MPI 2.2" <mpi-22_at_[hidden]> To "MPI 2.2" <mpi-22_at_[hidden]> cc Subject Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 Dear Dick, Thank you. Would you mind if I cite your proposal in the subsets discussion? Yours looks like a good alternative to the thinking of some of us that subsets might be very rich and mutable, and to Jeff's proposal on hints I've already cited there with his permission. Best regards. Alexander ________________________________ From: mpi-22-bounces_at_[hidden] [ mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: Thursday, April 24, 2008 6:16 PM To: MPI 2.2 Subject: Re: [Mpi-22] mpi-22 Digest, Vol 2, Issue 7 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 mpi-22-bounces_at_[hidden] wrote on 04/24/2008 11:33:42 AM: > Hi, > > Note that this is an argument for making the assertions optional: those > who don't care don't have to use them. Those who care should use them > correctly or else. As usual. > > Best regards. > > Alexander > Hi Alexander The assertions are optional in this proposal. If this is added to the MPI standard the minimal impacts (day one impacts) are: == To application writers (none) - MPI_INIT and MPI_INIT_THREAD still work. MPI_INIT_THREAD_xxx can be passed 0 (zero) as the assertions bit vector. To MPI Implementors (small) - subroutine MPI_INIT_THREAD_xxx can be a clone of MPI_INIT_THREAD under the covers. If the Forum decides the query function is for asking what assertions are being honored, the implementation can just return "none" to every query. If there is also a query for what assertions have been made then there are a few more lines of code the implementor must write to preserve the value so it can be returned(maybe 10 lines) Writers of opaque libraries (small) - call the query function at library init time and if any assertions are found, issue an error message and kill the job. This is awkward for a library that wants to support every MPI whether it has implemented the new query function or not. == As MPI implementations begin to take advantage of assertions there is more work for the MPI implementor and the library author must begin to think about whether his customer will be upset if the library simply outlaws all assertions. The library author will never be wrong if he simply forbids assertions forever. If they become valuable he will feel the pressure to work it out. The MPI implementor will never be wrong if he adds the API but simply ignores assertions forever. If they become valuable he will feel the pressure to honor some at least. --------------------------------------------------------------------- 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. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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