- Mpi3-bwcompat - mailman3.cels.anl.gov

Re: [Mpi3-bwcompat] Plan for MPI_Count
by unknown＠example.com 07 Mar '11

07 Mar '11

>> - Dave will send a final PDF to the bwcompat group to review early next week I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? Thanks, Dave

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 07 Mar '11

07 Mar '11

Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 > > Dave's point about generalized requests is a good one, though -- I need to go > think about that and convince myself that what we're talking about isn't > syntactic sugar and/or why it's better to be in the MPI implementation. In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. -Fab

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 07 Mar '11

07 Mar '11

On Mar 7, 2011, at 7:04 AM, Supalov, Alexander wrote: > The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? Yes, timers will work anywhere -- they're requests, like any other request. So you can use them with any MPI_WAIT* / MPI_TEST* functions. As I understand it, the FT group has some internal proposals about non-blocking spawn, connect, accept, etc. Our idea here was to minimally impact other, existing parts of MPI. A timer request is a standalone item; it can complete independent of any other request (e.g., a non-blocking p2p or collective communication, spawn, accept, connect, ..etc.). As Fab stated, completion of a timer intentionally has no other connotation about other incomplete actions. Dave's point about generalized requests is a good one, though -- I need to go think about that and convince myself that what we're talking about isn't syntactic sugar and/or why it's better to be in the MPI implementation. -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 07 Mar '11

07 Mar '11

What you are proposing amounts to a built-in version of "MPI_Cancel-after-timeout". So at the very least it has all of the downsides associated with cancel (esp. for send operations). It has the additional downside of forcing the MPI implementation to check all pending requests (that contain a timeout) for expiration. Other than my general dislike of message cancellation, I don't currently have a specific concern at this point, provided that the wording is sufficiently vague to permit timeout firing to be _very_ delayed. The multithreaded receive queue design that we sometimes use on Blue Gene would not permit this sort of cancellation in a timely fashion because it uses an additional, separate "fast post" queue in order to maximize message rate. Forcing timely timeouts would likely negate most of the performance benefit from such a design. Is there a good application use case for this functionality? Or is this just something amusing that is theoretically useful? -Dave On Mar 7, 2011, at 10:17 AM CST, Supalov, Alexander wrote: > Can you give an example of the impact you're indicating? On an afterthought there may be an atomicity issue with the postconditioning. Shouldn't be a big problem though: if the message has matched, attaching a timeout to it will effectively be a no-op. Is your concern going in a comparable direction? Like, what happens if the message is matched just before the timeout fires, or vice versa? > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Monday, March 07, 2011 4:28 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI timer requests > > What would be the impact of such a proposal on message matching and ordering semantics? I suspect this would make developing an efficient receive queue implementation even more difficult than it already is. > > -Dave > > On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote: > >> Hi, >> >> The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? >> >> As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": >> >> MPI_Isend(..., &req); >> MPI_Timer_set(MPI_Wtime() + 5, &req); >> ... >> MPI_Wait(&req); >> >> Or, for "preconditioning": >> >> MPI_Timer_create(MPI_Wtime() + 5, &req); >> MPI_Isend(..., &req); >> ... >> MPI_Wait(&req); >> >> The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? >> >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell >> Sent: Friday, March 04, 2011 10:21 PM >> To: MPI-3 backwards compatability WG >> Subject: Re: [Mpi3-bwcompat] MPI timer requests >> >> I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. >> >> I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. >> >> -Dave >> >> On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: >> >>> All -- >>> >>> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. >>> >>> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers >>> >>> Thanks! >>> >>> -- >>> Jeff Squyres >>> jsquyres_at_[hidden] >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> Mpi3-bwcompat mailing list >>> Mpi3-bwcompat_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> -------------------------------------------------------------------------------------- >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland >> 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 a.M. (BLZ 502 109 00) 600119052 >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > 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 a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 07 Mar '11

07 Mar '11

