April 2009 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] mpi-22 Digest, Vol 13, Issue 4
by unknown＠example.com 04 Apr '09

04 Apr '09

Hi Bronis, On Apr 4, 2009, at 10:57 AM, mpi-22-request_at_[hidden] wrote: > Message: 2 > Date: Fri, 3 Apr 2009 13:13:04 -0700 (PDT) > From: "Bronis R. de Supinski" <bronis_at_[hidden]> > Subject: Re: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28 > To: "MPI 2.2" <mpi-22_at_[hidden]> > Message-ID: <Pine.LNX.4.58.0904031311180.3888_at_[hidden]> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Quincy: > > A consistent order for MPI_COMM_SELF seems necessary for > the functionality that you need. Dick's comments that making > it consistent for all communicators makes a lot of sense. If > you put in the effort to find the places it needs to be > fixed then LLNL would support your proposed change. Thanks for the encouragement. :-) OK, I'll go through the standard and figure out the places that should be changed. However, I'm going to create a new ticket for this change, since I don't want to hold up ticket #71 and this new idea is tangential to the primary purpose of ticket #71. Quincey > Bronis > > > > > On Fri, 3 Apr 2009, Quincey Koziol wrote: > >> Hi Dick, >> >> On Mar 30, 2009, at 11:00 AM, treumann_at_[hidden] wrote: >> >>> Message: 3 >>> Date: Mon, 30 Mar 2009 10:09:44 -0400 >>> From: Richard Treumann <treumann_at_[hidden]> >>> Subject: Re: [Mpi-22] Ticket #71: Add routine for registering >>> callback >>> when finalize occurs >>> To: "MPI 2.2" <mpi-22_at_[hidden]> >>> Message-ID: >>> <OF78D7D349.90931954- >>> ON85257589.004B887F-85257589.004DCBDF_at_[hidden]> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> >>> I understand that the immediate motive is associated with the use of >>> attribute delete callbacks that occur when MPI_COMM_SELF is freed at >>> MPI_FINALIZE. >>> >>> That does not alter the fact that when MPI-2 imposed an implicit >>> free of >>> MPI_COMM_SELF in MPI_FINALIZE to allow the use of attribute delete >>> functions for cleanup it involved a narrow extension of a general >>> MPI >>> facility related to attributes and certain object types. To allow >>> attribute >>> delete functions for all other communicators (etc) to occur in >>> arbitrary >>> order while demanding that attribute delete for MPI_COMM_SELF have a >>> standards defined order is an inelegant hack (in my opinion). >>> Freeing >>> MPI_COMM_SELF within MPI_FINALIZE was a relatively elegant hack >>> because it >>> did not introduce inconsistency. >>> >>> Add to that the probability that an MPI implementor is likely to use >>> the >>> same algorithms for all attribute management rather than write >>> special case >>> code for MPI_COMM_SELF leads me to argue that if a defined order for >>> attribute delete callbacks is adopted it should be adopted broadly >>> to >>> maintain a consistent flavor across the standard. >>> >>> If an existing MPI implementation is currently deleting in some >>> other order >>> and an application happens to work on that MPI only because of that >>> order, >>> that application is at least non-portable and probably should be >>> considered >>> buggy. If (or when) the implementation adopts the fifo order for >>> attribute >>> deletes on "user_comm" it would be clear that the implementation >>> change had >>> not "broken the user". >>> >>> A general mandate that attribute deletion callbacks on all object >>> types >>> must occur in fifo order for an implementation to be MPI 2.2 >>> compliant >>> should not break any "correct" MPI application and should not be >>> noticeably >>> harder for implementors. >>> >>> It will require tracking down all places in the standard that >>> currently say >>> the order is arbitrary so it is harder to get all ducks in a row for >>> the >>> ticket. >> >> I'm willing to do the work to find the places in the standard which >> need to change, but need some general feedback about whether this is >> desired. Any opinions? Personally, I think it would be easier for >> implementors and more understandable to users to make things >> consistent across all attributes also, rather than treating >> MPI_COMM_SELF in a special way for the order of the delete callbacks. >> >> Quincey *

1 0

Re: [Mpi-22] [MPI Forum] #55: MPI-2.1 Cross-language attribute example is wrong
by unknown＠example.com 04 Apr '09

04 Apr '09

The fundamental problem here is that C encourages users to work with addresses of objects and in Fortran 77, there was no user-visible addresses at all. "Pointers" in Fortran 90 are also different from addresses. In many ways, the real mistake is trying to establish a correspondence between the Fortran and C/C++ versions. Permitting "Address-sized" integers in Fortran doesn't change the fact that you can't use them in the same way in Fortran as in C. Much of the struggle in this ticket is trying to work around this, as well as the decision (in MPI 1.0) to return pointers for all attributes in C, even for integer-valued predefined attributes. Bill On Apr 4, 2009, at 12:33 PM, MPI Forum wrote: > #55: MPI-2.1 Cross-language attribute example is wrong > ----------------------------------- > +---------------------------------------- > Reporter: jsquyres | Owner: jsquyres > Type: Correction to standard | Status: assigned > Priority: Waiting for reviews | Milestone: 2009/04/06 > Chicago > Version: MPI 2.2 | Resolution: > Keywords: | Implementation: Completed > ----------------------------------- > +---------------------------------------- > > Comment(by rsthakur): > > Note that if you get the value of MPI_TAG_UB in Fortran with > MPI_Comm_get_attr, you will get an address-sized value (487:48, > 488:1). > But in C you will get a pointer to an int-sized value. Does not seem > right. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55#comment:54 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] MPI-2.2 -- change ABI or not?
by unknown＠example.com 04 Apr '09

04 Apr '09

C++ is a bit tricky. It will have a runtime load impact if the MPI provider exports the C++ interface from a DLL (because of the C++ func signature change). If the C++ interface was provided as a static library (or as an inline implementation in the header) that links to the C bindings, there is no runtime impact and the application does not need to rebuild. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Saturday, April 04, 2009 9:21 AM To: MPI 2.2 Subject: [Mpi-22] MPI-2.2 -- change ABI or not? On Apr 4, 2009, at 9:53 AM, Jeff Squyres (jsquyres) wrote: > But the general point may need broad discussion next week -- have we > been sure to adhere to the "must be ABI compatible" rule for all > MPI-2.2 issues? > (changed the subjet to be more accurate) I notice that ticket #5 has already had a 1st reading; it will certainly change the ABI. My point: if we are taking a hard line to make it possible for any existing MPI-2.1 application to be able to run against MPI-2.1 and MPI-2.2 versions of the same implementation, we will need to review all MPI-2.2 tickets. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL
by unknown＠example.com 04 Apr '09

04 Apr '09

Its not always the choice of the MPI Application provider. In many cases there's an upgrade path for the infrastructure (like upgrading from Windows Compute Cluster Server to the newer version of Windows HPC Server) that includes an upgrade to the MPI implementation, any already deployed application that is not compatible with the new version would break. That would be a blocker for an upgrade and an important scenario for us. Another example is the impact on the application provider. Because of the release of the incompatible MPI 2.2 impl, the app provider has to re-ship an already shipped version of their app just to cope with the new installations of of MPI 2.2. (in those cases, yes, they don't ship the MPI implementation). That said, I didn't see any commercial app that depends on the C++ bindings. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Saturday, April 04, 2009 6:54 AM To: MPI 2.2 Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL Regardless of this point, note that the C++ bindings are *broken* in MPI-2.1 with regards to #55. You can't compile C++ MPI-2.1 applications that use MPI::FILE_NULL, MPI::WIN_NULL as specified in #55, so the point may be moot for this ticket. But the general point may need broad discussion next week -- have we been sure to adhere to the "must be ABI compatible" rule for all MPI-2.2 issues? My $0.02: why would ISV's (or any MPI application provider) upgrade to an MPI-2.2 implementation? They would only upgrade if there are features or bug fixes that they want. They would not upgrade for the sake of upgrading to 2.2. In such cases, I think it's ok for any MPI application developer (ISV or not) to re-compile. Indeed, most ISV's bundle/ship their own MPI implementation, so they tightly control the MPI anyway. If they don't want to upgrade to an MPI-2.2 implementation, they won't. On Apr 3, 2009, at 4:04 PM, Supalov, Alexander wrote: > Right. This is why I'm not sure whether changing the const status > may break existing apps: only compiler writers know for sure what > kind of repercussions this change may have in a C++ program. We > should probably ask them, at least in order to make data based > decisions. > > Semantic changes are also important and should be reduced only to > clean extensions. If an application expects a certain outcome, and > this outcome changes, the application may break, defeating MPI-2.2 > charter. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Friday, April 03, 2009 9:58 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on > MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > > I think it's both; > Any compiled application that is running against any specific > implementation does not have to recompile/rebuild to continue and > run against an updated implementation that is compliant with MPI 2.2. > i.e., MPI 2.2 does not mandate any runtime incompatibility. An > example for such incompatibility would be to for a change of the > rank parameter from int to MPI_Aint. > > Plus - any application that recompiles with the new MPI 2.2 headers > should not incur any (new) compiler errors. > > The first rule is significant to ISV's that release binary > implementation. Without this requirement, MPI 2.2 would create a > significant backward compatibility to those implementing. > > Thanks, > .Erez > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Jeff Squyres > Sent: Friday, April 03, 2009 11:07 AM > To: MPI Forum > Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on > MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > > This is worth raising to the list. > > What is the rule for 2.2 -- that existing MPI applications must be > able to run with no changes against an MPI-2.2 library? Or is it that > existing MPI applications must be able to compile and run with no > source code changes against an MPI-2.2 implementation? > > I hope it's the latter; this change is relatively important. > > > > On Apr 3, 2009, at 5:56 AM, MPI Forum wrote: > > > #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and > MPI::COMM_NULL > > ----------------------------------- > > +---------------------------------------- > > Reporter: hubertritzdorf | Owner: > hubertritzdorf > > Type: Correction to standard | Status: new > > Priority: Waiting for reviews | Milestone: 2009/04/06 > > Chicago > > Version: MPI 2.2 | Resolution: > > Keywords: | Implementation: Completed > > ----------------------------------- > > +---------------------------------------- > > Changes (by asupalov): > > > > * cc: alexander.supalov_at_[hidden] (added) > > > > > > Comment: > > > > Aren't we changing C++ ABI herewith? If so, we may want to postpone > > this > > change till MPI-3. > > > > -- > > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/ > 59#comment:33 > > > > > MPI Forum <https://svn.mpi-forum.org/> > > MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > 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 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

MPI-2.2 -- change ABI or not?
by unknown＠example.com 04 Apr '09

04 Apr '09

On Apr 4, 2009, at 9:53 AM, Jeff Squyres (jsquyres) wrote: > But the general point may need broad discussion next week -- have we > been sure to adhere to the "must be ABI compatible" rule for all > MPI-2.2 issues? > (changed the subjet to be more accurate) I notice that ticket #5 has already had a 1st reading; it will certainly change the ABI. My point: if we are taking a hard line to make it possible for any existing MPI-2.1 application to be able to run against MPI-2.1 and MPI-2.2 versions of the same implementation, we will need to review all MPI-2.2 tickets. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL
by unknown＠example.com 04 Apr '09

04 Apr '09

On Apr 4, 2009, at 9:53 AM, Jeff Squyres wrote: > Regardless of this point, note that the C++ bindings are *broken* in > MPI-2.1 with regards to #55. You can't compile C++ MPI-2.1 > applications that use MPI::FILE_NULL, MPI::WIN_NULL as specified in > #55, so the point may be moot for this ticket. Ever-vigilant Rolf pointed out that I really meant #59, not #55. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL
by unknown＠example.com 04 Apr '09

04 Apr '09

