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

Re: [Mpi-forum] MPI "Allocate receive" proposal
by Matthieu Dorier 31 Aug '13

31 Aug '13

----- Mail original ----- > De: "Dries Kimpe" <dkimpe(a)mcs.anl.gov> > À: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Envoyé: Samedi 31 Août 2013 04:21:34 > Objet: Re: [Mpi-forum] MPI "Allocate receive" proposal > > > * Pavan Balaji <balaji(a)mcs.anl.gov> [2013-08-30 21:12:44]: > > > > Where are you providing the buffer information? Where will the > > message be received to? > > Most likely it should be a MPI_Improbe followed by user(application) > memory allocation, followed by MPI_Imrecv into the freshly allocated > buffer. Yes, this is what I'm thinking of. Yet reading the mails that I skipped yesterday, I can see now why it's still not good enough (because it requires a rendez-vous). So maybe adding some parameters to MPI_Arecv? like MPI_Arecv(..., alloc_fn, free_fn) would be useful, to tell MPI what functions to use to allocate and free the buffer (the reason for providing the free_fn parameter also would be to recover from errors happening after the allocation but before the return from MPI_Arecv, in order not to have a memory leak that should be handled by the user. Besides, MPI_Mem_free could also select the user-provided free_fn for the buffer returned by MPI_Arecv, so that the user can always use the MPI_Mem_free abstraction.). Of course some constants like MPI_DEFAULT_ALLOC and MPI_DEFAULT_FREE could always provide a default way of allocating/freeing the buffer. Matthieu > > > Dries > > _______________________________________________ > 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] MPI "Allocate receive" proposal
by Dries Kimpe 30 Aug '13

30 Aug '13

* Pavan Balaji <balaji(a)mcs.anl.gov> [2013-08-30 21:12:44]: > Where are you providing the buffer information? Where will the message be received to? Most likely it should be a MPI_Improbe followed by user(application) memory allocation, followed by MPI_Imrecv into the freshly allocated buffer. Dries

1 0

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

30 Aug '13

Where are you providing the buffer information? Where will the message be received to? -- Pavan On Aug 30, 2013, at 7:27 PM, Matthieu Dorier wrote: > What I actually meant is rather a version of MPI_Iprobe that uses an MPI_Request argument rather than a (flag, status) pair. > > Matthieu > > ----- Mail original ----- >> De: "Matthieu Dorier" <matthieu.dorier(a)irisa.fr> >> À: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Envoyé: Samedi 31 Août 2013 02:23:07 >> Objet: Re: [Mpi-forum] MPI "Allocate receive" proposal >> >> Sorry I only read only half of the exchanges, but I see many open >> questions here while another solution could be easier and more >> elegant, in my opinion: just provide MPI_Iprobe. >> >> The main problem we have here is the fact that it is not possible to >> use MPI_Probe in a Wait/Test array, which I agree is an important >> problem (I ran into it myself no later than this summer). Yet from >> the MPI_Arecv proposal, my immediate question is "What if I don't >> want MPI to use malloc but another function (e.g. cudaMalloc, or any >> other custom allocators, for instance those from the C++ STL, or an >> allocator that allocates in a shared memory, etc.)?" >> >> MPI_Iprobe(int source, int tag, MPI_Comm comm, MPI_Request* req) >> seems to resolve everything: we can use the request in a test/wait >> array, as soon as it completes we can get the status using >> MPI_Request_get_status, and get all the informations we would have >> had from a normal MPI_Probe. From there, the user is free to >> allocate its buffer the way she wants, and do either an MPI_Recv or >> an MPI_Irecv with this buffer. >> >> To be honest I also don't like the idea of having a library >> internally allocate memory for me that I should free outside of the >> library afterward (except if it's specifically the goal of that >> library), it's a good way of forgetting to free the buffer and it >> disallows any flexibility in the way the memory is allocated. >> >> Matthieu >> _______________________________________________ >> 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 -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] MPI "Allocate receive" proposal
by Matthieu Dorier 30 Aug '13