Hi Alexander, Your idea of post-conditioning a request wouldn't require any changes to existing APIs - I like it. The pre-conditioning however would make the request parameter inout to all functions that currently return one, which would break backward compatibility (users would need to initialize all input requests to MPI_REQUEST_NULL if they didn't have a pre-conditioned request). If you associate a timeout with individual requests, what happens to a request when it times out? Does it complete in error? Is it complete at all, or does the wait function simply return? One of the reasons for having separate timer requests rather than adding a timeout to existing requests is that the timeout condition remains completely local and doesn't indicate anything about outstanding I/O request. This leaves it up to the application to figure out how to handle the timeout. If an error, a send request could be cancelled, for example. Thanks, -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 07, 2011 4:05 AM Hi, The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": MPI_Isend(..., &req); MPI_Timer_set(MPI_Wtime() + 5, &req); ... MPI_Wait(&req); Or, for "preconditioning": MPI_Timer_create(MPI_Wtime() + 5, &req); MPI_Isend(..., &req); ... MPI_Wait(&req); The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? Best regards. Alexander -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Friday, March 04, 2011 10:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. -Dave On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > All -- > > Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. > > We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. > > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers > > Thanks! > > -- > Jeff Squyres > jsquyres_at_[hidden] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052 _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Fwd: [Mpi-forum] MPI_Count ticket
by unknown＠example.com 07 Mar '11

07 Mar '11

