October 2008 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] Higher-level languages proposal
by unknown＠example.com 14 Oct '08

14 Oct '08

Sure. This will most likely be a MPI-3 topic, though. I'll drop in a link here once ready. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Tuesday, October 14, 2008 2:35 PM To: MPI 2.2 Subject: Re: [Mpi-22] Higher-level languages proposal On Oct 14, 2008, at 7:07 AM, Supalov, Alexander wrote: > Thanks. I'd rather say that if the purpose of the extension is > indeed to > serialize the Probe/Recv pair, the better way to solve this and many > other problems would be to make threads directly addressable, as if > they > were MPI processes. > > One way to do this might be, say, to create a call like > MPI_Comm_thread_enroll that creates an intra-communicator out of all > threads that call this function in a loosely synchronous fashion, > collectively over one or several MPI processes they constitute. I'm still not sure I follow. Can you provide more details, perhaps with function prototypes and specific rules? (i.e., an alternate proposal)? > If paired with the appropriately extended MPI_Comm_free, this would > allow, for example, all threads in an OpenMP parallel section to be > addressed as if they were fully fledged MPI processes. Note that this > would allow more than one parallel section during the program run. > > Other threading models would profit from this "opt-in/opt-out" method, > too. This may be a more flexible way of dealing with threads than the > one-time MPI_Init variety mentioned by George Bosilica in his > EuroPVM/MPI keynote, by the way. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Terry Dontje > Sent: Tuesday, October 14, 2008 12:45 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Higher-level languages proposal > > Supalov, Alexander wrote: >> Dear Jeff, >> >> Unfortunately, I won't be in Chicago, so we should rather discuss >> this >> here. I talked to Torsten last time about this extension. As far as I >> can remember, the main purpose of this extension is to make sure that >> the thread that called the MPI_Probe also calls the MPI_Recv and gets >> the message matched by the aforementioned MPI_Probe. >> >> If so, the main problem here is not the matching. The main problem is >> that one cannot address threads in MPI. If we fix that, the proposed >> extension with the message handle and such will become superfluous. >> >> See what I mean? >> >> > Interesting, so you are basically redefining the MPI_Probe/Recv pair > to > guarrantee a message to go to a specific thread. Or in other words > lowering the proposal's MPI_Mprobe/recv to be in the implementation of > MPI_Probe/Recv. This seems reasonable to me since MPI_Probe/Recv > itself > > is basically useless unless the programmer assures serialization when > that combination is used. > > --td >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres >> Sent: Monday, October 13, 2008 11:48 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Higher-level languages proposal >> >> On Oct 13, 2008, at 10:46 AM, Supalov, Alexander wrote: >> >> >>> Thanks. The 2.1.1, which was presented last time, in my opinion does > >>> not >>> seem to solve the right problem. Instead of defining a way for >>> unambiguous addressing of the threads in MPI, which would eliminate >>> the >>> MPI_Probe/Recv ambiguity and many other issues, it attempts to add > yet >>> another concept (this time, a message id) in the current situation >>> where >>> any thread can do what they please. >>> >> >> I'm not quite sure I understand your proposal. >> >> <... after typing out a lengthy/rambling discourse that made very >> little sense and was fraught with questions and ambiguities :-) ...> >> >> Let's discuss this in Chicago; Rich has allocated 5-7pm on Monday for > >> discussion of this proposal. These are exactly the kinds of larger >> issues that we want to raise via this proposal. >> >> > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [Mpi-22] Higher-level languages proposal
by unknown＠example.com 14 Oct '08

14 Oct '08