Regardless of this point, note that the C++ bindings are *broken* in MPI-2.1 with regards to #55. You can't compile C++ MPI-2.1 applications that use MPI::FILE_NULL, MPI::WIN_NULL as specified in #55, so the point may be moot for this ticket. But the general point may need broad discussion next week -- have we been sure to adhere to the "must be ABI compatible" rule for all MPI-2.2 issues? My $0.02: why would ISV's (or any MPI application provider) upgrade to an MPI-2.2 implementation? They would only upgrade if there are features or bug fixes that they want. They would not upgrade for the sake of upgrading to 2.2. In such cases, I think it's ok for any MPI application developer (ISV or not) to re-compile. Indeed, most ISV's bundle/ship their own MPI implementation, so they tightly control the MPI anyway. If they don't want to upgrade to an MPI-2.2 implementation, they won't. On Apr 3, 2009, at 4:04 PM, Supalov, Alexander wrote: > Right. This is why I'm not sure whether changing the const status > may break existing apps: only compiler writers know for sure what > kind of repercussions this change may have in a C++ program. We > should probably ask them, at least in order to make data based > decisions. > > Semantic changes are also important and should be reduced only to > clean extensions. If an application expects a certain outcome, and > this outcome changes, the application may break, defeating MPI-2.2 > charter. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Friday, April 03, 2009 9:58 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on > MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > > I think it's both; > Any compiled application that is running against any specific > implementation does not have to recompile/rebuild to continue and > run against an updated implementation that is compliant with MPI 2.2. > i.e., MPI 2.2 does not mandate any runtime incompatibility. An > example for such incompatibility would be to for a change of the > rank parameter from int to MPI_Aint. > > Plus - any application that recompiles with the new MPI 2.2 headers > should not incur any (new) compiler errors. > > The first rule is significant to ISV's that release binary > implementation. Without this requirement, MPI 2.2 would create a > significant backward compatibility to those implementing. > > Thanks, > .Erez > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Jeff Squyres > Sent: Friday, April 03, 2009 11:07 AM > To: MPI Forum > Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on > MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > > This is worth raising to the list. > > What is the rule for 2.2 -- that existing MPI applications must be > able to run with no changes against an MPI-2.2 library? Or is it that > existing MPI applications must be able to compile and run with no > source code changes against an MPI-2.2 implementation? > > I hope it's the latter; this change is relatively important. > > > > On Apr 3, 2009, at 5:56 AM, MPI Forum wrote: > > > #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and > MPI::COMM_NULL > > ----------------------------------- > > +---------------------------------------- > > Reporter: hubertritzdorf | Owner: > hubertritzdorf > > Type: Correction to standard | Status: new > > Priority: Waiting for reviews | Milestone: 2009/04/06 > > Chicago > > Version: MPI 2.2 | Resolution: > > Keywords: | Implementation: Completed > > ----------------------------------- > > +---------------------------------------- > > Changes (by asupalov): > > > > * cc: alexander.supalov_at_[hidden] (added) > > > > > > Comment: > > > > Aren't we changing C++ ABI herewith? If so, we may want to postpone > > this > > change till MPI-3. > > > > -- > > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/ > 59#comment:33 > > > > > MPI Forum <https://svn.mpi-forum.org/> > > MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > 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 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28
by unknown＠example.com 03 Apr '09

03 Apr '09