30 Aug '13

What I actually meant is rather a version of MPI_Iprobe that uses an MPI_Request argument rather than a (flag, status) pair. Matthieu ----- Mail original ----- > De: "Matthieu Dorier" <matthieu.dorier(a)irisa.fr> > À: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Envoyé: Samedi 31 Août 2013 02:23:07 > Objet: Re: [Mpi-forum] MPI "Allocate receive" proposal > > Sorry I only read only half of the exchanges, but I see many open > questions here while another solution could be easier and more > elegant, in my opinion: just provide MPI_Iprobe. > > The main problem we have here is the fact that it is not possible to > use MPI_Probe in a Wait/Test array, which I agree is an important > problem (I ran into it myself no later than this summer). Yet from > the MPI_Arecv proposal, my immediate question is "What if I don't > want MPI to use malloc but another function (e.g. cudaMalloc, or any > other custom allocators, for instance those from the C++ STL, or an > allocator that allocates in a shared memory, etc.)?" > > MPI_Iprobe(int source, int tag, MPI_Comm comm, MPI_Request* req) > seems to resolve everything: we can use the request in a test/wait > array, as soon as it completes we can get the status using > MPI_Request_get_status, and get all the informations we would have > had from a normal MPI_Probe. From there, the user is free to > allocate its buffer the way she wants, and do either an MPI_Recv or > an MPI_Irecv with this buffer. > > To be honest I also don't like the idea of having a library > internally allocate memory for me that I should free outside of the > library afterward (except if it's specifically the goal of that > library), it's a good way of forgetting to free the buffer and it > disallows any flexibility in the way the memory is allocated. > > Matthieu > _______________________________________________ > 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] MPI "Allocate receive" proposal
by Matthieu Dorier 30 Aug '13

30 Aug '13

Sorry I only read only half of the exchanges, but I see many open questions here while another solution could be easier and more elegant, in my opinion: just provide MPI_Iprobe. The main problem we have here is the fact that it is not possible to use MPI_Probe in a Wait/Test array, which I agree is an important problem (I ran into it myself no later than this summer). Yet from the MPI_Arecv proposal, my immediate question is "What if I don't want MPI to use malloc but another function (e.g. cudaMalloc, or any other custom allocators, for instance those from the C++ STL, or an allocator that allocates in a shared memory, etc.)?" MPI_Iprobe(int source, int tag, MPI_Comm comm, MPI_Request* req) seems to resolve everything: we can use the request in a test/wait array, as soon as it completes we can get the status using MPI_Request_get_status, and get all the informations we would have had from a normal MPI_Probe. From there, the user is free to allocate its buffer the way she wants, and do either an MPI_Recv or an MPI_Irecv with this buffer. To be honest I also don't like the idea of having a library internally allocate memory for me that I should free outside of the library afterward (except if it's specifically the goal of that library), it's a good way of forgetting to free the buffer and it disallows any flexibility in the way the memory is allocated. Matthieu

1 0

Tools chapter tickets
by Kathryn Mohror 27 Aug '13

27 Aug '13

Hi all, We will read the following tickets in Madrid. I have attached a current copy of the chapter marked up with the changes. The changes are isolated to the tools chapter. MPI-next tickets to be read: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/377 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/378 Errata tickets to be read and voted on: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/385 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/386 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/387 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/391 Kathryn ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

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

27 Aug '13

On Aug 27, 2013, at 2:33 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> Note that the type matching rules for send-receive say that MPI_BYTE >> matches only MPI_BYTE, not MPI_INT/FLOAT, or other type (pg 33-34). So >> this function would have to take a datatype argument, otherwise it >> would match only sends of bytes. Or we could relax those rules to permit Arecv to match any typed or untyped send. The type matching rules in the standard don't actually match the way that existing implementations operate, nor do they match with any hardware I've ever heard of. > See 2) in my previous email. I would propose to add an etype. Any time a noncontiguous "etype" is posted this will likely force a copy on the receiver that could otherwise be avoided by posting contiguous bytes instead. I suppose that we would define any holes in the buffer described by the etype to have undefined values after the Arecv call completes? If we permit etypes, why not permit arbitrary types as well? Is there a good reason for the monotonic non-decreasing requirement? -Dave

