December 2008 - mpiwg-coll - mailman3.cels.anl.gov

Re: [mpi3-coll] Official reading of NBC - Re: Notes from Telecon
by Torsten Hoefler 15 Dec '08

15 Dec '08

On Thu, Dec 11, 2008 at 01:00:09PM -0500, Torsten Hoefler wrote: > Rolf, > > is the proposal > > http://www.unixer.de/sec/nbc-proposal-11-26-2008.pdf > > and > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/NBColl/nbc-pro… > > the basis for the official reading of NBC on Wed 17, 10:30-11:30 > > at the MPI Forum meeting in San Francisco? > > yes! Please let me know if you have any suggestions or corrections. > > I will announce every change to the document on this list. I just updated the proposal with Jesper's face-to-face comments. The new version is in the wiki [1] and mirrored at [2]. It were mostly small changes in phrasing, the diff-file of the source that enumerates all changes is at [3]. The latest version will be used for the reading on Wednesday. Best, Torsten [1]: https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/NBColl/nbc-pro… [2]: http://www.unixer.de/sec/nbc-proposal-12-15-2008.pdf [3]: http://www.unixer.de/sec/nbc-proposal-12-15-2008.diff -- 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: [mpi3-coll] Official reading of NBC - Re: Notes from Telecon
by Torsten Hoefler 11 Dec '08

11 Dec '08

Rolf, > is the proposal > http://www.unixer.de/sec/nbc-proposal-11-26-2008.pdf > and > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/NBColl/nbc-pro… > the basis for the official reading of NBC on Wed 17, 10:30-11:30 > at the MPI Forum meeting in San Francisco? yes! Please let me know if you have any suggestions or corrections. I will announce every change to the document on this list. 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

[mpi3-coll] Official reading of NBC - Re: Notes from Telecon
by Rolf Rabenseifner 11 Dec '08

11 Dec '08

Torsten, is the proposal http://www.unixer.de/sec/nbc-proposal-11-26-2008.pdf and https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/NBColl/nbc-pro… the basis for the official reading of NBC on Wed 17, 10:30-11:30 at the MPI Forum meeting in San Francisco? Best regards Rolf On Wed, 26 Nov 2008 16:30:16 -0500 Torsten Hoefler <htor(a)cs.indiana.edu> wrote: > Hello, > I put my notes from today's teleconference at: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Telecon112608 > >Feel free to extend the page. I also updated the proposal document at > [1] and http://www.unixer.de/sec/nbc-proposal-11-26-2008.pdf > > I try to attach patchfiles to every update, so that it is easier for >you > to track changes (let me know if that helps). The first one is >attached > to this mail. > > Best, > Torsten > > [1]: >https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/NBColl/ > > -- > 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 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

[mpi3-coll] MPI 2.2 items for Collectives Chapter
by Adam Moody 05 Dec '08

05 Dec '08

Hello everyone, I'd like to make sure that we attempt to make progress on each item before the next meeting. If you own a ticket, could you please send a response with your ticket number? Torsten, do we have a list of the 2.2 items to be reviewed which fall in the collectives chapter? -Adam

1 0

Re: [mpi3-coll] Nonblocking collectives standard draft
by Torsten Hoefler 02 Dec '08

02 Dec '08

On Mon, Dec 01, 2008 at 07:36:10PM -0600, Rajeev Thakur wrote: > > However, if we do need to provide the above semantics for > > MPI_Cancel, we will have to deal with a funny non-locality of > > behavior. Suppose we have an MPI_Ibcast and one of the > > receivers calls MPI_Cancel. What happens to the other > > participants? Do they all have to call MPI_Cancel to not > > participate or is any one calling it sufficient? > > What about things like MPI_Gather and MPI_AlltoAll? We > > certainly don't want to force non-all-to-all operations to > > have to do an all-reduce at the end to check for cancellation. > > Yup, those are the issues that come up. One could say that MPI_Cancel is not > allowed for nonblocking collectives. That has already been said for exactly such reasons :). I guess Greg missed some of our discussions about this. The quintessence was that we should not allow MPI_Cancel for collective requests. This is also documented in the current standard proposal. 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: [mpi3-coll] Nonblocking collectives standard draft
by Rajeev Thakur 01 Dec '08

01 Dec '08

> At 01:39 PM 12/1/2008, Rajeev Thakur wrote: > >MPI_Cancel cannot simply be ignored. For example, if there is an > >MPI_Isend followed by MPI_Cancel, and the matching receive is never > >called, the cancel cannot fail. > > Are you sure that this is the way it works? It doesn't say so > explicitly in the spec and the notes for MPI_Cancel on > http://www-unix.mcs.anl.gov/mpi/www/ say "Cancel has only > been implemented for receive requests; it is a no-op for send > requests". Those are some old web pages from somewhere :-). The standard says on pg 67 "If a send is marked for cancellation, then it must be the case that either the send completes normally, in which case the message sent was received at the destination process, or that the send is successfully canceled, in which case no part of the message was received at the destination. Then, any matching receive has to be satisfied by another send." So if a send is cancelled, and the destination program doesn't ever call a matching receive, the implementation has to cancel the send; it can't simply say the cancel failed. Otherwise, MPI_Cancel would be the easiest call to implement (along with MPI_Pcontrol) :-). > However, if we do need to provide the above semantics for > MPI_Cancel, we will have to deal with a funny non-locality of > behavior. Suppose we have an MPI_Ibcast and one of the > receivers calls MPI_Cancel. What happens to the other > participants? Do they all have to call MPI_Cancel to not > participate or is any one calling it sufficient? > What about things like MPI_Gather and MPI_AlltoAll? We > certainly don't want to force non-all-to-all operations to > have to do an all-reduce at the end to check for cancellation. Yup, those are the issues that come up. One could say that MPI_Cancel is not allowed for nonblocking collectives. Rajeev

1 0

Re: [mpi3-coll] Nonblocking collectives standard draft
by Greg Bronevetsky 01 Dec '08

01 Dec '08

At 01:39 PM 12/1/2008, Rajeev Thakur wrote: >MPI_Cancel cannot simply be ignored. For example, if there is an MPI_Isend >followed by MPI_Cancel, and the matching receive is never called, the cancel >cannot fail. Are you sure that this is the way it works? It doesn't say so explicitly in the spec and the notes for MPI_Cancel on http://www-unix.mcs.anl.gov/mpi/www/ say "Cancel has only been implemented for receive requests; it is a no-op for send requests". However, if we do need to provide the above semantics for MPI_Cancel, we will have to deal with a funny non-locality of behavior. Suppose we have an MPI_Ibcast and one of the receivers calls MPI_Cancel. What happens to the other participants? Do they all have to call MPI_Cancel to not participate or is any one calling it sufficient? What about things like MPI_Gather and MPI_AlltoAll? We certainly don't want to force non-all-to-all operations to have to do an all-reduce at the end to check for cancellation. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1(a)llnl.gov

1 0

Re: [mpi3-coll] Nonblocking collectives standard draft
by Rajeev Thakur 01 Dec '08

01 Dec '08

MPI_Cancel cannot simply be ignored. For example, if there is an MPI_Isend followed by MPI_Cancel, and the matching receive is never called, the cancel cannot fail. Rajeev > -----Original Message----- > From: mpi3-coll-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of > Greg Bronevetsky > Sent: Monday, December 01, 2008 11:33 AM > To: MPI-3 Collective Subgroup Discussions; MPI-3 Collective > Subgroup Discussions > Subject: Re: [mpi3-coll] Nonblocking collectives standard draft > > > >However, if you all already think that MPI_Request_free is bad, then > >what do you think about the evil MPI_Cancel? > > MPI_Cancel is a performance hint as far as I'm concerned, one that is > frequently ignored. Can you point to any semantic > difficulties with it? > > Greg Bronevetsky > Post-Doctoral Researcher > 1028 Building 451 > Lawrence Livermore National Lab > (925) 424-5756 > bronevetsky1(a)llnl.gov > > _______________________________________________ > mpi3-coll mailing list > mpi3-coll(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-coll >

1 0

Re: [mpi3-coll] Nonblocking collectives standard draft
by Greg Bronevetsky 01 Dec '08

01 Dec '08

>However, if you all already think that MPI_Request_free is bad, then >what do you think about the evil MPI_Cancel? MPI_Cancel is a performance hint as far as I'm concerned, one that is frequently ignored. Can you point to any semantic difficulties with it? Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1(a)llnl.gov

1 0

Re: [mpi3-coll] Nonblocking collectives standard draft
by Christian Siebert 01 Dec '08

01 Dec '08

Greg Bronevetsky wrote: > >> There is already a ticket for MPI-2.2 to deprecate it. However, there >> was some discussion. We will discuss this again at the next meeting. >> Until then, I just leave the text as is. Please let me know if you have >> a proposal for better wording. > > Yes, that sounds best. The issue with the ticket is that it breaks > existing programs and therefore doesn't work for 2.2. However, if we > agree that MPI_Request_free is a bad idea, we can push for its removal > as part of the 3.0 working groups. If we succeed, we won't need to worry > about this text. Not necessarily - we could try to deprecate it in 2.2, in order to remove it in 3.0. However, if you all already think that MPI_Request_free is bad, then what do you think about the evil MPI_Cancel? Best regards, Christian -- Christian Siebert, Dipl.-Inf. Research Associate NEC Laboratories Europe, NEC Europe Ltd. Rathausallee 10, D-53757 Sankt Augustin, Germany Phone: +49 (0) 2241 - 92 52 44 Fax: +49 (0) 2241 - 92 52 99 (Registered Office: 1 Victoria Road, London W3 6BL, 2832014)

1 0