Quincy: A consistent order for MPI_COMM_SELF seems necessary for the functionality that you need. Dick's comments that making it consistent for all communicators makes a lot of sense. If you put in the effort to find the places it needs to be fixed then LLNL would support your proposed change. Bronis On Fri, 3 Apr 2009, Quincey Koziol wrote: > Hi Dick, > > On Mar 30, 2009, at 11:00 AM, treumann_at_[hidden] wrote: > > > Message: 3 > > Date: Mon, 30 Mar 2009 10:09:44 -0400 > > From: Richard Treumann <treumann_at_[hidden]> > > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback > > when finalize occurs > > To: "MPI 2.2" <mpi-22_at_[hidden]> > > Message-ID: > > <OF78D7D349.90931954- > > ON85257589.004B887F-85257589.004DCBDF_at_[hidden]> > > Content-Type: text/plain; charset="us-ascii" > > > > > > I understand that the immediate motive is associated with the use of > > attribute delete callbacks that occur when MPI_COMM_SELF is freed at > > MPI_FINALIZE. > > > > That does not alter the fact that when MPI-2 imposed an implicit > > free of > > MPI_COMM_SELF in MPI_FINALIZE to allow the use of attribute delete > > functions for cleanup it involved a narrow extension of a general MPI > > facility related to attributes and certain object types. To allow > > attribute > > delete functions for all other communicators (etc) to occur in > > arbitrary > > order while demanding that attribute delete for MPI_COMM_SELF have a > > standards defined order is an inelegant hack (in my opinion). Freeing > > MPI_COMM_SELF within MPI_FINALIZE was a relatively elegant hack > > because it > > did not introduce inconsistency. > > > > Add to that the probability that an MPI implementor is likely to use > > the > > same algorithms for all attribute management rather than write > > special case > > code for MPI_COMM_SELF leads me to argue that if a defined order for > > attribute delete callbacks is adopted it should be adopted broadly to > > maintain a consistent flavor across the standard. > > > > If an existing MPI implementation is currently deleting in some > > other order > > and an application happens to work on that MPI only because of that > > order, > > that application is at least non-portable and probably should be > > considered > > buggy. If (or when) the implementation adopts the fifo order for > > attribute > > deletes on "user_comm" it would be clear that the implementation > > change had > > not "broken the user". > > > > A general mandate that attribute deletion callbacks on all object > > types > > must occur in fifo order for an implementation to be MPI 2.2 compliant > > should not break any "correct" MPI application and should not be > > noticeably > > harder for implementors. > > > > It will require tracking down all places in the standard that > > currently say > > the order is arbitrary so it is harder to get all ducks in a row for > > the > > ticket. > > I'm willing to do the work to find the places in the standard which > need to change, but need some general feedback about whether this is > desired. Any opinions? Personally, I think it would be easier for > implementors and more understandable to users to make things > consistent across all attributes also, rather than treating > MPI_COMM_SELF in a special way for the order of the delete callbacks. > > Quincey > >

1 0

Re: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28
by unknown＠example.com 03 Apr '09

03 Apr '09