On Oct 14, 2008, at 7:07 AM, Supalov, Alexander wrote: > Thanks. I'd rather say that if the purpose of the extension is > indeed to > serialize the Probe/Recv pair, the better way to solve this and many > other problems would be to make threads directly addressable, as if > they > were MPI processes. > > One way to do this might be, say, to create a call like > MPI_Comm_thread_enroll that creates an intra-communicator out of all > threads that call this function in a loosely synchronous fashion, > collectively over one or several MPI processes they constitute. I'm still not sure I follow. Can you provide more details, perhaps with function prototypes and specific rules? (i.e., an alternate proposal)? > If paired with the appropriately extended MPI_Comm_free, this would > allow, for example, all threads in an OpenMP parallel section to be > addressed as if they were fully fledged MPI processes. Note that this > would allow more than one parallel section during the program run. > > Other threading models would profit from this "opt-in/opt-out" method, > too. This may be a more flexible way of dealing with threads than the > one-time MPI_Init variety mentioned by George Bosilica in his > EuroPVM/MPI keynote, by the way. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Terry Dontje > Sent: Tuesday, October 14, 2008 12:45 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Higher-level languages proposal > > Supalov, Alexander wrote: >> Dear Jeff, >> >> Unfortunately, I won't be in Chicago, so we should rather discuss >> this >> here. I talked to Torsten last time about this extension. As far as I >> can remember, the main purpose of this extension is to make sure that >> the thread that called the MPI_Probe also calls the MPI_Recv and gets >> the message matched by the aforementioned MPI_Probe. >> >> If so, the main problem here is not the matching. The main problem is >> that one cannot address threads in MPI. If we fix that, the proposed >> extension with the message handle and such will become superfluous. >> >> See what I mean? >> >> > Interesting, so you are basically redefining the MPI_Probe/Recv pair > to > guarrantee a message to go to a specific thread. Or in other words > lowering the proposal's MPI_Mprobe/recv to be in the implementation of > MPI_Probe/Recv. This seems reasonable to me since MPI_Probe/Recv > itself > > is basically useless unless the programmer assures serialization when > that combination is used. > > --td >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres >> Sent: Monday, October 13, 2008 11:48 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Higher-level languages proposal >> >> On Oct 13, 2008, at 10:46 AM, Supalov, Alexander wrote: >> >> >>> Thanks. The 2.1.1, which was presented last time, in my opinion does > >>> not >>> seem to solve the right problem. Instead of defining a way for >>> unambiguous addressing of the threads in MPI, which would eliminate >>> the >>> MPI_Probe/Recv ambiguity and many other issues, it attempts to add > yet >>> another concept (this time, a message id) in the current situation >>> where >>> any thread can do what they please. >>> >> >> I'm not quite sure I understand your proposal. >> >> <... after typing out a lengthy/rambling discourse that made very >> little sense and was fraught with questions and ambiguities :-) ...> >> >> Let's discuss this in Chicago; Rich has allocated 5-7pm on Monday for > >> discussion of this proposal. These are exactly the kinds of larger >> issues that we want to raise via this proposal. >> >> > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Friendly reminder: tickets!!
by unknown＠example.com 14 Oct '08

14 Oct '08

Many thanks! On Oct 14, 2008, at 7:56 AM, Jesper Larsson Traeff wrote: > > Hi Jeff, > > sorry, thought I'd done them... Now, I'm done (I hope) > > best, > > Jesper > > On Tue, Oct 14, 2008 at 07:49:51AM -0400, Jeff Squyres wrote: >> As Bill indicated previously, your proposal won't be discussed next >> week unless your proposal has been turned into a ticket. Please >> convert them! Instructions: >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/TicketWorkflow >> >> The authors listed below have proposals that have not yet been >> converted into tickets (pulled from the MpiTwoTwoWikiPage page): >> >> - Erez Haba >> - Dick Treumann >> - Adam Moody >> - Rolf Rabenseifner >> - Hubert Ritzdorf >> - Rajeev Thakur >> - Douglas Gregor >> - Quincey Koziol >> - Rainer Keller >> - Dries Kimpe >> - David Solt >> - Jesper Larsson Träff >> - Martin Schulz >> - Pavan Balaji >> - William Gropp >> >> -- >> Jeff Squyres >> Cisco Systems >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Friendly reminder: tickets!!
by unknown＠example.com 14 Oct '08

14 Oct '08

Hi Jeff, orry, thought I'd done them... Now, I'm done (I hope) best, Jesper On Tue, Oct 14, 2008 at 07:49:51AM -0400, Jeff Squyres wrote: > As Bill indicated previously, your proposal won't be discussed next > week unless your proposal has been turned into a ticket. Please > convert them! Instructions: > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/TicketWorkflow > > The authors listed below have proposals that have not yet been > converted into tickets (pulled from the MpiTwoTwoWikiPage page): > > - Erez Haba > - Dick Treumann > - Adam Moody > - Rolf Rabenseifner > - Hubert Ritzdorf > - Rajeev Thakur > - Douglas Gregor > - Quincey Koziol > - Rainer Keller > - Dries Kimpe > - David Solt > - Jesper Larsson Träff > - Martin Schulz > - Pavan Balaji > - William Gropp > > -- > Jeff Squyres > Cisco Systems > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Friendly reminder: tickets!!
by unknown＠example.com 14 Oct '08

