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
"WITH_INFO" review correlated for collective operations in Chapters "Collective Operations" and "Process Topologies" #85
Info keys are missing from blocking and nonblocking collective operations.
Blocking and nonblocking APIs (noted below) presently lack info arguments for legacy reasons; per-operation info arguments can be useful to application performance tuning in MPI implementations that support such optional arguments. Standardized info key may also be proposed separately.
If Ticket #80 is approved, this is a proposed extension to those extended APIs to be proposed for collective operations. We do not intend to create a combinatorial explosion of APIs WITH_INFO and _X, but rather merge the two changes into one new API set (_X).
The blocking and nonblocking collectives APIs that will be modified by Ticket #80 that do not have info arguments will be augmented to have info arguments. For each case, we will make sure it makes sense for the info argument to be added in the _X interface based on performance and functionality. In some cases, we might prefer to have a separate _WITH_INFO form.
In general, the info argument will be added between the comm and request arguments for nonblocking arguments, and after the comm in blocking operations.
Example (shown with C bindings to emphasize the Ticket #80 changes too):
Ticket #85 addition (on its own):
Ticket #80 addition (on its own):
Note: No existing functionality is broken, nor is any API deprecated by this ticket.
Tickets #78, #82 proposes new, nonblocking operations. These tickets will separately address the info argument for such new APIs where appropriate. Nothing described in these tickets is impacted by this ticket. Ticket #25 operations already include info keys as well, so this ticket does not impact Ticket #25.
Also, note that this ticket could be folded into Ticket #80 if appropriate.
Changes to the Text
Here is a subset related to topologies (copied from Ticket #84, which is duplicative and is being closed):
MPI_GRAPH_CREATE requires that each process passes the full (global) communication graph to the call. This limits the scalability of this constructor. With the distributed graph interface, the communication graph is specified in a fully distributed fashion.
In the absence of a proposal to deprecate MPI_GRAPH_CREATE (and thereby obviate the need to maintain/improve it), adding an MPI_INFO argument is one of the advisable changes/improvements.
This ticket can standalone or be approved with Ticket #80. If approved on its own, the info argument would be added to a set of APIs with the suffix _WITH_INFO.
If Ticket #85 is approved, this ticket would be modified to combine with it, as noted above. Ticket #80's changes for "big MPI" would be augmented to add the info argument to each of the abovenamed operations.
Impact on Implementations
Impact on Users
Users want to deliver info arguments in particular calls can incrementally modify their programs to use the new API where warranted.
Users opting for the new "big MPI" API already have to make appropriate changes to their code to use functionality added by Ticket #80. This would minimally add MPI_INFO_NULL into an argument slot during such refactoring.
This gives us the opportunity to use the form
Good point; that is obviously a friendly amendment.…
On Thu, Mar 8, 2018 at 7:26 AM, Dan Holmes ***@***.***> wrote: This gives us the opportunity to use the form MPI_thing_WITH_INFO rather than MPI_thing_X for the BigMPI-and-info API. That is, the _WITH_INFO functions would have both MPI_INFO and MPI_COUNT parameters, whereas the existing API would stand as is with neither of these enhancements. This alleviates concerns over the ambiguity, and possible future use, of _X function names. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA38ia2I9aKQHEYn8n5FBRiNa1XoYttlks5tcSN2gaJpZM4SikqW> .
-- Anthony Skjellum, PhD email@example.com Cell: +1-205-807-4968