-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Info key(s) for Start Ordering Persistent Collective Communication #83
Comments
See page 217 of initial text... |
Verified today that this info key is at the communicator scope. |
This is the public copy. |
We need to make updates based on the reading attempt on June 13, 2018 (all minor). We will present a new reading in Barcelona. |
Here is the latest PDF file for reading at Barcelona: |
Outcome of reading
|
Rudiments of the example/counter-examples: Restrictions with key:
Rank 0:
All other ranks must do the exact same dispatch order for these collectives. illegal:
Without key: Rank 0:
Rank 1:
legal. Rank N-1: Legal Legal --> Other collectives still are issued in same order across group. |
This comment has been minimized.
This comment has been minimized.
mpi32-report-ticket83-19nov18.pdf Here is the rewritten and revised text. |
We did the reading in San Jose.
The group agrees that we will take ticket 0 votes in Chattanooga on these changes above, which do not change the syntax or semantics of the info key, and then if it passes, take the first vote in Chattanooga in March, 2019. If ticket 0 votes fails, we will re-read in Chattanooga. |
This was merged because of my mistake. I'll reopen this issue and work with @wgropp and @tonyskjellum to create a new PR. |
@tonyskjellum we owe this start ordering info key from the persistent collective operations work. It would be great if this hit the MPI-4.1 release. I updated the PR by merging mpi-4.x into it. This should not need further changes, but we will need to restart the procedure with a reading in the Dec 22 meeting. |
Yes we should read again in December … thank you for doing this merging …
this is my albatross (cf, Rime of Ancient Mariner).
On Thu, Oct 20, 2022 at 12:30 PM Dan Holmes ***@***.***> wrote:
@tonyskjellum <https://github.com/tonyskjellum> we owe this start
ordering info key from the persistent collective operations work. It would
be great if this hit the MPI-4.1 release. I updated the PR by merging
mpi-4.x into it. This should not need further changes, but we will need to
restart the procedure with a reading in the Dec 22 meeting.
—
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAG7ZCNKBZH3ABDGTXLMOETWEFXTLANCNFSM4ETCZGJQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Anthony Skjellum, PhD
***@***.***
Cell: +1-205-807-4968
|
This had a reading on 2022-12-07. There were some no-no items raised (e.g., the changelog) that will be re-read at the March 2023 meeting. |
Latest PDF (with fixed change log and moved AtoU) for Feb'23 voting meeting: |
This passed a no-no vote on 2023-02-01.
|
This passed a first vote on 2023-02-08.
|
This passed a 2nd vote.
|
Problem
We want to add one or more info keys, such as one that guarantees that the persistent collective operation will only be started in order across the group of its communicator. Other info keys relevant to persistent collective initialization or operations may also be considered in addition to this one.
Note: this ticket actually describes the ordering rules for persistent collectives with and without this assertion with regard to all other collective communication on the same communicator.
Proposal
Specify at least one info key for ordered-across-group in persistent collectives at communicator scope. Others TBD.
Changes to the Text
Appropriate text will be added that defines the info key and its semantics. If other keys are conceived of quickly, they may be added too. So far, just one info key,
Impact on Implementations
For the specific info key specified thus far, it is an assertion. Implementations can ignore this assertion, or exploit it for greater performance. The assertion is mpi_assert_strict_persistent_collective_ordering ; it requires that programs order persistent collective starts [defined via a communicator that makes this assertion] under the same rules as other collectives. If an implementation can exploit this assertion for greater performance, it can do so, or do legally do nothing.
Impact on Users
Provides an info key; requires that the programs meet the restricted semantics if a given communicator with this assertion is used to generate persistent collective operations.
References
The original pull request for this ticket is https://github.com/mpi-forum/mpi-standard/pull/278
Merged too early: https://github.com/mpi-forum/mpi-standard/pull/661
Reverted by: https://github.com/mpi-forum/mpi-standard/pull/662
This is the PR that fixes this issue: https://github.com/mpi-forum/mpi-standard/pull/666
PDF File: mpi40-report-ticket83-12sep20.pdf
Updated PDF:
mpi40-report-ticket83-04may22.pdf
The text was updated successfully, but these errors were encountered: