August 2013 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] MPI "Allocate receive" proposal
by Jeff Hammond 26 Aug '13

26 Aug '13

I read the slides and accepted your arguments that there was something to optimize here in some cases, but I wasn't convinced there were that many cases and how much difference it would make to them. Pavan has suggested some usages but it isn't clear which parts of your proposal actually affect them. I think this proposed feature could help MADNESS a lot, but I refuse to use MADNESS as a litmus test for MPI Forum activities since I did that for the C++ bindings and it amounted to a huge waste of time. It seems to me that the better way to solve this problem is to support active messages and let the remote handler deal with memory allocation in the most appropriate manner. Jeff On Mon, Aug 26, 2013 at 1:23 PM, David Goodell (dgoodell) < dgoodell(a)cisco.com> wrote: > JeffH, please read the slides for motivation and performance > opportunities, esp. the big red bullets on #2, #6, and #7. > > -Dave > > On Aug 26, 2013, at 1:05 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > When does this actually improve performance? If memory is a limiting > factor, it merely eliminates a function call. If memory is limiting, I > don't see how doing extra ping-pong to keep from hitting OOM errors is > noticeable. > > > > JeffS and Dave: What's the use case? So far, I fail to see how this is > more than icing. > > > > Jeff > > > > > > On Mon, Aug 26, 2013 at 12:55 PM, Sur, Sayantan <sayantan.sur(a)intel.com> > wrote: > > This is a good feature to have in general that improves performance, > although the devil is in the details. > > > > What is the app trying to do when it finds itself in the quandary of > having to accept any sized message (probably from any source as well?). It > appears to me that the kind of app that is looking for this feature, or > could benefit from this feature is really looking for a many-to-one (or > one-to-one, many-to-many) reliably connected stream. It is likely that the > app that benefits significantly from this feature will be repeatedly using > this call to fetch differing amounts of data each time. > > > > A few meetings ago, Bill mentioned that it would be good to think of the > standard as a whole and not get bogged down in narrow use-cases. He > proposed that a streaming model be added to MPI P2P communications. Can > this use-case be included in that model? > > > > Thanks, > > Sayantan > > > > > > > -----Original Message----- > > > From: mpi-forum [mailto:[email protected]] On > > > Behalf Of Jeff Squyres (jsquyres) > > > Sent: Monday, August 26, 2013 8:11 AM > > > To: MPI Forum list > > > Subject: [Mpi-forum] MPI "Allocate receive" proposal > > > > > > Dave Goodell and I have a proposal that we've socialized a bit around > with > > > other Forum members, and would now like larger Forum feedback. I'll be > > > presenting the attached slides on the concept of an "allocate receive" > in > > > Madrid (3:30-4pm on Thursday). > > > > > > There's no text or ticket yet; this is an idea that we want to get > feedback on > > > before working up a full proposal. > > > > > > -- > > > Jeff Squyres > > > jsquyres(a)cisco.com > > > For corporate legal information go to: > > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [Mpi-forum] MPI "Allocate receive" proposal
by Anthony Skjellum 26 Aug '13

26 Aug '13

