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

Additional Reviews for ticket #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL
by unknown＠example.com 30 Mar '09

30 Mar '09

Hi, I'm looking for 2 additional reviews for Ticket #59. If there is additional interest to clarify the status of MPI::FILE_NULL and MPI::WIN_NULL and if you are interested to have the predefined C++ datatypes const-qualified again, please review ticket 59 (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/59) Many thanks in advance Hubert *

1 0

Fw: Ticket #71: Add routine for registering callback when finalize occurs
by unknown＠example.com 30 Mar '09

30 Mar '09

I should have said LIFO below. The proposal is to have attribute deletion callback occur in the reverse of the order in which they were placed. I have no objection to making this part of the standard but do not think it should be unique to MPI_COMM_SELF if we adopt it. 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 ----- Forwarded by Richard Treumann/Poughkeepsie/IBM on 03/30/2009 02:49 PM ----- From: Richard Treumann/Poughkeepsie/IBM_at_IBMUS To: "MPI 2.2" <mpi-22_at_[hidden]> Date: 03/30/2009 10:12 AM Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs 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 <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: > > <OFE2F8673A.D3771BE2- > > 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 > >

1 0

Re: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs
by unknown＠example.com 30 Mar '09

30 Mar '09

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 <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: > > <OFE2F8673A.D3771BE2- > > 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 > >

1 0

Re: [Mpi-22] Ticket #33: Fix Scalability Issues in Graph Topology Interface
by unknown＠example.com 29 Mar '09

29 Mar '09

Hello, > We need more people reviewing this ticket to see if this is the right way to > fix the scalability problem with graph topologies. Among the new features > proposed in 2.2, it is a significant one and is not trivial to understand > and vote on unless you have studied it beforehand. > > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/33 thanks Rajeev! We already had multiple reviews and constructive discussions about this ticket. The meeting is coming closer and we would like to receive more comments from a broader audience. As Rajeev already mentioned, this ticket is significant and a very important bugfix in scope of MPI-2.2. The ticket is also an important prepration for some efforts in the collective working group for MPI-3 (sparse collectives). Please read the ticket and participate in the discussions! A separate discussion is, that this ticket (optionally) proposed to deprecate the old non-scalable graph interface. Deprecating features in MPI-2.2 received little discussion so far. Due to the complexity and importance of this issue, I would like to ask for some time where the full forum collectively reviews and discusses this ticket in the style that we did nonblocking collective operations (I think we can "donate" time from the collective WG and/or the planned MPI-3 vote). Given the shortness of time and the procedural requirements of MPI-2.2, this should be done during the first day if the meeting. The ticket has been around for six months and was (briefly) discussed during each meeting, thus, I assume that most participants are familiar with the issue. Thanks & All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Postdoctoral Researcher Open Systems Lab | Indiana University 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA Lindley Hall Room 135 | +01 (812) 855-3608

1 0

Re: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs
by unknown＠example.com 28 Mar '09

28 Mar '09

> Date: Thu, 26 Mar 2009 13:24:26 -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: > <OFE2F8673A.D3771BE2- > 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 >

1 0

Re: [Mpi-22] Ordering guarantees and multiple threads
by unknown＠example.com 27 Mar '09

27 Mar '09

The standard already says: If a sender sends two messages in succession to the same destination, and both match the same receive, then this operation cannot receive the second message if the first one is still pending. If a receiver posts two receives in succession, and both match the same message, then the second receive operation cannot be satisfied by this message, if the first one is still pending. This requirement facilitates matching of sends to receives. It guarantees that message-passing code is deterministic, I think that already provides the appropriate guarantee. Two concurrent threads making MPI calls do not provide any enforcement of "?succession" and the standard points this out to be helpful. It should not really have been necessary to say this. Explicit temporal ordering of actions on otherwise concurrent threads by an application is common and it is not the job of the MPI standard to say how this is to be done. MPI should probably only say in any situation where "?succession" is ambiguous, MPI makes no guarantee of disambiguation. Where "succession" is clear cut, MPI will reflect the succession order. 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/27/2009 01:25:29 PM: > [image removed] > > Re: [Mpi-22] Ordering guarantees and multiple threads > > Greg Bronevetsky > > to: > > MPI 2.2, MPI 2.2 > > 03/27/2009 01:27 PM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > At 09:35 AM 3/27/2009, Darius Buntinas wrote: > > >I've just created a ticket: > > https:// svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 > >to suggest that we strengthen the ordering guarantees between sends (and > >receives) from different threads. > > > >I think that the real question here is whether the potential benefit to > >the user outweighs the potential for optimization in a multithreaded > >implementation. > > > >Please have a look at it and feel free to comment. > > I like the spirit of this proposal but in practice it will be hard to > specify. In particular, consider the sentence "two sends do not > overlap if the first MPI_Send() returns before the second MPI_Send() > is called". The word "before" here is only properly defined on a > sequentially consistent memory. On any other memory model "before" is > only defined by synchronization primitives supplied by the shared > memory system. As such, I don't know how to be precise about > something like "before" without talking about the shared memory > system. This will be hard because we'll need to talk about concepts > that all these systems share but for which they all provide different > primitives and semantics. I don't know how the wider forum will react > to such a specification. However, I agree that something like this is > necessary. > > Greg Bronevetsky > Post-Doctoral Researcher > 1028 Building 451 > Lawrence Livermore National Lab > (925) 424-5756 > bronevetsky1_at_[hidden] > http://greg.bronevetsky.com > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Re: [Mpi-22] Ordering guarantees and multiple threads
by unknown＠example.com 27 Mar '09

27 Mar '09

At 09:35 AM 3/27/2009, Darius Buntinas wrote: >I've just created a ticket: > https:// svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 >to suggest that we strengthen the ordering guarantees between sends (and >receives) from different threads. > >I think that the real question here is whether the potential benefit to >the user outweighs the potential for optimization in a multithreaded >implementation. > >Please have a look at it and feel free to comment. I like the spirit of this proposal but in practice it will be hard to specify. In particular, consider the sentence "two sends do not overlap if the first MPI_Send() returns before the second MPI_Send() is called". The word "before" here is only properly defined on a sequentially consistent memory. On any other memory model "before" is only defined by synchronization primitives supplied by the shared memory system. As such, I don't know how to be precise about something like "before" without talking about the shared memory system. This will be hard because we'll need to talk about concepts that all these systems share but for which they all provide different primitives and semantics. I don't know how the wider forum will react to such a specification. However, I agree that something like this is necessary. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1_at_[hidden] http://greg.bronevetsky.com

1 0

Ordering guarantees and multiple threads
by unknown＠example.com 27 Mar '09

27 Mar '09

I've just created a ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 to suggest that we strengthen the ordering guarantees between sends (and receives) from different threads. I think that the real question here is whether the potential benefit to the user outweighs the potential for optimization in a multithreaded implementation. Please have a look at it and feel free to comment. Thanks, -d

1 0

Re: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs
by unknown＠example.com 26 Mar '09

26 Mar '09

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 *

1 0

Ticket #71: Add routine for registering callback when finalize occurs
by unknown＠example.com 26 Mar '09

26 Mar '09

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 *

1 0