From erezh at [hidden] Wed Apr 1 20:06:07 2009 From: erezh at [hidden] (Erez Haba) Date: Wed, 1 Apr 2009 18:06:07 -0700 Subject: [Mpi-22] Please review ticket #140: Add const Keyword to the C bindings In-Reply-To: <[Mpi-22] Please review ticket #140: Add const Keyword to the C bindings> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B777BF5E9@NA-EXMSG-C105.redmond.corp.microsoft.com> Reminder: We need reviewers for ticket #140 for it to go through first reading in next week meeting. If you reviewed ticket #46, please review ticket #140 the diff between the two is quite trivial. If you were actively involved in discussing this ticket over email, please review and comment. Here's a list of ticket #46 reviewers: Darius Buntinas (thanks) Richard Graham Alexander Supalov Jesper Larsson Traeff Rajeev Thakur David Solt Torsten Hoefler Thanks, .Erez _____________________________________________ From: Erez Haba Sent: Monday, March 23, 2009 11:52 AM To: MPI 2.2 Subject: Please review ticket #140: Add const Keyword to the C bindings I opened a new ticket #140 for the "Add const Keyword to the C bindings" proposal instead of existing tickets #46, #129 & #130. Ticket #140 differs from ticket #46 only by the applied amendments in tickets #129 and #130. Chapter authors please review this ticket before the next forum meeting. Thanks, .Erez * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsquyres at [hidden] Thu Apr 2 15:18:09 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 2 Apr 2009 16:18:09 -0400 Subject: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs In-Reply-To: Message-ID: <498159EA-4785-4D83-8C69-A568F090FDD3@cisco.com> FWIW, I think this ticket is only about clarifying an existing semantic -- the notion of adding callbacks on MPI_COMM_SELF dates back quite a ways (I think all the way back to MPI-1 somewhere? I don't remember). On Mar 26, 2009, at 1:24 PM, Richard Treumann wrote: > Why would this be specific to MPI_COMM_SELF? If this is the right > thing to do, shouldn't it apply to attribute delete functions on all > disposed objects? > > > 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 03/26/2009 12:50:40 PM: > > > [image removed] > > > > [Mpi-22] Ticket #71: Add routine for registering callback when > finalize occurs > > > > Quincey Koziol > > > > to: > > > > mpi-22 > > > > 03/26/2009 12:54 PM > > > > Sent by: > > > > mpi-22-bounces_at_[hidden] > > > > Please respond to "MPI 2.2" > > > > Hi all, > > Could another two people review this ticket for specifying the > order > > that attribute delete callbacks should be made: > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 > > > > Thanks, > > 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 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Thu Apr 2 15:31:46 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 2 Apr 2009 16:31:46 -0400 Subject: [Mpi-22] Ticket #71: Add routine for registering callbackwhen finalize occurs In-Reply-To: Message-ID: Sorry -- I didn't see this much-more-complete discussion before I replied to the other mail. I agree with most of Dick's points (e.g., an MPI will likely implement the same mechanism for COMM_SELF as it does for all other attribute destruction functionality). But I don't feel strongly one way or the other (apply the ordering just to COMM_SELF or to all attribute destruction). To me, the COMM_SELF attribute destruction stuff is already a hack -- elegant or not -- so adding ordering on it is no big deal. But like I said, I don't have strong feelings either way. On Mar 30, 2009, at 10:09 AM, Richard Treumann wrote: > 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. > > > > 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 03/28/2009 11:57:19 PM: > > > [image removed] > > > > Re: [Mpi-22] Ticket #71: Add routine for registering callback when > > finalize occurs > > > > Quincey Koziol > > > > to: > > > > mpi-22 > > > > 03/30/2009 09:28 AM > > > > Sent by: > > > > mpi-22-bounces_at_[hidden] > > > > Please respond to "MPI 2.2" > > > > > > > Date: Thu, 26 Mar 2009 13:24:26 -0400 > > > From: Richard Treumann > > > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering > callback > > > when finalize occurs > > > To: "MPI 2.2" > > > Message-ID: > > > > > ON85257585.005F95BC-85257585.005F9F47_at_[hidden]> > > > Content-Type: text/plain; charset="us-ascii" > > > > > > Why would this be specific to MPI_COMM_SELF? If this is the right > > > thing to > > > do, shouldn't it apply to attribute delete functions on all > disposed > > > objects? > > > > The ticket is oriented to what happens at MPI_Finalize, really, > and > > not so much about MPI_COMM_SELF per se. The attribute callback on > > MPI_COMM_SELF was just the accepted way in the standard to "have > > something happen" when MPI_Finalize was called. > > > > Quincey > > > > > 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 03/26/2009 12:50:40 > PM: > > > > > >> [image removed] > > >> > > >> [Mpi-22] Ticket #71: Add routine for registering callback when > > >> finalize > > > occurs > > >> > > >> Quincey Koziol > > >> > > >> to: > > >> > > >> mpi-22 > > >> > > >> 03/26/2009 12:54 PM: > > >> > > >> Sent by: > > >> > > >> mpi-22-bounces_at_[hidden] > > >> > > >> Please respond to "MPI 2.2" > > >> > > >> Hi all, > > >> Could another two people review this ticket for specifying the > order > > >> that attribute delete callbacks should be made: > > >> > > >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 > > >> > > >> Thanks, > > >> 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 > > > -------------- next part -------------- > > > HTML attachment scrubbed and removed > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > mpi-22 mailing list > > > mpi-22_at_[hidden] > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > > > > > End of mpi-22 Digest, Vol 12, Issue 26 > > > ************************************** > > > > > > > [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 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From wgropp at [hidden] Thu Apr 2 15:38:07 2009 From: wgropp at [hidden] (William Gropp) Date: Thu, 2 Apr 2009 15:38:07 -0500 Subject: [Mpi-22] [MPI Forum] #71: Add routine for registering callback when finalize occurs In-Reply-To: <053.b18048c8090a18f9c581c15f4a4f5bbf@lists.mpi-forum.org> Message-ID: <94521C73-37DE-4A50-A706-55470DDBF2C0@illinois.edu> I checked MPICH2, and it doesn't invoke the attribute destroy functions in the order required here. It wouldn't be hard to change, but I haven't had a chance to do that. Bill On Apr 2, 2009, at 3:26 PM, MPI Forum wrote: > #71: Add routine for registering callback when finalize occurs > ------------------------------------- > +-------------------------------------- > Reporter: koziol | Owner: koziol > Type: Enhancements to standard | Status: assigned > Priority: Waiting for reviews | Milestone: 2009/04/06 > Chicago > Version: MPI 2.2 | Resolution: > Keywords: | Implementation: Waiting > ------------------------------------- > +-------------------------------------- > > Comment(by jsquyres): > > Other than missing a changelog, this proposal looks good (read: we > need a > changelog entry ASAP before we can discuss it next week in Chicago!). > > Rajeev -- I think the issue with enforced ordering was inspired by > potentially using multiple different middleware packages that may > not be > able to coordinate their shutdown callbacks. E.g., if package A uses > package B which uses MPI, then you ''need'' to have B's finalize > callback > called before A's. A and B would be hard-pressed to coordinate this > if > they didn't know about each other. And so on. > > FWIW, Open MPI does ''not'' invoke COMM_SELF callbacks in any > particular > order -- it'll actually be a little painful to convert to assign an > order > (because we use a hash table to store this stuff). But it's all just > bookkeeping -- it's certainly do-able. So someone needs to do an > open- > source implementation. > > Bill -- did you get a chance to see if MPICH2 destroys COMM_SELF > attributes in order? > > -- > Ticket URL: > > MPI Forum > 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 From jed at [hidden] Fri Apr 3 06:43:51 2009 From: jed at [hidden] (Jed Brown) Date: Fri, 3 Apr 2009 13:43:51 +0200 Subject: [Mpi-22] Non-collective reductions: MPI_Op_reduce Message-ID: <20090403114351.GE13759@brakk.ethz.ch> I hope this is the right forum. It looks like I can't make a Trac account. There is no way for the user to apply an MPI_Op to local buffers. I am missing this ability for implementing a domain-specific irregular reduction, for which use of MPI_Op would be natural. This functionality would be useful for many domain-specific collective operations. The semantics I'm looking for are identical to Open MPI's ompi_op_reduce(). Any chance this could be made available in MPI-2.2 (or 3)? Jed * -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-part Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From traff at [hidden] Fri Apr 3 06:53:47 2009 From: traff at [hidden] (Jesper Larsson Traeff) Date: Fri, 3 Apr 2009 13:53:47 +0200 Subject: [Mpi-22] Non-collective reductions: MPI_Op_reduce In-Reply-To: <20090403114351.GE13759@brakk.ethz.ch> Message-ID: <20090403115347.GA21721@fourier.it.neclab.eu> Dear Jed, what you're looking for sounds like MPI_Reduce_local which is proposed in ticket #24. There's a fair chance that that will become part of MPI 2.2 best regards Jesper On Fri, Apr 03, 2009 at 01:43:51PM +0200, Jed Brown wrote: > I hope this is the right forum. It looks like I can't make a Trac account. > > There is no way for the user to apply an MPI_Op to local buffers. I am > missing this ability for implementing a domain-specific irregular > reduction, for which use of MPI_Op would be natural. This functionality > would be useful for many domain-specific collective operations. The > semantics I'm looking for are identical to Open MPI's ompi_op_reduce(). > > Any chance this could be made available in MPI-2.2 (or 3)? > > Jed > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From jed at [hidden] Fri Apr 3 07:02:08 2009 From: jed at [hidden] (Jed Brown) Date: Fri, 3 Apr 2009 14:02:08 +0200 Subject: [Mpi-22] Non-collective reductions: MPI_Op_reduce In-Reply-To: <20090403115347.GA21721@fourier.it.neclab.eu> Message-ID: <20090403120208.GF13759@brakk.ethz.ch> On Fri 2009-04-03 13:53, Jesper Larsson Traeff wrote: > what you're looking for sounds like MPI_Reduce_local which is proposed > in ticket #24. There's a fair chance that that will become part > of MPI 2.2 Thanks Jesper, somehow I missed this. It's exactly what I was looking for. Jed * -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-part Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jsquyres at [hidden] Fri Apr 3 09:19:37 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 3 Apr 2009 10:19:37 -0400 Subject: [Mpi-22] Non-collective reductions: MPI_Op_reduce In-Reply-To: <20090403120208.GF13759@brakk.ethz.ch> Message-ID: FWIW, it's already implemented in Open MPI, but wasn't included in the v1.3 series. On Apr 3, 2009, at 8:02 AM, Jed Brown wrote: > On Fri 2009-04-03 13:53, Jesper Larsson Traeff wrote: > > what you're looking for sounds like MPI_Reduce_local which is > proposed > > in ticket #24. There's a fair chance that that will become part > > of MPI 2.2 > > Thanks Jesper, somehow I missed this. It's exactly what I was looking > for. > > Jed > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Fri Apr 3 13:06:47 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 3 Apr 2009 14:06:47 -0400 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: <061.c7457bd04f1bbb0bf27e96ae11aadb00@lists.mpi-forum.org> Message-ID: <3940B25F-4581-4E98-ADD2-0A42BE9DDFFB@cisco.com> 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: > > MPI Forum > MPI Forum -- Jeff Squyres Cisco Systems From wgropp at [hidden] Fri Apr 3 13:48:25 2009 From: wgropp at [hidden] (William Gropp) Date: Fri, 3 Apr 2009 13:48:25 -0500 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: <3940B25F-4581-4E98-ADD2-0A42BE9DDFFB@cisco.com> Message-ID: I've viewed this as a source-code requirement - Applications require no changes in their source code. That permits requiring recompilation. Bill On Apr 3, 2009, at 1:06 PM, Jeff Squyres wrote: > 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: > 59#comment:33 >>> >> MPI Forum >> MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 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 From alexander.supalov at [hidden] Fri Apr 3 13:59:40 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 3 Apr 2009 19:59:40 +0100 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E92718507@irsmsx504.ger.corp.intel.com> Hi, Thanks. AFAIK, the requirement is that the changes in MPI-2.2 should not break existing applications. I've always seen this as a semantic and an ABI constraint. If compile time changes are allowed, this may strongly delay adoption of the MPI-2.2 by the shrink-wrapped ISV applications. In any case, MPI-2.2 will have to offer substantially more new capabilities than the current set of tickets in order to make this change pay off. Don't forget about the ISV need for supporting many MPIs either. Some of them - both MPIs and applications - may prefer to stay in the 2.1 era to prevent forcing their customers to recompile. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Friday, April 03, 2009 8:48 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've viewed this as a source-code requirement - Applications require no changes in their source code. That permits requiring recompilation. Bill On Apr 3, 2009, at 1:06 PM, Jeff Squyres wrote: > 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: > 59#comment:33 >>> >> MPI Forum >> MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 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 _______________________________________________ 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. From koziol at [hidden] Fri Apr 3 14:01:53 2009 From: koziol at [hidden] (Quincey Koziol) Date: Fri, 3 Apr 2009 14:01:53 -0500 Subject: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28 In-Reply-To: Message-ID: <0F15FF71-CD2C-4F2F-8C86-5A25FC869D5E@hdfgroup.org> 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 > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback > when finalize occurs > To: "MPI 2.2" > Message-ID: > 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 * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: smime.p7s URL: From erezh at [hidden] Fri Apr 3 14:58:06 2009 From: erezh at [hidden] (Erez Haba) Date: Fri, 3 Apr 2009 12:58:06 -0700 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: <3940B25F-4581-4E98-ADD2-0A42BE9DDFFB@cisco.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B777BFE6A@NA-EXMSG-C105.redmond.corp.microsoft.com> 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: > > MPI Forum > MPI Forum -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From alexander.supalov at [hidden] Fri Apr 3 15:04:30 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 3 Apr 2009 21:04:30 +0100 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B777BFE6A@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E9271851E@irsmsx504.ger.corp.intel.com> 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: > > MPI Forum > 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. From treumann at [hidden] Fri Apr 3 15:07:19 2009 From: treumann at [hidden] (Richard Treumann) Date: Fri, 3 Apr 2009 16:07:19 -0400 Subject: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28 In-Reply-To: <0F15FF71-CD2C-4F2F-8C86-5A25FC869D5E@hdfgroup.org> Message-ID: 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 > > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback > > when finalize occurs > > To: "MPI 2.2" > > Message-ID: > > > 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronis at [hidden] Fri Apr 3 15:13:04 2009 From: bronis at [hidden] (Bronis R. de Supinski) Date: Fri, 3 Apr 2009 13:13:04 -0700 (PDT) Subject: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28 In-Reply-To: <0F15FF71-CD2C-4F2F-8C86-5A25FC869D5E@hdfgroup.org> Message-ID: 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 > > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback > > when finalize occurs > > To: "MPI 2.2" > > Message-ID: > > > 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 > > From jsquyres at [hidden] Sat Apr 4 08:53:47 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Sat, 4 Apr 2009 09:53:47 -0400 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E9271851E@irsmsx504.ger.corp.intel.com> Message-ID: 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: 59#comment:33 > > > > > MPI Forum > > 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 From jsquyres at [hidden] Sat Apr 4 10:57:22 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Sat, 4 Apr 2009 11:57:22 -0400 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: Message-ID: 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 From jsquyres at [hidden] Sat Apr 4 11:20:59 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Sat, 4 Apr 2009 12:20:59 -0400 Subject: [Mpi-22] MPI-2.2 -- change ABI or not? In-Reply-To: Message-ID: 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 From erezh at [hidden] Sat Apr 4 13:47:33 2009 From: erezh at [hidden] (Erez Haba) Date: Sat, 4 Apr 2009 11:47:33 -0700 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E7B777C0107@NA-EXMSG-C105.redmond.corp.microsoft.com> 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: 59#comment:33 > > > > > MPI Forum > > 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 From erezh at [hidden] Sat Apr 4 14:02:52 2009 From: erezh at [hidden] (Erez Haba) Date: Sat, 4 Apr 2009 12:02:52 -0700 Subject: [Mpi-22] MPI-2.2 -- change ABI or not? In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E7B777C010E@NA-EXMSG-C105.redmond.corp.microsoft.com> 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 From wgropp at [hidden] Sat Apr 4 14:56:11 2009 From: wgropp at [hidden] (William Gropp) Date: Sat, 4 Apr 2009 14:56:11 -0500 Subject: [Mpi-22] [MPI Forum] #55: MPI-2.1 Cross-language attribute example is wrong In-Reply-To: <055.dca3b02a6ff878779880864b9524564a@lists.mpi-forum.org> Message-ID: <5C86F545-ADBC-4CFA-A0F6-9707BF8BC9D6@illinois.edu> 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: > > MPI Forum > 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 From koziol at [hidden] Sat Apr 4 22:42:35 2009 From: koziol at [hidden] (Quincey Koziol) Date: Sat, 4 Apr 2009 22:42:35 -0500 Subject: [Mpi-22] mpi-22 Digest, Vol 13, Issue 4 In-Reply-To: Message-ID: <7E878CD0-DF9C-45BB-B6DA-A49F8136BCF6@hdfgroup.org> 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" > Subject: Re: [Mpi-22] mpi-22 Digest, Vol 12, Issue 28 > To: "MPI 2.2" > Message-ID: > 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 >>> Subject: Re: [Mpi-22] Ticket #71: Add routine for registering >>> callback >>> when finalize occurs >>> To: "MPI 2.2" >>> Message-ID: >>> >> 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 * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: smime.p7s URL: From alexander.supalov at [hidden] Sun Apr 5 19:45:42 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Mon, 6 Apr 2009 01:45:42 +0100 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E927185BA@irsmsx504.ger.corp.intel.com> Hi, This sort of puts the argument upon its head. It reads almost like "let's define a standard as we please, and those who don't like it may not upgrade". I bet there will be some who won't, as currently MPI-2.2 does not seem to provide an overwhelming set of new features to justify ABI incompatibility. What's the point in defining such a standard? I'm about to propose to scuttle an ABI-incompatible MPI-2.2 altogether then. Let's collect a critical mass of new features in the MPI-3, and then we'll be able to fix ABI issues in due order. Full disclaimer: written upon a 10-hour flight, running into 3 am by the old time zone. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Saturday, April 04, 2009 3:54 PM 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: 59#comment:33 > > > > > MPI Forum > > 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 --------------------------------------------------------------------- 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. From alexander.supalov at [hidden] Sun Apr 5 19:53:53 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Mon, 6 Apr 2009 01:53:53 +0100 Subject: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B777C0107@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E927185BB@irsmsx504.ger.corp.intel.com> Hi, There are some big shrink-wrapped HPC apps that use C++ extensively. They may be unavailable under Windows yet. One would have to ask their authors whether the MPI C++ interface is used directly or abstracted away via an internal layer talking to C. Applications that are deployed over a tightly controlled OS like Windows would probably recompile after some grumbling, or migrate to a less tightly controlled OS. Under that less centrally controlled OS, like Linux, a change in the ABI would basically add another tree to the MPI forest, instead of consolidating all of them in one bundle. And then ISVs would have a problem, and us, implementors, would have a problem, too. Do we want to create a standard with a built-in set of problems? I don't think so. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Saturday, April 04, 2009 8:48 PM To: MPI 2.2 Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL 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: 59#comment:33 > > > > > MPI Forum > > 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 _______________________________________________ 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. From jsquyres at [hidden] Mon Apr 6 05:59:29 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Mon, 6 Apr 2009 06:59:29 -0400 Subject: [Mpi-22] latex errors In-Reply-To: <063.c807febc79de6cef1f72c17f4f7241c2@lists.mpi-forum.org> Message-ID: Bill -- I get latex errors in any "chap-*" subdirectory when trying to build with a vanilla "make". Example: [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2 % cd chap-intro/ [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2/chap-intro % make rm -f temp.tex cat ../chapter-head.tex intro.tex > temp.tex if grep \\cite intro.tex ; then \ ....etc....... LaTeX Warning: Reference `sec:lang' on page 7 undefined on input line 818. LaTeX Warning: Reference `chap:change' on page 7 undefined on input line 834. ! Text line contains an invalid character. l.916 ^^H ibliographystyle{plain} ? On Apr 5, 2009, at 2:30 PM, MPI Forum wrote: > #148: Missing entries in the Index pages. > --------------------------------- > +------------------------------------------ > Reporter: RolfRabenseifner | Owner: RolfRabenseifner > Type: Trivial text changes | Status: new > Priority: Waiting for reviews | Milestone: 2009/04/06 > Chicago > Version: MPI 2.2 | Resolution: > Keywords: | Implementation: Unnecessary > --------------------------------- > +------------------------------------------ > > Comment(by gropp): > > For the chapter authors, there is now a Makefile in each chapter's > directory. Running "make" (no options) will built that chapter, > including > a basic index. This index includes all items for which some index > entry > will be created; it isn't separated into constant, function, etc. > indices. > This should make it easier to check your chapter - just print out the > index, then go through each page and make sure that all relevant > items > appear. > > -- > Ticket URL: > > MPI Forum > MPI Forum -- Jeff Squyres Cisco Systems From treumann at [hidden] Mon Apr 6 07:15:38 2009 From: treumann at [hidden] (Richard Treumann) Date: Mon, 6 Apr 2009 08:15:38 -0400 Subject: [Mpi-22] MPI-2.2 -- change ABI or not? In-Reply-To: Message-ID: Changing the ABI strikes me as a disaster. ( I did not notice this discussion until just now ) If anyone is thinking it is OK for the Forum to cause a 2.1 application compiled against MPI 2.1 headers to fail on an MPI 2.2 version of the same implementation or the reverse (2.1 application compiled with 2.2 headers fails on a 2.1 implementation) then I need to hear a really good reason. And I mean really, awesomely, spectacularly, bodacious ) good. The user of a parallel application does not always have control over the level of MPI installed on the systems he uses and does not always have the source code to recompile. Some people use multiple systems (same architecture but maybe different MPI version) It seems like a very bad idea to tell the user of MPI that he must upgrade all MPI software he uses on the same day the system admin installs the MPI 2.2 version of the MPI implementation. It seems like an equally bad idea to be telling system admins they are forbidden to upgrade to the MPI 2.2 version because one of more critical applications used on the system cannot be easily rebuilt in MPI 2.2 compatible form. If a shop uses only one ISV application then perhaps they can use the MPI level the ISV specifies but what does a shop that uses assorted ISV applications do if some vendors stick with MPI 2.1 headers and others compile for 2.2? Dick 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/04/2009 12:20:59 PM: > [image removed] > > [Mpi-22] MPI-2.2 -- change ABI or not? > > Jeff Squyres > > to: > > MPI 2.2 > > 04/04/2009 12:25 PM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From wgropp at [hidden] Mon Apr 6 10:30:29 2009 From: wgropp at [hidden] (William Gropp) Date: Mon, 6 Apr 2009 10:30:29 -0500 Subject: [Mpi-22] latex errors In-Reply-To: Message-ID: Argh. There are two problems which I'll work on fixing: 1. It doesn't import the aux file from a full build. 2. echo has unspecified behavior when the first character is a \ (some echo's want this to be an escape into an extended character set, and some don't). Does echo '\bib' give \bib or ^hib on your system? Bill On Apr 6, 2009, at 5:59 AM, Jeff Squyres wrote: > Bill -- > > I get latex errors in any "chap-*" subdirectory when trying to build > with a vanilla "make". Example: > > [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2 % cd chap-intro/ > [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2/chap-intro % > make > rm -f temp.tex > cat ../chapter-head.tex intro.tex > temp.tex > if grep \\cite intro.tex ; then \ > ....etc....... > LaTeX Warning: Reference `sec:lang' on page 7 undefined on input line > 818. > > > LaTeX Warning: Reference `chap:change' on page 7 undefined on input > line 834. > > ! Text line contains an invalid character. > l.916 ^^H > ibliographystyle{plain} > ? > > > > > On Apr 5, 2009, at 2:30 PM, MPI Forum wrote: > >> #148: Missing entries in the Index pages. >> --------------------------------- >> +------------------------------------------ >> Reporter: RolfRabenseifner | Owner: >> RolfRabenseifner >> Type: Trivial text changes | Status: new >> Priority: Waiting for reviews | Milestone: 2009/04/06 >> Chicago >> Version: MPI 2.2 | Resolution: >> Keywords: | Implementation: Unnecessary >> --------------------------------- >> +------------------------------------------ >> >> Comment(by gropp): >> >> For the chapter authors, there is now a Makefile in each chapter's >> directory. Running "make" (no options) will built that chapter, >> including >> a basic index. This index includes all items for which some index >> entry >> will be created; it isn't separated into constant, function, etc. >> indices. >> This should make it easier to check your chapter - just print out the >> index, then go through each page and make sure that all relevant >> items >> appear. >> >> -- >> Ticket URL: > 148#comment:3 >>> >> MPI Forum >> MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 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 From wgropp at [hidden] Mon Apr 6 18:38:07 2009 From: wgropp at [hidden] (William Gropp) Date: Mon, 6 Apr 2009 18:38:07 -0500 Subject: [Mpi-22] MPI 2.2 lists of participants and organizations (front matter for MPI 2.2) Message-ID: <52DBB012-3E48-4FF1-9B84-9804D51A5847@illinois.edu> Please have a look at https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/77 . This list the participants and their institutions; it is your responsibility to make sure that you and your organization are correctly listed. We will be giving this a first reading at this meeting. Thanks! Bill 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 From jsquyres at [hidden] Mon Apr 6 22:04:04 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Mon, 6 Apr 2009 22:04:04 -0500 Subject: [Mpi-22] latex errors In-Reply-To: Message-ID: <01EEADD0-E970-4CA1-94DF-FF4B85BC53C7@cisco.com> [22:03] rtp-jsquyres-8716:~ % echo '\bib' \bib On Apr 6, 2009, at 10:30 AM, William Gropp wrote: > Argh. There are two problems which I'll work on fixing: > 1. It doesn't import the aux file from a full build. > 2. echo has unspecified behavior when the first character is a \ (some > echo's want this to be an escape into an extended character set, and > some don't). > Does echo '\bib' give \bib or ^hib on your system? > > Bill > > On Apr 6, 2009, at 5:59 AM, Jeff Squyres wrote: > > > Bill -- > > > > I get latex errors in any "chap-*" subdirectory when trying to build > > with a vanilla "make". Example: > > > > [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2 % cd chap- > intro/ > > [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2/chap-intro % > > make > > rm -f temp.tex > > cat ../chapter-head.tex intro.tex > temp.tex > > if grep \\cite intro.tex ; then \ > > ....etc....... > > LaTeX Warning: Reference `sec:lang' on page 7 undefined on input > line > > 818. > > > > > > LaTeX Warning: Reference `chap:change' on page 7 undefined on input > > line 834. > > > > ! Text line contains an invalid character. > > l.916 ^^H > > ibliographystyle{plain} > > ? > > > > > > > > > > On Apr 5, 2009, at 2:30 PM, MPI Forum wrote: > > > >> #148: Missing entries in the Index pages. > >> --------------------------------- > >> +------------------------------------------ > >> Reporter: RolfRabenseifner | Owner: > >> RolfRabenseifner > >> Type: Trivial text changes | Status: new > >> Priority: Waiting for reviews | Milestone: 2009/04/06 > >> Chicago > >> Version: MPI 2.2 | Resolution: > >> Keywords: | Implementation: Unnecessary > >> --------------------------------- > >> +------------------------------------------ > >> > >> Comment(by gropp): > >> > >> For the chapter authors, there is now a Makefile in each chapter's > >> directory. Running "make" (no options) will built that chapter, > >> including > >> a basic index. This index includes all items for which some index > >> entry > >> will be created; it isn't separated into constant, function, etc. > >> indices. > >> This should make it easier to check your chapter - just print out > the > >> index, then go through each page and make sure that all relevant > >> items > >> appear. > >> > >> -- > >> Ticket URL: >> 148#comment:3 > >>> > >> MPI Forum > >> MPI Forum > > > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > 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 > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Tue Apr 7 06:19:27 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 7 Apr 2009 06:19:27 -0500 Subject: [Mpi-22] MPI-2.2 -- change ABI or not? In-Reply-To: Message-ID: <2F8331E6-BF8B-47A8-93B2-99D6BB1B4567@cisco.com> Dick -- Following a round of discussion here in Chicago, there is general consensus on your point. The have decided to give a little leeway on the C++ bindings, though. That is, the C++ ABI may change (e.g., it *has* changed between 2.0 and 2.1) because most MPI's implement the C++ layer as inline functions and therefore don't usually affect the run-time ABI. For example #59 will definitely change the ABI. But right now, those methods *won't compile* in the C++ bindings (because they are wrong), so we can't possibly be breaking any real/user applications. On Apr 6, 2009, at 7:15 AM, Richard Treumann wrote: > Changing the ABI strikes me as a disaster. ( I did not notice this > discussion until just now ) > > If anyone is thinking it is OK for the Forum to cause a 2.1 > application compiled against MPI 2.1 headers to fail on an MPI 2.2 > version of the same implementation or the reverse (2.1 application > compiled with 2.2 headers fails on a 2.1 implementation) then I need > to hear a really good reason. And I mean really, awesomely, > spectacularly, bodacious ) good. > > The user of a parallel application does not always have control over > the level of MPI installed on the systems he uses and does not > always have the source code to recompile. Some people use multiple > systems (same architecture but maybe different MPI version) > > It seems like a very bad idea to tell the user of MPI that he must > upgrade all MPI software he uses on the same day the system admin > installs the MPI 2.2 version of the MPI implementation. > > It seems like an equally bad idea to be telling system admins they > are forbidden to upgrade to the MPI 2.2 version because one of more > critical applications used on the system cannot be easily rebuilt in > MPI 2.2 compatible form. > > If a shop uses only one ISV application then perhaps they can use > the MPI level the ISV specifies but what does a shop that uses > assorted ISV applications do if some vendors stick with MPI 2.1 > headers and others compile for 2.2? > > Dick > > > 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/04/2009 12:20:59 PM: > > > [image removed] > > > > [Mpi-22] MPI-2.2 -- change ABI or not? > > > > Jeff Squyres > > > > to: > > > > MPI 2.2 > > > > 04/04/2009 12:25 PM > > > > Sent by: > > > > mpi-22-bounces_at_[hidden] > > > > Please respond to "MPI 2.2" > > > > 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 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From alexander.supalov at [hidden] Tue Apr 7 08:29:23 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Tue, 7 Apr 2009 14:29:23 +0100 Subject: [Mpi-22] MPI-2.2 -- change ABI or not? In-Reply-To: <2F8331E6-BF8B-47A8-93B2-99D6BB1B4567@cisco.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E92768332@irsmsx504.ger.corp.intel.com> Hi, Thanks. Let me add that there's quite vocal opposition to changing C++ ABI either. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Tuesday, April 07, 2009 1:19 PM To: MPI 2.2 Subject: Re: [Mpi-22] MPI-2.2 -- change ABI or not? Dick -- Following a round of discussion here in Chicago, there is general consensus on your point. The have decided to give a little leeway on the C++ bindings, though. That is, the C++ ABI may change (e.g., it *has* changed between 2.0 and 2.1) because most MPI's implement the C++ layer as inline functions and therefore don't usually affect the run-time ABI. For example #59 will definitely change the ABI. But right now, those methods *won't compile* in the C++ bindings (because they are wrong), so we can't possibly be breaking any real/user applications. On Apr 6, 2009, at 7:15 AM, Richard Treumann wrote: > Changing the ABI strikes me as a disaster. ( I did not notice this > discussion until just now ) > > If anyone is thinking it is OK for the Forum to cause a 2.1 > application compiled against MPI 2.1 headers to fail on an MPI 2.2 > version of the same implementation or the reverse (2.1 application > compiled with 2.2 headers fails on a 2.1 implementation) then I need > to hear a really good reason. And I mean really, awesomely, > spectacularly, bodacious ) good. > > The user of a parallel application does not always have control over > the level of MPI installed on the systems he uses and does not > always have the source code to recompile. Some people use multiple > systems (same architecture but maybe different MPI version) > > It seems like a very bad idea to tell the user of MPI that he must > upgrade all MPI software he uses on the same day the system admin > installs the MPI 2.2 version of the MPI implementation. > > It seems like an equally bad idea to be telling system admins they > are forbidden to upgrade to the MPI 2.2 version because one of more > critical applications used on the system cannot be easily rebuilt in > MPI 2.2 compatible form. > > If a shop uses only one ISV application then perhaps they can use > the MPI level the ISV specifies but what does a shop that uses > assorted ISV applications do if some vendors stick with MPI 2.1 > headers and others compile for 2.2? > > Dick > > > 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/04/2009 12:20:59 PM: > > > [image removed] > > > > [Mpi-22] MPI-2.2 -- change ABI or not? > > > > Jeff Squyres > > > > to: > > > > MPI 2.2 > > > > 04/04/2009 12:25 PM > > > > Sent by: > > > > mpi-22-bounces_at_[hidden] > > > > Please respond to "MPI 2.2" > > > > 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 > _______________________________________________ > 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 --------------------------------------------------------------------- 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. From jsquyres at [hidden] Thu Apr 16 09:19:05 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 16 Apr 2009 10:19:05 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? Message-ID: <5757270D-63D6-4FCB-AADB-59847B3A1C75@cisco.com> This is related to -- but different from -- MPI 2.2 ticket #55 ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly adding all the #55 CC members to this mail, plus a few others. I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific behavior regarding the EXTRA_STATE arguments passed to the Fortran keyval copy and delete functions (both the ADDRESS_KIND and deprecated flavors). I see two choices: 1. pass the user's original EXTRA_STATE argument by reference to the callbacks, or 2. copy the user's original EXTRA_STATE into internal MPI storage and pass *that* value by reference to the callbacks ==> Open MPI currently does #1. What do other implementations do? I raise this issue because the text does not indicate which way is right. And I just ran across an old Sun test that assumed #2. But our internal copy of the Intel MPI tests assume #1 (to be fair: I have no idea if the Intel tests originally assumed #2 and we changed them to #1 over time). Indeed, #2 is actually in-line with the philosophy of storing attribute values in internal MPI storage. E.g.: INTEGER foo = 4 INTEGER bar CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) foo = 5 CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) bar should equal 4, not 5 (right?). So what does that mean (or imply) about the EXTRA_STATE value passed to the Fortran callbacks? -- Jeff Squyres Cisco Systems From david.solt at [hidden] Thu Apr 16 09:29:14 2009 From: david.solt at [hidden] (Solt, David George) Date: Thu, 16 Apr 2009 14:29:14 +0000 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <5757270D-63D6-4FCB-AADB-59847B3A1C75@cisco.com> Message-ID: HP-MPI does #2. What if the address of the variable originally passed in is no longer in scope when the corresponding comm_get_attr call is made? Dave -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 9:19 AM To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Alexander Supalov; Bronis de Supinski; Solt, David George; Hans Westgaard Ry; Håkon Bugge Subject: Another MPI-2.2 attribute ambiguity? This is related to -- but different from -- MPI 2.2 ticket #55 ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly adding all the #55 CC members to this mail, plus a few others. I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific behavior regarding the EXTRA_STATE arguments passed to the Fortran keyval copy and delete functions (both the ADDRESS_KIND and deprecated flavors). I see two choices: 1. pass the user's original EXTRA_STATE argument by reference to the callbacks, or 2. copy the user's original EXTRA_STATE into internal MPI storage and pass *that* value by reference to the callbacks ==> Open MPI currently does #1. What do other implementations do? I raise this issue because the text does not indicate which way is right. And I just ran across an old Sun test that assumed #2. But our internal copy of the Intel MPI tests assume #1 (to be fair: I have no idea if the Intel tests originally assumed #2 and we changed them to #1 over time). Indeed, #2 is actually in-line with the philosophy of storing attribute values in internal MPI storage. E.g.: INTEGER foo = 4 INTEGER bar CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) foo = 5 CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) bar should equal 4, not 5 (right?). So what does that mean (or imply) about the EXTRA_STATE value passed to the Fortran callbacks? -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Thu Apr 16 09:34:34 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 16 Apr 2009 10:34:34 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: <84F7D41C-FE3B-4AEB-93A5-A7BEB9F1A398@cisco.com> On Apr 16, 2009, at 10:29 AM, Solt, David George wrote: > HP-MPI does #2. > > What if the address of the variable originally passed in is no > longer in scope when the corresponding comm_get_attr call is made? > Ya, that can be a problem. Do you have an internal copy of the Intel MPI tests? What does MPI_KEYVAL1_F do? Ours checks that the value of a global variable has been changed by the callbacks. I think that's why we coded it up in Open MPI this way, but I'm not sure (that was a long time ago). -- Jeff Squyres Cisco Systems From ritzdorf at [hidden] Thu Apr 16 10:15:05 2009 From: ritzdorf at [hidden] (Hubert Ritzdorf) Date: Thu, 16 Apr 2009 17:15:05 +0200 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <5757270D-63D6-4FCB-AADB-59847B3A1C75@cisco.com> Message-ID: <49E74B79.5030600@it.neclab.eu> Hi, NEC MPI uses #1 approach (such as for mpi_register_datarep and mpi_grequest_start). I assume that #2 is more in the Fortran spirit. Hubert Jeff Squyres wrote: > This is related to -- but different from -- MPI 2.2 ticket #55 > ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly > adding all the #55 CC members to this mail, plus a few others. > > I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific > behavior regarding the EXTRA_STATE arguments passed to the Fortran > keyval copy and delete functions (both the ADDRESS_KIND and deprecated > flavors). I see two choices: > > 1. pass the user's original EXTRA_STATE argument by reference to the > callbacks, or > 2. copy the user's original EXTRA_STATE into internal MPI storage and > pass *that* value by reference to the callbacks > > ==> Open MPI currently does #1. What do other implementations do? > > I raise this issue because the text does not indicate which way is > right. And I just ran across an old Sun test that assumed #2. But > our internal copy of the Intel MPI tests assume #1 (to be fair: I have > no idea if the Intel tests originally assumed #2 and we changed them > to #1 over time). Indeed, #2 is actually in-line with the philosophy > of storing attribute values in internal MPI storage. E.g.: > > INTEGER foo = 4 > INTEGER bar > CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) > foo = 5 > CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) > > bar should equal 4, not 5 (right?). > > So what does that mean (or imply) about the EXTRA_STATE value passed > to the Fortran callbacks? > > --Jeff Squyres > Cisco Systems > * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From david.solt at [hidden] Thu Apr 16 16:09:39 2009 From: david.solt at [hidden] (Solt, David George) Date: Thu, 16 Apr 2009 21:09:39 +0000 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <84F7D41C-FE3B-4AEB-93A5-A7BEB9F1A398@cisco.com> Message-ID: We do have an internal copy of the Intel MPI tests. We also down loaded a more recent copy for comparison. In both cases I do not see code in MPI_KEYVAL1_F that would differentiate between the two interpretations. All of the tests seem to follow the following general pattern: INTEGER ATTR = MPIKEYVAL_ME .... CALL MPI_COMM_SET_ATTR(comm, keyval, ATTR, ierr) .... .... CALL MPI_COMM_GET_ATTR(comm, keyval, ATTR, flag, ierr) Dave -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 9:35 AM To: Solt, David George Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge Subject: Re: Another MPI-2.2 attribute ambiguity? On Apr 16, 2009, at 10:29 AM, Solt, David George wrote: > HP-MPI does #2. > > What if the address of the variable originally passed in is no longer > in scope when the corresponding comm_get_attr call is made? > Ya, that can be a problem. Do you have an internal copy of the Intel MPI tests? What does MPI_KEYVAL1_F do? Ours checks that the value of a global variable has been changed by the callbacks. I think that's why we coded it up in Open MPI this way, but I'm not sure (that was a long time ago). -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Thu Apr 16 16:14:28 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 16 Apr 2009 17:14:28 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: <3151B7ED-79D6-468C-BB31-79BFE46FE881@cisco.com> What about when you call COMM_DUP? That's when the COPY callback will be invoked. In my copy of MPI_Keyval1_f.F, in COPY_FUNCTION1, it does the following: EXTRA_STATE = EXTRA_STATE + 1 And then later in the application, it checks the value of EXTRA1 to see if it was incremented to 3 (by calling COPY_FUNCTION1 3 times). Hence, it's assuming that EXTRA_STATE in COPY_FUNCTION1 is really a reference to a global variable -- not a pointer to internal MPI state. Does yours not do that? On Apr 16, 2009, at 5:09 PM, Solt, David George wrote: > We do have an internal copy of the Intel MPI tests. We also down > loaded a more recent copy for comparison. In both cases I do not > see code in MPI_KEYVAL1_F that would differentiate between the two > interpretations. All of the tests seem to follow the following > general pattern: > > INTEGER ATTR = MPIKEYVAL_ME > .... > CALL MPI_COMM_SET_ATTR(comm, keyval, ATTR, ierr) > .... > > .... > CALL MPI_COMM_GET_ATTR(comm, keyval, ATTR, flag, ierr) > > > > Dave > > -----Original Message----- > From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > Sent: Thursday, April 16, 2009 9:35 AM > To: Solt, David George > Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert > Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; > Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge > Subject: Re: Another MPI-2.2 attribute ambiguity? > > On Apr 16, 2009, at 10:29 AM, Solt, David George wrote: > > > HP-MPI does #2. > > > > What if the address of the variable originally passed in is no > longer > > in scope when the corresponding comm_get_attr call is made? > > > > Ya, that can be a problem. > > Do you have an internal copy of the Intel MPI tests? What does > MPI_KEYVAL1_F do? Ours checks that the value of a global variable has > been changed by the callbacks. > > I think that's why we coded it up in Open MPI this way, but I'm not > sure (that was a long time ago). > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems From david.solt at [hidden] Thu Apr 16 16:51:58 2009 From: david.solt at [hidden] (Solt, David George) Date: Thu, 16 Apr 2009 21:51:58 +0000 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <3151B7ED-79D6-468C-BB31-79BFE46FE881@cisco.com> Message-ID: Yes, I was focused on ATTR and not the extra_state aspect. It looks like we did modify the Intel test suite in this case. We basically included our own method to count the number of times the callback was called and did not use the EXTRA_STATE "feature" as a method to do this. So, you are correct that the Intel test suite (unmodified) will fail with approach #2. Apparently, our founding fathers here on HP-MPI believed very strongly that the Intel test was bogus and we were doing the right thing. Dave -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 4:14 PM To: Solt, David George Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge Subject: Re: Another MPI-2.2 attribute ambiguity? What about when you call COMM_DUP? That's when the COPY callback will be invoked. In my copy of MPI_Keyval1_f.F, in COPY_FUNCTION1, it does the following: EXTRA_STATE = EXTRA_STATE + 1 And then later in the application, it checks the value of EXTRA1 to see if it was incremented to 3 (by calling COPY_FUNCTION1 3 times). Hence, it's assuming that EXTRA_STATE in COPY_FUNCTION1 is really a reference to a global variable -- not a pointer to internal MPI state. Does yours not do that? On Apr 16, 2009, at 5:09 PM, Solt, David George wrote: > We do have an internal copy of the Intel MPI tests. We also down > loaded a more recent copy for comparison. In both cases I do not > see code in MPI_KEYVAL1_F that would differentiate between the two > interpretations. All of the tests seem to follow the following > general pattern: > > INTEGER ATTR = MPIKEYVAL_ME > .... > CALL MPI_COMM_SET_ATTR(comm, keyval, ATTR, ierr) .... > > .... > CALL MPI_COMM_GET_ATTR(comm, keyval, ATTR, flag, ierr) > > > > Dave > > -----Original Message----- > From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > Sent: Thursday, April 16, 2009 9:35 AM > To: Solt, David George > Cc: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert > Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; > Alexander Supalov; Bronis de Supinski; Hans Westgaard Ry; Håkon Bugge > Subject: Re: Another MPI-2.2 attribute ambiguity? > > On Apr 16, 2009, at 10:29 AM, Solt, David George wrote: > > > HP-MPI does #2. > > > > What if the address of the variable originally passed in is no > longer > > in scope when the corresponding comm_get_attr call is made? > > > > Ya, that can be a problem. > > Do you have an internal copy of the Intel MPI tests? What does > MPI_KEYVAL1_F do? Ours checks that the value of a global variable has > been changed by the callbacks. > > I think that's why we coded it up in Open MPI this way, but I'm not > sure (that was a long time ago). > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems From alexander.supalov at [hidden] Fri Apr 17 07:59:09 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 17 Apr 2009 13:59:09 +0100 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <5757270D-63D6-4FCB-AADB-59847B3A1C75@cisco.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E941E1070@irsmsx504.ger.corp.intel.com> Hi, Intel MPI (and most likely other MPICH2 derivatives) appears to use method #2. Best regards. Alexander -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Thursday, April 16, 2009 4:19 PM To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; Supalov, Alexander; Bronis de Supinski; David Solt; Hans Westgaard Ry; Håkon Bugge Subject: Another MPI-2.2 attribute ambiguity? This is related to -- but different from -- MPI 2.2 ticket #55 ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly adding all the #55 CC members to this mail, plus a few others. I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific behavior regarding the EXTRA_STATE arguments passed to the Fortran keyval copy and delete functions (both the ADDRESS_KIND and deprecated flavors). I see two choices: 1. pass the user's original EXTRA_STATE argument by reference to the callbacks, or 2. copy the user's original EXTRA_STATE into internal MPI storage and pass *that* value by reference to the callbacks ==> Open MPI currently does #1. What do other implementations do? I raise this issue because the text does not indicate which way is right. And I just ran across an old Sun test that assumed #2. But our internal copy of the Intel MPI tests assume #1 (to be fair: I have no idea if the Intel tests originally assumed #2 and we changed them to #1 over time). Indeed, #2 is actually in-line with the philosophy of storing attribute values in internal MPI storage. E.g.: INTEGER foo = 4 INTEGER bar CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) foo = 5 CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) bar should equal 4, not 5 (right?). So what does that mean (or imply) about the EXTRA_STATE value passed to the Fortran callbacks? -- Jeff Squyres Cisco Systems --------------------------------------------------------------------- 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. From jsquyres at [hidden] Fri Apr 17 08:14:40 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 17 Apr 2009 09:14:40 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E941E1070@irsmsx504.ger.corp.intel.com> Message-ID: Someone pointed out to me this morning that there's no restriction on the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may be an expression, for example. I think that pretty much seals the deal that #2 is the correct way. I think that this is worth an ATI in the text; does anyone disagree? I volunteer to write it up/make a 3.0 ticket (hey, first ticket for the Misc WG! :-) ) if no one disagrees. On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: > Hi, > > Intel MPI (and most likely other MPICH2 derivatives) appears to use > method #2. > > Best regards. > > Alexander > > -----Original Message----- > From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > Sent: Thursday, April 16, 2009 4:19 PM > To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert > Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; > Supalov, Alexander; Bronis de Supinski; David Solt; Hans Westgaard > Ry; Håkon Bugge > Subject: Another MPI-2.2 attribute ambiguity? > > This is related to -- but different from -- MPI 2.2 ticket #55 > ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly > adding all the #55 CC members to this mail, plus a few others. > > I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific > behavior regarding the EXTRA_STATE arguments passed to the Fortran > keyval copy and delete functions (both the ADDRESS_KIND and deprecated > flavors). I see two choices: > > 1. pass the user's original EXTRA_STATE argument by reference to the > callbacks, or > 2. copy the user's original EXTRA_STATE into internal MPI storage and > pass *that* value by reference to the callbacks > > ==> Open MPI currently does #1. What do other implementations do? > > I raise this issue because the text does not indicate which way is > right. And I just ran across an old Sun test that assumed #2. But > our internal copy of the Intel MPI tests assume #1 (to be fair: I have > no idea if the Intel tests originally assumed #2 and we changed them > to #1 over time). Indeed, #2 is actually in-line with the philosophy > of storing attribute values in internal MPI storage. E.g.: > > INTEGER foo = 4 > INTEGER bar > CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) > foo = 5 > CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) > > bar should equal 4, not 5 (right?). > > So what does that mean (or imply) about the EXTRA_STATE value passed > to the Fortran callbacks? > > -- > Jeff Squyres > Cisco Systems > > --------------------------------------------------------------------- > 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. > > -- Jeff Squyres Cisco Systems From wgropp at [hidden] Fri Apr 17 08:40:24 2009 From: wgropp at [hidden] (William Gropp) Date: Fri, 17 Apr 2009 08:40:24 -0500 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: <953834BC-6A9D-4458-9FCA-D9ECC53D71D9@illinois.edu> Yes, this is worth an ATI - the fact that we traded this much mail on it is proof of that :) Thanks, Jeff. Bill On Apr 17, 2009, at 8:14 AM, Jeff Squyres wrote: > Someone pointed out to me this morning that there's no restriction on > the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may be an > expression, for example. I think that pretty much seals the deal that > #2 is the correct way. > > I think that this is worth an ATI in the text; does anyone disagree? > I volunteer to write it up/make a 3.0 ticket (hey, first ticket for > the Misc WG! :-) ) if no one disagrees. > > > On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: > >> Hi, >> >> Intel MPI (and most likely other MPICH2 derivatives) appears to use >> method #2. >> >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: Jeff Squyres [mailto:jsquyres_at_[hidden]] >> Sent: Thursday, April 16, 2009 4:19 PM >> To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; Hubert >> Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan Balaji; >> Supalov, Alexander; Bronis de Supinski; David Solt; Hans Westgaard >> Ry; Håkon Bugge >> Subject: Another MPI-2.2 attribute ambiguity? >> >> This is related to -- but different from -- MPI 2.2 ticket #55 >> ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly >> adding all the #55 CC members to this mail, plus a few others. >> >> I cannot find any text in MPI-2.1 (e.g., p223-225) describing >> specific >> behavior regarding the EXTRA_STATE arguments passed to the Fortran >> keyval copy and delete functions (both the ADDRESS_KIND and >> deprecated >> flavors). I see two choices: >> >> 1. pass the user's original EXTRA_STATE argument by reference to the >> callbacks, or >> 2. copy the user's original EXTRA_STATE into internal MPI storage and >> pass *that* value by reference to the callbacks >> >> ==> Open MPI currently does #1. What do other implementations do? >> >> I raise this issue because the text does not indicate which way is >> right. And I just ran across an old Sun test that assumed #2. But >> our internal copy of the Intel MPI tests assume #1 (to be fair: I >> have >> no idea if the Intel tests originally assumed #2 and we changed them >> to #1 over time). Indeed, #2 is actually in-line with the philosophy >> of storing attribute values in internal MPI storage. E.g.: >> >> INTEGER foo = 4 >> INTEGER bar >> CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) >> foo = 5 >> CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) >> >> bar should equal 4, not 5 (right?). >> >> So what does that mean (or imply) about the EXTRA_STATE value passed >> to the Fortran callbacks? >> >> -- >> Jeff Squyres >> Cisco Systems >> >> --------------------------------------------------------------------- >> 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. >> >> > > > -- > Jeff Squyres > Cisco Systems > 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 From jsquyres at [hidden] Fri Apr 17 09:21:54 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 17 Apr 2009 10:21:54 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <953834BC-6A9D-4458-9FCA-D9ECC53D71D9@illinois.edu> Message-ID: Ok, I'll file an MPI-3 ticket for this. (for everyone else on the 2.2 list wondering why you just got blitzkrieged with a whole pile of emails on this topic: the listserver sent all these mails to moderation because of the lengthy CC list. IU just approved all the mails to go through this morning) On Apr 17, 2009, at 9:40 AM, William Gropp wrote: > Yes, this is worth an ATI - the fact that we traded this much mail on > it is proof of that :) > > Thanks, Jeff. > > Bill > > On Apr 17, 2009, at 8:14 AM, Jeff Squyres wrote: > > > Someone pointed out to me this morning that there's no restriction > on > > the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may > be an > > expression, for example. I think that pretty much seals the deal > that > > #2 is the correct way. > > > > I think that this is worth an ATI in the text; does anyone disagree? > > I volunteer to write it up/make a 3.0 ticket (hey, first ticket for > > the Misc WG! :-) ) if no one disagrees. > > > > > > On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: > > > >> Hi, > >> > >> Intel MPI (and most likely other MPICH2 derivatives) appears to use > >> method #2. > >> > >> Best regards. > >> > >> Alexander > >> > >> -----Original Message----- > >> From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > >> Sent: Thursday, April 16, 2009 4:19 PM > >> To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; > Hubert > >> Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan > Balaji; > >> Supalov, Alexander; Bronis de Supinski; David Solt; Hans Westgaard > >> Ry; Håkon Bugge > >> Subject: Another MPI-2.2 attribute ambiguity? > >> > >> This is related to -- but different from -- MPI 2.2 ticket #55 > >> ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly > >> adding all the #55 CC members to this mail, plus a few others. > >> > >> I cannot find any text in MPI-2.1 (e.g., p223-225) describing > >> specific > >> behavior regarding the EXTRA_STATE arguments passed to the Fortran > >> keyval copy and delete functions (both the ADDRESS_KIND and > >> deprecated > >> flavors). I see two choices: > >> > >> 1. pass the user's original EXTRA_STATE argument by reference to > the > >> callbacks, or > >> 2. copy the user's original EXTRA_STATE into internal MPI storage > and > >> pass *that* value by reference to the callbacks > >> > >> ==> Open MPI currently does #1. What do other implementations do? > >> > >> I raise this issue because the text does not indicate which way is > >> right. And I just ran across an old Sun test that assumed #2. But > >> our internal copy of the Intel MPI tests assume #1 (to be fair: I > >> have > >> no idea if the Intel tests originally assumed #2 and we changed > them > >> to #1 over time). Indeed, #2 is actually in-line with the > philosophy > >> of storing attribute values in internal MPI storage. E.g.: > >> > >> INTEGER foo = 4 > >> INTEGER bar > >> CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) > >> foo = 5 > >> CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) > >> > >> bar should equal 4, not 5 (right?). > >> > >> So what does that mean (or imply) about the EXTRA_STATE value > passed > >> to the Fortran callbacks? > >> > >> -- > >> Jeff Squyres > >> Cisco Systems > >> > >> > --------------------------------------------------------------------- > >> 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. > >> > >> > > > > > > -- > > Jeff Squyres > > Cisco Systems > > > > 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 > > > > -- Jeff Squyres Cisco Systems