If I understand this correctly, some of us suggested allocate-on-receive, free-on-send mode, but left this out in MPI-1. I advocated this type of reactive semantics ... That's how the Reactive Kernel worked at Caltech for instance... Allowing for MPI to choose efficient memory for messages of some sizes can provide nice properties, provided the memory is good to compute in. There are always concerns about starvation from holding the messages too long :-) I'd like to see this get full consideration. It could be a big help in exascale to have fine-grain computing. For instance, could we not get zero-copy unexpected short messages in this way? Tony ----- Original Message ----- From: "David Goodell (dgoodell)" <dgoodell(a)cisco.com> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> Sent: Monday, August 26, 2013 1:23:04 PM Subject: Re: [Mpi-forum] MPI "Allocate receive" proposal JeffH, please read the slides for motivation and performance opportunities, esp. the big red bullets on #2, #6, and #7. -Dave On Aug 26, 2013, at 1:05 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > When does this actually improve performance? If memory is a limiting factor, it merely eliminates a function call. If memory is limiting, I don't see how doing extra ping-pong to keep from hitting OOM errors is noticeable. > > JeffS and Dave: What's the use case? So far, I fail to see how this is more than icing. > > Jeff > > > On Mon, Aug 26, 2013 at 12:55 PM, Sur, Sayantan <sayantan.sur(a)intel.com> wrote: > This is a good feature to have in general that improves performance, although the devil is in the details. > > What is the app trying to do when it finds itself in the quandary of having to accept any sized message (probably from any source as well?). It appears to me that the kind of app that is looking for this feature, or could benefit from this feature is really looking for a many-to-one (or one-to-one, many-to-many) reliably connected stream. It is likely that the app that benefits significantly from this feature will be repeatedly using this call to fetch differing amounts of data each time. > > A few meetings ago, Bill mentioned that it would be good to think of the standard as a whole and not get bogged down in narrow use-cases. He proposed that a streaming model be added to MPI P2P communications. Can this use-case be included in that model? > > Thanks, > Sayantan > > > > -----Original Message----- > > From: mpi-forum [mailto:[email protected]] On > > Behalf Of Jeff Squyres (jsquyres) > > Sent: Monday, August 26, 2013 8:11 AM > > To: MPI Forum list > > Subject: [Mpi-forum] MPI "Allocate receive" proposal > > > > Dave Goodell and I have a proposal that we've socialized a bit around with > > other Forum members, and would now like larger Forum feedback. I'll be > > presenting the attached slides on the concept of an "allocate receive" in > > Madrid (3:30-4pm on Thursday). > > > > There's no text or ticket yet; this is an idea that we want to get feedback on > > before working up a full proposal. > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Anthony Skjellum, PhD Professor and Chair Department of Computer and Information Sciences Director, UAB Center for Information Assurance and Joint Forensics Research ("The Center") University of Alabama at Birmingham +1-(205)934-8657; FAX: +1- (205)934-5473 "The most insidious thing in the world is nonsense that sounds just plausible enough to listen to." - Lazav (from Murmuring Phantasm Dragon's Maze) _________________________________________ CONFIDENTIALITY: This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. Please consider the environment carefully before printing this e-mail, then don't do it.

1 0

Re: [Mpi-forum] MPI "Allocate receive" proposal
by Underwood, Keith D 26 Aug '13

26 Aug '13

> As per the use case, at least ADLB and Charm++ will benefit from this. > They don't know what message size will come in. But I'm sure there are > more. But, do they know *approximately* the size of the message that is expected? Because, if they do, then most of the advantage isn't there. I struggle a little bit with the idea of well coded apps that have little enough idea about the size of the message that they need this. > My concern is not whether someone can use it, but rather with respect to > how much the MPI implementation can do without the sender knowing if > the receiver is going to receive the message using RECV or ARECV. But > maybe with Iarecv, it'll not be a problem. I'm more concerned about calling malloc() in the library. At the end of the day, even with the measly int-limited max message size, you will *have* to malloc in that path. I am also wondering if there is a better way to do this by exposing the traditional rendezvous? Sure, if you are under the rendezvous threshold, toss the eager receive buffer up. If you are above the threshold, toss it up to the library and provide a way to do a "pull" of the rest of the data. You could even go crazy and push an opaque handle out at the receiver to use in the pull. Given the implementation implications of this concept, my bias would be to not hide reality from the user. We should really only abstract the things for which the MPI library can do optimizations on the user's behalf. If we exposed and efficient way for the user to do rendezvous themselves, that may be better. Keith

1 0

Re: [Mpi-forum] Madrid hybrid slides: init/finalize
by Wesley Bland 26 Aug '13

26 Aug '13

