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

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

03 Apr '09

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

1 0

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

03 Apr '09

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

1 0

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

03 Apr '09

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: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/ >> 59#comment:33 >>> >> MPI Forum <https://svn.mpi-forum.org/> >> MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 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.

1 0

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

03 Apr '09

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: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/ >> 59#comment:33 >>> >> MPI Forum <https://svn.mpi-forum.org/> >> MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

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

03 Apr '09

This is worth raising to the list. What is the rule for 2.2 -- that existing MPI applications must be able to run with no changes against an MPI-2.2 library? Or is it that existing MPI applications must be able to compile and run with no source code changes against an MPI-2.2 implementation? I hope it's the latter; this change is relatively important. On Apr 3, 2009, at 5:56 AM, MPI Forum wrote: > #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > ----------------------------------- > +---------------------------------------- > Reporter: hubertritzdorf | Owner: hubertritzdorf > Type: Correction to standard | Status: new > Priority: Waiting for reviews | Milestone: 2009/04/06 > Chicago > Version: MPI 2.2 | Resolution: > Keywords: | Implementation: Completed > ----------------------------------- > +---------------------------------------- > Changes (by asupalov): > > * cc: alexander.supalov_at_[hidden] (added) > > > Comment: > > Aren't we changing C++ ABI herewith? If so, we may want to postpone > this > change till MPI-3. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/59#comment:33 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Non-collective reductions: MPI_Op_reduce
by unknown＠example.com 03 Apr '09

03 Apr '09

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 > <ATT9968668.dat>_______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Non-collective reductions: MPI_Op_reduce
by unknown＠example.com 03 Apr '09

03 Apr '09

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 *

1 0

Re: [Mpi-22] Non-collective reductions: MPI_Op_reduce
by unknown＠example.com 03 Apr '09

03 Apr '09

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

1 0

Non-collective reductions: MPI_Op_reduce
by unknown＠example.com 03 Apr '09

03 Apr '09

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 *

1 0

Re: [Mpi-22] [MPI Forum] #71: Add routine for registering callback when finalize occurs
by unknown＠example.com 02 Apr '09

02 Apr '09

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: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71#comment:17 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0