Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Adding Persistent Collective Communication #25
This ticket proposes non-blocking persistent collective operations be added to the standard.
For each API that currently supports a request as an out argument of a non-blocking collective operation, MPI will support an _init version.
Example: MPI_Bcast() [blocking, MPI-1] -> MPI_Ibcast(...,info,request[,ierr]) [MPI 3.x] -> MPI_Bcast_init(...,info,request[,ierr]) [new]
The attached text is prototypical standards draft text.
Some quick notes:
MPI persistent collective operation _inits are initialization calls and follow all the ordering rules already existing for posing nonblocking collective operations (this implies _init operations are local and non-blocking). Remember that the point-to-point init functions disallow communication whereas the persistent collective inits may communicate but must not rely on state of other MPI processes.
The info argument is an in argument that allows for a limited number of hints about how the persistent, nonblocking collective will be used, as defined in the text (collective chapter).
The request argument is an out argument in each process of the calling group of the communicator that can be used zero or more times to start a collective operation. Each such request must be started in all the processes of the underlying group of the communicator (they are deemed active after this). Each request must be completed (making them inactive) before another start is permitted. Each process in the group of the communicator must complete the operation.
We do not require that starts across a group for persistent collective operations serialize to the same order. This makes using MPI_STARTALL allowed.
MPI_Test/MPI_Wait operations (all) give completion information without destroying the persistent request. MPI_Request_free() is used as with persistent point-to-point operations to free up an inactive persistent collective operation. This is the same behavior as for persistent point-to-point requests.
There are some per-communicator info items also defined that make sense on a communicator scope vs. a per-operation scope, also defined in the collective chapter.
Ticket #83 specifies additional functionality for info keys for these persistent operations, and is a related ticket that should be considered in sequence or in parallel with this ticket.
The associated PR is at: mpi-forum/mpi-standard#29
OK, I''ll go look...
On Thu, Jun 2, 2016 at 8:12 AM, Wesley Bland email@example.com
Anthony Skjellum, PhD
Page 215, Line 5-9 of mpi-report.pdf specifies:
I think, that the send buffers can be modified until MPI_Start/MPI_Startall and receive buffers can be accessed after the corresponding request is completed not freed.
We do not allow these operations in Startall, but you are correct:
I would agree with this modified statement: I think, that the send buffers
On Fri, Jun 3, 2016 at 5:15 AM, Hubert Ritzdorf firstname.lastname@example.org
Anthony Skjellum, PhD
I had the same comment - see comment on the PR - I think we have to allow this, otherwise we can only send the same data over and over again.
To be more precise, we can modify send buffers until Start and then again after the request is complete until the next Start. Similar for receive buffers.
@tonyskjellum: Can you clarify the statement that Startall is not allowed? I didn't get this from the text.
The user can't do that anyway - there is no way to access or change the pointer after the init calls - it also different to the terminology that we use in the rest of the standard (as far as I remember): changing a buffer means changing its contents (and that's a real restriction between start and completions and should be mentioned)
Hi Tony, Ryan, and Dan,
As we saw, the wording in the PT2PT Persistent Communication
The meaning of "should" may be taken out of
"In all clauses, you should be clear about
Dr. Rolf Rabenseifner . . . . . . . . . .. email email@example.com
I’ve added this information and some related info to the instructions document (instr.tex), which I’ll push later today.
This was referenced
Mar 8, 2018
referenced this issue
Mar 21, 2018
Rolf, thank you ... As we’ve explained we still intended to do more with subsequent ticket 90 and beyond if needed; maybe this recommendation could be a small enough change to fit within a ticket 25 no no vote or such ... but maybe we should do this on ticket 90 since it’s purpose is precisely to clean the front matter language for ticket 25... Anthony Skjellum, PhD 205-807-4968…
On Feb 28, 2018, at 3:55 AM, Rolf Rabenseifner ***@***.***> wrote: In the intro of Section 3.9 on page 73 (pdf page 105), the sentence "The remainder of this section covers only point-to-point persistent operations." is not fully true. It wanted to tell that the collective persistent ...INIT... routines are not here. A more correct statement would be: "The remainder of this section covers the point-to-point persistent initialization operations and the start routines, which are used for both point-to-point and collective persistent communication." Best regards Rolf ----- Original Message ----- > From: "github notifications" ***@***.***> > To: "mpi-forum" ***@***.***> > Cc: "Rolf Rabenseifner" ***@***.***>, "Mention" ***@***.***> > Sent: Tuesday, February 27, 2018 5:58:54 PM > Subject: Re: [mpi-forum/mpi-issues] Adding Persistent Collective Communication (#25) > Here is the diff against the latest MPI-3 standard; for reading on 2/28/18. > > https://uab.box.com/s/5n6wcks2w30vb62uanfnqa6rj4txyho4 > > > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > #25 (comment) -- Dr. Rolf Rabenseifner . . . . . . . . . .. email ***@***.*** . 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) . — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Ok ticket #80 and #105 need to update to reflect the new APIs once merger done Anthony Skjellum, PhD 205-807-4968…
On Sep 21, 2018, at 9:16 AM, Martin Schulz ***@***.***> wrote: Passed no/no vote and second vote at Barcelona meeting in Sep. 2018, ready to be merged into golden copy — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.