1 0

Ticket 375 : Message Queue Support for Debugger Side Document
by Anh Vo 27 Aug '13

27 Aug '13

This ticket has been updated with some minor changes. The update is expected to be read at Madrid before the 1st vote https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/375 Thanks Anh

1 0

Errata-tickets #388, #389, and #390 - Re: 2 week cutoff: tonight
by Rolf Rabenseifner 27 Aug '13

27 Aug '13

Dear all, As already listed on the agenda of the Madrid Sep. 2013 MPI forum Meeting, the Fortran WG wants to read and vote on the following reviewed and scheduled errata tickets: - #388: Errata: Solving the FORTRAN LOGICAL and BIND(C) Problem https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/388 - #389: Errata: MPI_CONVERSION_FN_NULL is missing in annexes A.2, A.3, and A.4 (This ticket is mainly reviewed by the I/O WG, because it is an MPI-I/O function) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/389 - #390: Errata: Correcting Fortran _CPTR interface descriptions https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/390 Agenda: ------- Thursday, September 12, 2013, 1:30am - 3:00pm Fortran WG Plenary (Errata and Readings, Jeff S. and Rolf) Friday, September 13, 2013 11:15am - 11:30pm Reread/Discusson of ticket 0 changes (Fortran) 11:30am - 11:45am Votes (Errata) Best regards Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI Forum list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Tuesday, August 27, 2013 2:33:40 PM > Subject: [Mpi-forum] 2 week cutoff: tonight > According to > http://meetings.mpi-forum.org/secretary/2013/09/agenda.php, the Madrid > meeting starts at 9:30am on Wednesday, Sep. 11, 2013. > > If you want a formal reading of something at the Madrid meeting, you > need to send it to this list before 9:30am tomorrow morning (Madrid > time -- i.e., effectively tonight :-) ). > > -- > 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 -- 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: Room 1.307)

1 0

Re: [Mpi-forum] [MPI Forum] #388: MPI-3.0 errata: Solving the FORTRAN LOGICAL and BIND(C) problem
by Rolf Rabenseifner 27 Aug '13

27 Aug '13

Jeff, do you again remove the old pdf from Aug. 22? Best regards Rolf ----- Original Message ----- > From: "MPI Forum" <mpi-forum(a)lists.mpi-forum.org> > Sent: Tuesday, August 27, 2013 2:31:24 PM > Subject: Re: [MPI Forum] #388: MPI-3.0 errata: Solving the FORTRAN LOGICAL and BIND(C) problem > #388: MPI-3.0 errata: Solving the FORTRAN LOGICAL and BIND(C) problem > -------------------------------------+------------------------------------- > Reporter: | Owner: > RolfRabenseifner | RolfRabenseifner > Type: | Status: new > Correction to standard (for | Milestone: > upcoming release + errata) | 2013/09/11 Madrid, Spain > Priority: | Resolution: > Waiting for proposal reviews | Implementation status: > Version: MPI | Completed > <next> | Author: Rich Graham: 0 > Keywords: | Author: Torsten Hoefler: 0 > Author: Bill Gropp: 0 | Author: Jesper Larsson Traeff: 0 > Author: Adam Moody: 0 | Author: David Solt: 0 > Author: Dick Treumann: 0 | Author: Rajeev Thakur: 0 > Author: George Bosilca: 0 | Author: Alexander Supalov: 0 > Author: Bronis de Supinski: 0 | > Author: Jeff Squyres: 0 | > Author: Rolf Rabenseifner: 0 | > -------------------------------------+------------------------------------- > > Comment (by jsquyres): > > I'm ok with Rolf's single change to the 2013-08-27 PDF (compared to > the > 2013-08-22 PDF). Reviewed ok. > > -- > Ticket URL: > <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/388#comment:19> > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum -- 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: Room 1.307)

1 0