Skip to content
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

Improve inlining of scope latch counters #1057

Merged
merged 1 commit into from
Jun 20, 2023
Merged

Conversation

cuviper
Copy link
Member

@cuviper cuviper commented Jun 20, 2023

The increment and set methods now have #[inline] hints, and the
counter fields in CountLatch and CountLockLatch are now listed
first to increase the chance that layout puts them at the same offset.
(That layout is not critical to ensure, but works out nicely.)

The `increment` and `set` methods now have `#[inline]` hints, and the
`counter` fields in `CountLatch` and `CountLockLatch` are now listed
first to increase the chance that layout puts them at the same offset.
(That layout is not critical to ensure, but works out nicely.)
@cuviper
Copy link
Member Author

cuviper commented Jun 20, 2023

bors r+

@bors
Copy link
Contributor

bors bot commented Jun 20, 2023

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

@bors bors bot merged commit 38e54eb into rayon-rs:master Jun 20, 2023
3 checks passed
cuviper added a commit to cuviper/rayon that referenced this pull request Jun 21, 2023
The former `enum ScopeLatch` forced a `match` during both `increment`
and `set` (decrement), even though both variants only need to update an
`AtomicUsize` most of the time. rayon-rs#1057 helped hide that for `increment`,
but `set` branching still showed up in perf profiles.

Now this is refactored to a unified `CountLatch` that has a direct field
for its `counter` used in the frequent case, and then an internal enum
for the one-time notification variants. Therefore, most of its updates
will have no `match` reached at all.

The only other use of the former `CountLatch` was the one-shot
termination latch in `WorkerThread`, so that's now renamed to
`OnceLatch`.
bors bot added a commit that referenced this pull request Jun 22, 2023
1059: Refactor scope latches to reduce matching r=cuviper a=cuviper

The former `enum ScopeLatch` forced a `match` during both `increment`
and `set` (decrement), even though both variants only need to update an
`AtomicUsize` most of the time. #1057 helped hide that for `increment`,
but `set` branching still showed up in perf profiles.

Now this is refactored to a unified `CountLatch` that has a direct field
for its `counter` used in the frequent case, and then an internal enum
for the one-time notification variants. Therefore, most of its updates
will have no `match` reached at all.

The only other use of the former `CountLatch` was the one-shot
termination latch in `WorkerThread`, so that's now renamed to
`OnceLatch`.


Co-authored-by: Josh Stone <cuviper@gmail.com>
@cuviper cuviper deleted the scope-inlines branch June 22, 2023 17:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant