forked from rayon-rs/rayon
-
Notifications
You must be signed in to change notification settings - Fork 13
Cherry-pick changes from upstream rayon-core #16
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
Merged
Merged
+309
−833
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.) (cherry picked from commit f98eb57)
If a worker thread has jobs in its own queue, then it's not really headed for an inactive / sleepy state yet, so we can avoid modifying the registry-wide sleep state. (cherry picked from commit 99e6fc1)
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`. (cherry picked from commit 32d3774)
(cherry picked from commit e39b730)
(cherry picked from commit 0b73db2)
(cherry picked from commit 936093f)
(cherry picked from commit dca9bd0)
(cherry picked from commit 24723fa)
(cherry picked from commit c8bb6ca)
Rayon has long had some logging functionality, but not well advertised. The only mention is in the (private) module docs: > To use in a debug build, set the env var `RAYON_LOG` as > described below. In a release build, logs are compiled out by > default unless Rayon is built with `--cfg rayon_rs_log` (try > `RUSTFLAGS="--cfg rayon_rs_log"`). > > Note that logs are an internally debugging tool and their format > is considered unstable, as are the details of how to enable them. I, for one, have not "internally" used this for debugging at all, yet it comes at some cost to all users, even disabled in release builds. At the very least it requires `crossbeam-channel` that we're not using anywhere else except tests. Besides that, this code also bloats the compiled size of `rayon-core` by about 30%, and similar for its compile time. **So let's just rip out the logger!** The remaining uses of `crossbeam-channel` in test cases are easily avoidable too, since `std::sync::mpsc::Sender` is now `Sync`. (cherry picked from commit 191ade2)
…oop. This was originally done for rayon-rs#1063, in order to reuse this to allow cleaning up the TLS data allocated by use_current_thread. We ended up not using that, but this refactoring seems useful on its own. (cherry picked from commit ea0c06d)
(cherry picked from commit 3fe51e5)
(cherry picked from commit e9835aa)
(cherry picked from commit 9dc500f)
(cherry picked from commit 2e071c2)
Signed-off-by: acceptacross <csqcqs@gmail.com> (cherry picked from commit 6f4bb8e)
(cherry picked from commit a14f459)
(cherry picked from commit f3dbb42)
(cherry picked from commit a4c8748)
(cherry picked from commit e8c381d)
(cherry picked from commit 1900fae)
(cherry picked from commit b2f7393)
(cherry picked from commit 96ea97e)
(cherry picked from commit 95eed8b)
(cherry picked from commit fade88f)
(cherry picked from commit 2ca893b)
LGTM |
cuviper
added a commit
to cuviper/rust
that referenced
this pull request
Apr 16, 2025
* [Fix a race with deadlock detection](rust-lang/rustc-rayon#15) * [Cherry-pick changes from upstream rayon-core](rust-lang/rustc-rayon#16) - This also removes a few dependencies from rustc's tidy list.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 17, 2025
Upgrade to `rustc-rayon-core` 0.5.1 * [Fix a race with deadlock detection](rust-lang/rustc-rayon#15) * [Cherry-pick changes from upstream rayon-core](rust-lang/rustc-rayon#16) - This also removes a few dependencies from rustc's tidy list.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 17, 2025
Upgrade to `rustc-rayon-core` 0.5.1 * [Fix a race with deadlock detection](rust-lang/rustc-rayon#15) * [Cherry-pick changes from upstream rayon-core](rust-lang/rustc-rayon#16) - This also removes a few dependencies from rustc's tidy list.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Apr 17, 2025
Upgrade to `rustc-rayon-core` 0.5.1 * [Fix a race with deadlock detection](rust-lang/rustc-rayon#15) * [Cherry-pick changes from upstream rayon-core](rust-lang/rustc-rayon#16) - This also removes a few dependencies from rustc's tidy list.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 17, 2025
Rollup merge of rust-lang#139935 - cuviper:rustc-rayon-core-0.5.1, r=lqd Upgrade to `rustc-rayon-core` 0.5.1 * [Fix a race with deadlock detection](rust-lang/rustc-rayon#15) * [Cherry-pick changes from upstream rayon-core](rust-lang/rustc-rayon#16) - This also removes a few dependencies from rustc's tidy list.
lcnr
pushed a commit
to lcnr/rust
that referenced
this pull request
Apr 17, 2025
* [Fix a race with deadlock detection](rust-lang/rustc-rayon#15) * [Cherry-pick changes from upstream rayon-core](rust-lang/rustc-rayon#16) - This also removes a few dependencies from rustc's tidy list.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR cherry-picks changes from upstream, but only in the
rayon-core
path. This seems like a simpler way to synchronize changes, as that's all the compiler is using since rust-lang/rust#139011.I also skipped rayon-rs#1063 and rayon-rs#1110 because those increase complexity, and I think it's unlikely that rustc will want to use those features.