Fair enough. Clearly I'm not reading well today. On Mon, Aug 26, 2013 at 1:33 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com > wrote: > First mention of it is on slide 4, "Re-initionaliztion of MPI". :-) > > Then lots more discussion about it starting effectively with slide 7, > e.g., "New INIT behavior ... If MPI is not currently initialized // > Initialize MPI / start a new MPI epoch // This can happen multiple times in > a process". > > No code examples until late in the slides, though. > > > > On Aug 26, 2013, at 2:22 PM, Wesley Bland <wbland(a)mcs.anl.gov> wrote: > > > That sounds good to me. I just didn't see that in the slides until one > of the corner cases. > > > > Thanks, > > Wesley > > > > > > On Mon, Aug 26, 2013 at 1:20 PM, Pavan Balaji <balaji(a)mcs.anl.gov> > wrote: > > > > That's one of the proposed changes. > > > > > > On 08/26/2013 01:06 PM, Wesley Bland wrote: > > Am I mistaken in remembering that MPI doesn't allow an application to go > > in and out of MPI: > > > > INIT > > .... > > FINALIZE > > .... > > INIT > > .... > > FINALIZE > > > > I've looked at the standard and that's what Section 8.7 says to me. So > > am I correct in assuming that this will change that text to say that you > > can start, stop, and start new "MPI epochs"? > > > > Thanks, > > Wesley > > > > > > On Mon, Aug 26, 2013 at 12:10 PM, Jeff Squyres (jsquyres) > > <jsquyres(a)cisco.com <mailto:[email protected]>> wrote: > > > > The hybrid working group will be hosting a plenary on Friday > > afternoon in Madrid. > > > > We will be presenting a proposal on MPI_INIT/MPI_FINALIZE regarding > > interaction with threads (going back to the use cases Jeff Hammond > > raised at a prior Forum meeting), and nested MPI_INIT/MPI_FINALIZE. > > This is not a formal reading; we're requesting Forum feedback on > > the overall ideas. > > > > The slides are attached. See you in Madrid. > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com <mailto:[email protected]> > > > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > > > > > > > > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > > > -- > > Pavan Balaji > > http://www.mcs.anl.gov/~balaji > > > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Re: [Mpi-forum] Madrid hybrid slides: init/finalize
by Jeff Squyres (jsquyres) 26 Aug '13

26 Aug '13

First mention of it is on slide 4, "Re-initionaliztion of MPI". :-) Then lots more discussion about it starting effectively with slide 7, e.g., "New INIT behavior ... If MPI is not currently initialized // Initialize MPI / start a new MPI epoch // This can happen multiple times in a process". No code examples until late in the slides, though. On Aug 26, 2013, at 2:22 PM, Wesley Bland <wbland(a)mcs.anl.gov> wrote: > That sounds good to me. I just didn't see that in the slides until one of the corner cases. > > Thanks, > Wesley > > > On Mon, Aug 26, 2013 at 1:20 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > That's one of the proposed changes. > > > On 08/26/2013 01:06 PM, Wesley Bland wrote: > Am I mistaken in remembering that MPI doesn't allow an application to go > in and out of MPI: > > INIT > .... > FINALIZE > .... > INIT > .... > FINALIZE > > I've looked at the standard and that's what Section 8.7 says to me. So > am I correct in assuming that this will change that text to say that you > can start, stop, and start new "MPI epochs"? > > Thanks, > Wesley > > > On Mon, Aug 26, 2013 at 12:10 PM, Jeff Squyres (jsquyres) > <jsquyres(a)cisco.com <mailto:[email protected]>> wrote: > > The hybrid working group will be hosting a plenary on Friday > afternoon in Madrid. > > We will be presenting a proposal on MPI_INIT/MPI_FINALIZE regarding > interaction with threads (going back to the use cases Jeff Hammond > raised at a prior Forum meeting), and nested MPI_INIT/MPI_FINALIZE. > This is not a formal reading; we're requesting Forum feedback on > the overall ideas. > > The slides are attached. See you in Madrid. > > -- > Jeff Squyres > jsquyres(a)cisco.com <mailto:[email protected]> > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] MPI "Allocate receive" proposal
by David Goodell (dgoodell) 26 Aug '13

26 Aug '13