Great -- this is very helpful. Thanks for the explanation! On Mar 5, 2011, at 10:20 AM, William Gropp wrote: > Jeff, > > I think you should go ahead with the reading. If the chapter authors don't find anything (other than trivial items), then you are good to go. If they do, well, the reading will be useful anyway. Review by the chapter authors should not be *required* before a *reading*. It is required before the first vote. > > Bill > > On Mar 4, 2011, at 4:46 PM, Jeff Squyres wrote: > >> Bwcompat WG -- >> >> I'm kinda thinking that this means we won't be able to have a first reading= >> by next meeting. Getting reviews by the chapter authors takes time... >> >> >> Begin forwarded message: >> >>> From: William Gropp <wgropp_at_[hidden]> >>> Date: March 4, 2011 5:41:07 PM EST >>> To: Main MPI Forum mailing list <mpi-forum_at_[hidden]> >>> Subject: Re: [Mpi-forum] MPI_Count ticket >>> Reply-To: Main MPI Forum mailing list <mpi-forum_at_[hidden]> >>> =20 >>> Changes to the other chapters require at least the chapter author's revie= >> w. They should do whatever they need to do to ensure that the changes make= >> sense (so that roughly means they should review the whole ticket). >>> =20 >>> It would be good if they're done by the first reading. If they find some= >> thing that needs to be changed, other than something that meets everyone's = >> definition of a trivial change, then you'd need to fix it and have a new fi= >> rst reading. >>> =20 >>> Bill >>> =20 >>> On Mar 4, 2011, at 1:05 PM, Jeff Squyres wrote: >>> =20 >>>> Forum -- >>>> =20 >>>> Sorry; I know we've discussed this a number of times, but they've all go= >> tten jumbled in my head and I don't remember what was decided. >>>> =20 >>>> We are bringing the MPI_Count ticket to the Forum for a first reading in= >> Chicago. Unfortunately, this ticket will span a bunch of chapters (5 or 6= >> , I think). >>>> =20 >>>> Do we have to get the individual sections of text reviewed by each chapt= >> er committee? And are they expected to review the *whole* ticket, and then= >> double check/review it in the context of *their specific chapter*? (I ask= >> because the text in one chapter doesn't really make sense without the rest= >> of the text in the ticket) >>>> =20 >>>> If we do need reviews from each chapter committee, do they need to be co= >> mplete by the first reading? >>>> =20 >>>> --=20 >>>> Jeff Squyres >>>> jsquyres_at_[hidden] >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> =20 >>>> =20 >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> =20 >>> 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 >>> =20 >>> =20 >>> =20 >>> =20 >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> --=20 >> Jeff Squyres >> jsquyres_at_[hidden] >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > 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 jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 07 Mar '11

07 Mar '11

Can you give an example of the impact you're indicating? On an afterthought there may be an atomicity issue with the postconditioning. Shouldn't be a big problem though: if the message has matched, attaching a timeout to it will effectively be a no-op. Is your concern going in a comparable direction? Like, what happens if the message is matched just before the timeout fires, or vice versa? -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Monday, March 07, 2011 4:28 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests What would be the impact of such a proposal on message matching and ordering semantics? I suspect this would make developing an efficient receive queue implementation even more difficult than it already is. -Dave On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote: > Hi, > > The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? > > As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": > > MPI_Isend(..., &req); > MPI_Timer_set(MPI_Wtime() + 5, &req); > ... > MPI_Wait(&req); > > Or, for "preconditioning": > > MPI_Timer_create(MPI_Wtime() + 5, &req); > MPI_Isend(..., &req); > ... > MPI_Wait(&req); > > The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? > > Best regards. > > Alexander > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Friday, March 04, 2011 10:21 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI timer requests > > I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. > > I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. > > -Dave > > On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > >> All -- >> >> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. >> >> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers >> >> Thanks! >> >> -- >> Jeff Squyres >> jsquyres_at_[hidden] >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > 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 a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 07 Mar '11

07 Mar '11

What would be the impact of such a proposal on message matching and ordering semantics? I suspect this would make developing an efficient receive queue implementation even more difficult than it already is. -Dave On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote: > Hi, > > The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? > > As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": > > MPI_Isend(..., &req); > MPI_Timer_set(MPI_Wtime() + 5, &req); > ... > MPI_Wait(&req); > > Or, for "preconditioning": > > MPI_Timer_create(MPI_Wtime() + 5, &req); > MPI_Isend(..., &req); > ... > MPI_Wait(&req); > > The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? > > Best regards. > > Alexander > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Friday, March 04, 2011 10:21 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI timer requests > > I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. > > I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. > > -Dave > > On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > >> All -- >> >> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. >> >> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers >> >> Thanks! >> >> -- >> Jeff Squyres >> jsquyres_at_[hidden] >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > 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 a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] MPI timer requests
by unknown＠example.com 07 Mar '11

07 Mar '11

Hi, The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": MPI_Isend(..., &req); MPI_Timer_set(MPI_Wtime() + 5, &req); ... MPI_Wait(&req); Or, for "preconditioning": MPI_Timer_create(MPI_Wtime() + 5, &req); MPI_Isend(..., &req); ... MPI_Wait(&req); The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? Best regards. Alexander -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Friday, March 04, 2011 10:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. -Dave On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > All -- > > Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. > > We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers > > Thanks! > > -- > Jeff Squyres > jsquyres_at_[hidden] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052

1 0

Re: [Mpi3-bwcompat] Fwd: [Mpi-forum] MPI_Count ticket
by unknown＠example.com 05 Mar '11

05 Mar '11

Jeff, I think you should go ahead with the reading. If the chapter authors don't find anything (other than trivial items), then you are good to go. If they do, well, the reading will be useful anyway. Review by the chapter authors should not be *required* before a *reading*. It is required before the first vote. Bill On Mar 4, 2011, at 4:46 PM, Jeff Squyres wrote: > Bwcompat WG -- > > I'm kinda thinking that this means we won't be able to have a first > reading= > by next meeting. Getting reviews by the chapter authors takes time... > > > Begin forwarded message: > >> From: William Gropp <wgropp_at_[hidden]> >> Date: March 4, 2011 5:41:07 PM EST >> To: Main MPI Forum mailing list <mpi-forum_at_[hidden]> >> Subject: Re: [Mpi-forum] MPI_Count ticket >> Reply-To: Main MPI Forum mailing list <mpi-forum_at_[hidden]> >> =20 >> Changes to the other chapters require at least the chapter author's >> revie= > w. They should do whatever they need to do to ensure that the > changes make= > sense (so that roughly means they should review the whole ticket). >> =20 >> It would be good if they're done by the first reading. If they >> find some= > thing that needs to be changed, other than something that meets > everyone's = > definition of a trivial change, then you'd need to fix it and have a > new fi= > rst reading. >> =20 >> Bill >> =20 >> On Mar 4, 2011, at 1:05 PM, Jeff Squyres wrote: >> =20 >>> Forum -- >>> =20 >>> Sorry; I know we've discussed this a number of times, but they've >>> all go= > tten jumbled in my head and I don't remember what was decided. >>> =20 >>> We are bringing the MPI_Count ticket to the Forum for a first >>> reading in= > Chicago. Unfortunately, this ticket will span a bunch of chapters > (5 or 6= > , I think). >>> =20 >>> Do we have to get the individual sections of text reviewed by each >>> chapt= > er committee? And are they expected to review the *whole* ticket, > and then= > double check/review it in the context of *their specific chapter*? > (I ask= > because the text in one chapter doesn't really make sense without > the rest= > of the text in the ticket) >>> =20 >>> If we do need reviews from each chapter committee, do they need to >>> be co= > mplete by the first reading? >>> =20 >>> --=20 >>> Jeff Squyres >>> jsquyres_at_[hidden] >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> =20 >>> =20 >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> =20 >> 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 >> =20 >> =20 >> =20 >> =20 >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > --=20 > Jeff Squyres > jsquyres_at_[hidden] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat 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