H Quincy Only Jeff has made any statement about his preference and he did not make a strong one. We will need to see what the Forum thinks next week. I added a comment to the ticket today. I think that having a LIFO order for attribute detach function callbacks is reasonable and not a very big burden on implementors. Bill Gropp mentioned that MPICH uses a hash table and would need to revise their code but he did not think it would be very difficult. It seems reasonable to me to say that all objects that cache attributes must record them in order so that attribute delete and attribute copy callback functions can be executed in a predictable order. For delete callbacks the logical order is LIFO. Since we previously said the order was arbitrary for both delete and copy, it cannot break any compliant MPI application if copy functions also are triggered in LIFO order. If somebody argues attribute copy functions should be triggered in FIFO order, things get a bit messy but still not too bad. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 04/03/2009 03:01:53 PM: > [image removed] > > Re: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28 > > Quincey Koziol > > to: > > mpi-22 > > 04/03/2009 03:04 PM > > Sent by: > > mpi-22-bounces_at_[hidden], > > Please respond to "MPI 2.2" > > Hi Dick, > > On Mar 30, 2009, at 11:00 AM, treumann_at_[hidden] wrote: > > > Message: 3 > > Date: Mon, 30 Mar 2009 10:09:44 -0400 > > From: Richard Treumann <treumann_at_[hidden]> > > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback > > when finalize occurs > > To: "MPI 2.2" <mpi-22_at_[hidden]> > > Message-ID: > > <OF78D7D349.90931954- > > ON85257589.004B887F-85257589.004DCBDF_at_[hidden]> > > Content-Type: text/plain; charset="us-ascii" > > > > > > I understand that the immediate motive is associated with the use of > > attribute delete callbacks that occur when MPI_COMM_SELF is freed at > > MPI_FINALIZE. > > > > That does not alter the fact that when MPI-2 imposed an implicit > > free of > > MPI_COMM_SELF in MPI_FINALIZE to allow the use of attribute delete > > functions for cleanup it involved a narrow extension of a general MPI > > facility related to attributes and certain object types. To allow > > attribute > > delete functions for all other communicators (etc) to occur in > > arbitrary > > order while demanding that attribute delete for MPI_COMM_SELF have a > > standards defined order is an inelegant hack (in my opinion). Freeing > > MPI_COMM_SELF within MPI_FINALIZE was a relatively elegant hack > > because it > > did not introduce inconsistency. > > > > Add to that the probability that an MPI implementor is likely to use > > the > > same algorithms for all attribute management rather than write > > special case > > code for MPI_COMM_SELF leads me to argue that if a defined order for > > attribute delete callbacks is adopted it should be adopted broadly to > > maintain a consistent flavor across the standard. > > > > If an existing MPI implementation is currently deleting in some > > other order > > and an application happens to work on that MPI only because of that > > order, > > that application is at least non-portable and probably should be > > considered > > buggy. If (or when) the implementation adopts the fifo order for > > attribute > > deletes on "user_comm" it would be clear that the implementation > > change had > > not "broken the user". > > > > A general mandate that attribute deletion callbacks on all object > > types > > must occur in fifo order for an implementation to be MPI 2.2 compliant > > should not break any "correct" MPI application and should not be > > noticeably > > harder for implementors. > > > > It will require tracking down all places in the standard that > > currently say > > the order is arbitrary so it is harder to get all ducks in a row for > > the > > ticket. > > I'm willing to do the work to find the places in the standard which > need to change, but need some general feedback about whether this is > desired. Any opinions? Personally, I think it would be easier for > implementors and more understandable to users to make things > consistent across all attributes also, rather than treating > MPI_COMM_SELF in a special way for the order of the delete callbacks. > > Quincey > > [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/ > IBM] _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL
by unknown＠example.com 03 Apr '09

03 Apr '09

Right. This is why I'm not sure whether changing the const status may break existing apps: only compiler writers know for sure what kind of repercussions this change may have in a C++ program. We should probably ask them, at least in order to make data based decisions. Semantic changes are also important and should be reduced only to clean extensions. If an application expects a certain outcome, and this outcome changes, the application may break, defeating MPI-2.2 charter. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Friday, April 03, 2009 9:58 PM To: MPI 2.2 Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL I think it's both; Any compiled application that is running against any specific implementation does not have to recompile/rebuild to continue and run against an updated implementation that is compliant with MPI 2.2. i.e., MPI 2.2 does not mandate any runtime incompatibility. An example for such incompatibility would be to for a change of the rank parameter from int to MPI_Aint. Plus - any application that recompiles with the new MPI 2.2 headers should not incur any (new) compiler errors. The first rule is significant to ISV's that release binary implementation. Without this requirement, MPI 2.2 would create a significant backward compatibility to those implementing. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, April 03, 2009 11:07 AM To: MPI Forum Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL This is worth raising to the list. What is the rule for 2.2 -- that existing MPI applications must be able to run with no changes against an MPI-2.2 library? Or is it that existing MPI applications must be able to compile and run with no source code changes against an MPI-2.2 implementation? I hope it's the latter; this change is relatively important. On Apr 3, 2009, at 5:56 AM, MPI Forum wrote: > #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > ----------------------------------- > +---------------------------------------- > Reporter: hubertritzdorf | Owner: hubertritzdorf > Type: Correction to standard | Status: new > Priority: Waiting for reviews | Milestone: 2009/04/06 > Chicago > Version: MPI 2.2 | Resolution: > Keywords: | Implementation: Completed > ----------------------------------- > +---------------------------------------- > Changes (by asupalov): > > * cc: alexander.supalov_at_[hidden] (added) > > > Comment: > > Aren't we changing C++ ABI herewith? If so, we may want to postpone > this > change till MPI-3. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/59#comment:33 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ 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