JeffH, please read the slides for motivation and performance opportunities, esp. the big red bullets on #2, #6, and #7. -Dave On Aug 26, 2013, at 1:05 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > When does this actually improve performance? If memory is a limiting factor, it merely eliminates a function call. If memory is limiting, I don't see how doing extra ping-pong to keep from hitting OOM errors is noticeable. > > JeffS and Dave: What's the use case? So far, I fail to see how this is more than icing. > > Jeff > > > On Mon, Aug 26, 2013 at 12:55 PM, Sur, Sayantan <sayantan.sur(a)intel.com> wrote: > This is a good feature to have in general that improves performance, although the devil is in the details. > > What is the app trying to do when it finds itself in the quandary of having to accept any sized message (probably from any source as well?). It appears to me that the kind of app that is looking for this feature, or could benefit from this feature is really looking for a many-to-one (or one-to-one, many-to-many) reliably connected stream. It is likely that the app that benefits significantly from this feature will be repeatedly using this call to fetch differing amounts of data each time. > > A few meetings ago, Bill mentioned that it would be good to think of the standard as a whole and not get bogged down in narrow use-cases. He proposed that a streaming model be added to MPI P2P communications. Can this use-case be included in that model? > > Thanks, > Sayantan > > > > -----Original Message----- > > From: mpi-forum [mailto:[email protected]] On > > Behalf Of Jeff Squyres (jsquyres) > > Sent: Monday, August 26, 2013 8:11 AM > > To: MPI Forum list > > Subject: [Mpi-forum] MPI "Allocate receive" proposal > > > > Dave Goodell and I have a proposal that we've socialized a bit around with > > other Forum members, and would now like larger Forum feedback. I'll be > > presenting the attached slides on the concept of an "allocate receive" in > > Madrid (3:30-4pm on Thursday). > > > > There's no text or ticket yet; this is an idea that we want to get feedback on > > before working up a full proposal. > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Madrid hybrid slides: init/finalize
by Wesley Bland 26 Aug '13

26 Aug '13

That sounds good to me. I just didn't see that in the slides until one of the corner cases. Thanks, Wesley On Mon, Aug 26, 2013 at 1:20 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > That's one of the proposed changes. > > > On 08/26/2013 01:06 PM, Wesley Bland wrote: > >> Am I mistaken in remembering that MPI doesn't allow an application to go >> in and out of MPI: >> >> INIT >> .... >> FINALIZE >> .... >> INIT >> .... >> FINALIZE >> >> I've looked at the standard and that's what Section 8.7 says to me. So >> am I correct in assuming that this will change that text to say that you >> can start, stop, and start new "MPI epochs"? >> >> Thanks, >> Wesley >> >> >> On Mon, Aug 26, 2013 at 12:10 PM, Jeff Squyres (jsquyres) >> <jsquyres(a)cisco.com <mailto:[email protected]>> wrote: >> >> The hybrid working group will be hosting a plenary on Friday >> afternoon in Madrid. >> >> We will be presenting a proposal on MPI_INIT/MPI_FINALIZE regarding >> interaction with threads (going back to the use cases Jeff Hammond >> raised at a prior Forum meeting), and nested MPI_INIT/MPI_FINALIZE. >> This is not a formal reading; we're requesting Forum feedback on >> the overall ideas. >> >> The slides are attached. See you in Madrid. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com <mailto:[email protected]> >> >> For corporate legal information go to: >> http://www.cisco.com/web/**about/doing_business/legal/**cri/<http://www.cisco.com/web/about/doing_business/legal/cri/> >> >> ______________________________**_________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]**forum.org<mpi-forum(a)lists.mpi-forum.org> >> > >> http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum> >> >> >> >> >> >> ______________________________**_________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum> >> >> > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji >

1 0

Re: [Mpi-forum] Madrid hybrid slides: init/finalize
by Pavan Balaji 26 Aug '13

26 Aug '13

That's one of the proposed changes. On 08/26/2013 01:06 PM, Wesley Bland wrote: > Am I mistaken in remembering that MPI doesn't allow an application to go > in and out of MPI: > > INIT > .... > FINALIZE > .... > INIT > .... > FINALIZE > > I've looked at the standard and that's what Section 8.7 says to me. So > am I correct in assuming that this will change that text to say that you > can start, stop, and start new "MPI epochs"? > > Thanks, > Wesley > > > On Mon, Aug 26, 2013 at 12:10 PM, Jeff Squyres (jsquyres) > <jsquyres(a)cisco.com <mailto:[email protected]>> wrote: > > The hybrid working group will be hosting a plenary on Friday > afternoon in Madrid. > > We will be presenting a proposal on MPI_INIT/MPI_FINALIZE regarding > interaction with threads (going back to the use cases Jeff Hammond > raised at a prior Forum meeting), and nested MPI_INIT/MPI_FINALIZE. > This is not a formal reading; we're requesting Forum feedback on > the overall ideas. > > The slides are attached. See you in Madrid. > > -- > Jeff Squyres > jsquyres(a)cisco.com <mailto:[email protected]> > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] MPI "Allocate receive" proposal
by Pavan Balaji 26 Aug '13

26 Aug '13

Jeff, While a lot of details still need to be worked out, the core idea is still useful for performance. Specifically, if the application has to do a PROBE and then post a receive, the message is always unexpected and there might be a copy. With an ARECV, eager communication can be zero-copy if the MPI implementation is willing to give away its temporary buffer to the user (whether it wants to do that is a different story; some networks which don't require registration can). As per the use case, at least ADLB and Charm++ will benefit from this. They don't know what message size will come in. But I'm sure there are more. My concern is not whether someone can use it, but rather with respect to how much the MPI implementation can do without the sender knowing if the receiver is going to receive the message using RECV or ARECV. But maybe with Iarecv, it'll not be a problem. -- Pavan On 08/26/2013 01:05 PM, Jeff Hammond wrote: > When does this actually improve performance? If memory is a limiting > factor, it merely eliminates a function call. If memory is limiting, I > don't see how doing extra ping-pong to keep from hitting OOM errors is > noticeable. > > JeffS and Dave: What's the use case? So far, I fail to see how this is > more than icing. > > Jeff > > > On Mon, Aug 26, 2013 at 12:55 PM, Sur, Sayantan <sayantan.sur(a)intel.com > <mailto:[email protected]>> wrote: > > This is a good feature to have in general that improves performance, > although the devil is in the details. > > What is the app trying to do when it finds itself in the quandary of > having to accept any sized message (probably from any source as > well?). It appears to me that the kind of app that is looking for > this feature, or could benefit from this feature is really looking > for a many-to-one (or one-to-one, many-to-many) reliably connected > stream. It is likely that the app that benefits significantly from > this feature will be repeatedly using this call to fetch differing > amounts of data each time. > > A few meetings ago, Bill mentioned that it would be good to think of > the standard as a whole and not get bogged down in narrow use-cases. > He proposed that a streaming model be added to MPI P2P > communications. Can this use-case be included in that model? > > Thanks, > Sayantan > > > > -----Original Message----- > > From: mpi-forum [mailto:[email protected] > <mailto:[email protected]>] On > > Behalf Of Jeff Squyres (jsquyres) > > Sent: Monday, August 26, 2013 8:11 AM > > To: MPI Forum list > > Subject: [Mpi-forum] MPI "Allocate receive" proposal > > > > Dave Goodell and I have a proposal that we've socialized a bit > around with > > other Forum members, and would now like larger Forum feedback. > I'll be > > presenting the attached slides on the concept of an "allocate > receive" in > > Madrid (3:30-4pm on Thursday). > > > > There's no text or ticket yet; this is an idea that we want to > get feedback on > > before working up a full proposal. > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com <mailto:[email protected]> > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] Madrid hybrid slides: init/finalize
by Wesley Bland 26 Aug '13

26 Aug '13

Am I mistaken in remembering that MPI doesn't allow an application to go in and out of MPI: INIT .... FINALIZE .... INIT .... FINALIZE I've looked at the standard and that's what Section 8.7 says to me. So am I correct in assuming that this will change that text to say that you can start, stop, and start new "MPI epochs"? Thanks, Wesley On Mon, Aug 26, 2013 at 12:10 PM, Jeff Squyres (jsquyres) < jsquyres(a)cisco.com> wrote: > The hybrid working group will be hosting a plenary on Friday afternoon in > Madrid. > > We will be presenting a proposal on MPI_INIT/MPI_FINALIZE regarding > interaction with threads (going back to the use cases Jeff Hammond raised > at a prior Forum meeting), and nested MPI_INIT/MPI_FINALIZE. This is not a > formal reading; we're requesting Forum feedback on the overall ideas. > > The slides are attached. See you in Madrid. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0