14 Oct '08

As Bill indicated previously, your proposal won't be discussed next week unless your proposal has been turned into a ticket. Please convert them! Instructions: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/TicketWorkflow The authors listed below have proposals that have not yet been converted into tickets (pulled from the MpiTwoTwoWikiPage page): - Erez Haba - Dick Treumann - Adam Moody - Rolf Rabenseifner - Hubert Ritzdorf - Rajeev Thakur - Douglas Gregor - Quincey Koziol - Rainer Keller - Dries Kimpe - David Solt - Jesper Larsson Träff - Martin Schulz - Pavan Balaji - William Gropp -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Higher-level languages proposal
by unknown＠example.com 14 Oct '08

14 Oct '08

Hi, Thanks. I'd rather say that if the purpose of the extension is indeed to serialize the Probe/Recv pair, the better way to solve this and many other problems would be to make threads directly addressable, as if they were MPI processes. One way to do this might be, say, to create a call like MPI_Comm_thread_enroll that creates an intra-communicator out of all threads that call this function in a loosely synchronous fashion, collectively over one or several MPI processes they constitute. If paired with the appropriately extended MPI_Comm_free, this would allow, for example, all threads in an OpenMP parallel section to be addressed as if they were fully fledged MPI processes. Note that this would allow more than one parallel section during the program run. Other threading models would profit from this "opt-in/opt-out" method, too. This may be a more flexible way of dealing with threads than the one-time MPI_Init variety mentioned by George Bosilica in his EuroPVM/MPI keynote, by the way. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Tuesday, October 14, 2008 12:45 PM To: MPI 2.2 Subject: Re: [Mpi-22] Higher-level languages proposal Supalov, Alexander wrote: > Dear Jeff, > > Unfortunately, I won't be in Chicago, so we should rather discuss this > here. I talked to Torsten last time about this extension. As far as I > can remember, the main purpose of this extension is to make sure that > the thread that called the MPI_Probe also calls the MPI_Recv and gets > the message matched by the aforementioned MPI_Probe. > > If so, the main problem here is not the matching. The main problem is > that one cannot address threads in MPI. If we fix that, the proposed > extension with the message handle and such will become superfluous. > > See what I mean? > > Interesting, so you are basically redefining the MPI_Probe/Recv pair to guarrantee a message to go to a specific thread. Or in other words lowering the proposal's MPI_Mprobe/recv to be in the implementation of MPI_Probe/Recv. This seems reasonable to me since MPI_Probe/Recv itself is basically useless unless the programmer assures serialization when that combination is used. --td > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Monday, October 13, 2008 11:48 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Higher-level languages proposal > > On Oct 13, 2008, at 10:46 AM, Supalov, Alexander wrote: > > >> Thanks. The 2.1.1, which was presented last time, in my opinion does >> not >> seem to solve the right problem. Instead of defining a way for >> unambiguous addressing of the threads in MPI, which would eliminate >> the >> MPI_Probe/Recv ambiguity and many other issues, it attempts to add yet >> another concept (this time, a message id) in the current situation >> where >> any thread can do what they please. >> > > I'm not quite sure I understand your proposal. > > <... after typing out a lengthy/rambling discourse that made very > little sense and was fraught with questions and ambiguities :-) ...> > > Let's discuss this in Chicago; Rich has allocated 5-7pm on Monday for > discussion of this proposal. These are exactly the kinds of larger > issues that we want to raise via this proposal. > > _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [Mpi-22] Higher-level languages proposal
by unknown＠example.com 14 Oct '08

14 Oct '08

Supalov, Alexander wrote: > Dear Jeff, > > Unfortunately, I won't be in Chicago, so we should rather discuss this > here. I talked to Torsten last time about this extension. As far as I > can remember, the main purpose of this extension is to make sure that > the thread that called the MPI_Probe also calls the MPI_Recv and gets > the message matched by the aforementioned MPI_Probe. > > If so, the main problem here is not the matching. The main problem is > that one cannot address threads in MPI. If we fix that, the proposed > extension with the message handle and such will become superfluous. > > See what I mean? > > Interesting, so you are basically redefining the MPI_Probe/Recv pair to guarrantee a message to go to a specific thread. Or in other words lowering the proposal's MPI_Mprobe/recv to be in the implementation of MPI_Probe/Recv. This seems reasonable to me since MPI_Probe/Recv itself is basically useless unless the programmer assures serialization when that combination is used. --td > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Monday, October 13, 2008 11:48 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Higher-level languages proposal > > On Oct 13, 2008, at 10:46 AM, Supalov, Alexander wrote: > > >> Thanks. The 2.1.1, which was presented last time, in my opinion does >> not >> seem to solve the right problem. Instead of defining a way for >> unambiguous addressing of the threads in MPI, which would eliminate >> the >> MPI_Probe/Recv ambiguity and many other issues, it attempts to add yet >> another concept (this time, a message id) in the current situation >> where >> any thread can do what they please. >> > > I'm not quite sure I understand your proposal. > > <... after typing out a lengthy/rambling discourse that made very > little sense and was fraught with questions and ambiguities :-) ...> > > Let's discuss this in Chicago; Rich has allocated 5-7pm on Monday for > discussion of this proposal. These are exactly the kinds of larger > issues that we want to raise via this proposal. > >

1 0

Re: [Mpi-22] Higher-level languages proposal
by unknown＠example.com 14 Oct '08

14 Oct '08

Dear Jeff, Unfortunately, I won't be in Chicago, so we should rather discuss this here. I talked to Torsten last time about this extension. As far as I can remember, the main purpose of this extension is to make sure that the thread that called the MPI_Probe also calls the MPI_Recv and gets the message matched by the aforementioned MPI_Probe. If so, the main problem here is not the matching. The main problem is that one cannot address threads in MPI. If we fix that, the proposed extension with the message handle and such will become superfluous. See what I mean? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Monday, October 13, 2008 11:48 PM To: MPI 2.2 Subject: Re: [Mpi-22] Higher-level languages proposal On Oct 13, 2008, at 10:46 AM, Supalov, Alexander wrote: > Thanks. The 2.1.1, which was presented last time, in my opinion does > not > seem to solve the right problem. Instead of defining a way for > unambiguous addressing of the threads in MPI, which would eliminate > the > MPI_Probe/Recv ambiguity and many other issues, it attempts to add yet > another concept (this time, a message id) in the current situation > where > any thread can do what they please. I'm not quite sure I understand your proposal. <... after typing out a lengthy/rambling discourse that made very little sense and was fraught with questions and ambiguities :-) ...> Let's discuss this in Chicago; Rich has allocated 5-7pm on Monday for discussion of this proposal. These are exactly the kinds of larger issues that we want to raise via this proposal. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Graph Interface Fixes
by unknown＠example.com 13 Oct '08

13 Oct '08

Hello Group, I finished a first implementation which maps the newly proposed graph interface to the old interface. This implementation is probably suboptimal and of course not scalable (can't be because the old interface isn't ;)). But is should be functional (compiles and works with some toy examples). I also corrected a slight mistake in ticket #33. As usual, I am open for comments. I CC'd the mpi-2.2 mailinglist because I think that might be of interest for the discussions next week. Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Research Assistant 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] Higher-level languages proposal
by unknown＠example.com 13 Oct '08

13 Oct '08

On Oct 13, 2008, at 10:46 AM, Supalov, Alexander wrote: > Thanks. The 2.1.1, which was presented last time, in my opinion does > not > seem to solve the right problem. Instead of defining a way for > unambiguous addressing of the threads in MPI, which would eliminate > the > MPI_Probe/Recv ambiguity and many other issues, it attempts to add yet > another concept (this time, a message id) in the current situation > where > any thread can do what they please. I'm not quite sure I understand your proposal. <... after typing out a lengthy/rambling discourse that made very little sense and was fraught with questions and ambiguities :-) ...> Let's discuss this in Chicago; Rich has allocated 5-7pm on Monday for discussion of this proposal. These are exactly the kinds of larger issues that we want to raise via this proposal. -- Jeff Squyres Cisco Systems

1 0