-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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 by Bors] - Swap out num_cpus for std::thread::available_parallelism #4970
Conversation
pub fn available_parallelism() -> usize { | ||
std::thread::available_parallelism() | ||
.map(NonZeroUsize::get) | ||
.unwrap_or(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should log a warning when it fails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This review comment isn't resolved yet. I'm fine with either adding the warning if it fails or a reasonable argument why it shouldn't be added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was mostly to keep the behavior the same as it was before (as with num_cpus). Also given that this can be called repeatedly, it could easily spam the logs made.
I don't know how important this is for Bevy, but |
Games generally don't run in containers that limit the amount of usable cpu. Also for bevy increasing the amount of threads doesn't increase the memory usage nearly as much as running more rustc processes at the same time. |
games don't, but a game server using Bevy could |
At worst that would reduce efficiency, not cause crashes due to
For maximum efficiency I think you will have to finetune the taskpool configuration anyway including manual determination of the amount of threads of each kind to use. |
Maybe we should just wait to see how rust-lang/rust#97925 plays out? |
Seems like rust-lang/rust#97925 has been merged and was released as a part of 1.63, so I think the issues there have been addressed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one comment. Looks fine otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
forgot to push the button to actually comment 😅
pub fn available_parallelism() -> usize { | ||
std::thread::available_parallelism() | ||
.map(NonZeroUsize::get) | ||
.unwrap_or(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This review comment isn't resolved yet. I'm fine with either adding the warning if it fails or a reasonable argument why it shouldn't be added.
bors r+ |
# Objective As of Rust 1.59, `std::thread::available_parallelism` has been stabilized. As of Rust 1.61, the API matches `num_cpus::get` by properly handling Linux's cgroups and other sandboxing mechanisms. As bevy does not have an established MSRV, we can replace `num_cpus` in `bevy_tasks` and reduce our dependency tree by one dep. ## Solution Replace `num_cpus` with `std::thread::available_parallelism`. Wrap it to have a fallback in the case it errors out and have it operate in the same manner as `num_cpus` did. This however removes `physical_core_count` from the API, though we are currently not using it in any way in first-party crates. --- ## Changelog Changed: `bevy_tasks::logical_core_count` -> `bevy_tasks::available_parallelism`. Removed: `bevy_tasks::physical_core_count`. ## Migration Guide `bevy_tasks::logical_core_count` and `bevy_tasks::physical_core_count` have been removed. `logical_core_count` has been replaced with `bevy_tasks::available_parallelism`, which works identically. If `bevy_tasks::physical_core_count` is required, the `num_cpus` crate can be used directly, as these two were just aliases for `num_cpus` APIs.
Pull request successfully merged into main. Build succeeded: |
…4970) # Objective As of Rust 1.59, `std::thread::available_parallelism` has been stabilized. As of Rust 1.61, the API matches `num_cpus::get` by properly handling Linux's cgroups and other sandboxing mechanisms. As bevy does not have an established MSRV, we can replace `num_cpus` in `bevy_tasks` and reduce our dependency tree by one dep. ## Solution Replace `num_cpus` with `std::thread::available_parallelism`. Wrap it to have a fallback in the case it errors out and have it operate in the same manner as `num_cpus` did. This however removes `physical_core_count` from the API, though we are currently not using it in any way in first-party crates. --- ## Changelog Changed: `bevy_tasks::logical_core_count` -> `bevy_tasks::available_parallelism`. Removed: `bevy_tasks::physical_core_count`. ## Migration Guide `bevy_tasks::logical_core_count` and `bevy_tasks::physical_core_count` have been removed. `logical_core_count` has been replaced with `bevy_tasks::available_parallelism`, which works identically. If `bevy_tasks::physical_core_count` is required, the `num_cpus` crate can be used directly, as these two were just aliases for `num_cpus` APIs.
…4970) # Objective As of Rust 1.59, `std::thread::available_parallelism` has been stabilized. As of Rust 1.61, the API matches `num_cpus::get` by properly handling Linux's cgroups and other sandboxing mechanisms. As bevy does not have an established MSRV, we can replace `num_cpus` in `bevy_tasks` and reduce our dependency tree by one dep. ## Solution Replace `num_cpus` with `std::thread::available_parallelism`. Wrap it to have a fallback in the case it errors out and have it operate in the same manner as `num_cpus` did. This however removes `physical_core_count` from the API, though we are currently not using it in any way in first-party crates. --- ## Changelog Changed: `bevy_tasks::logical_core_count` -> `bevy_tasks::available_parallelism`. Removed: `bevy_tasks::physical_core_count`. ## Migration Guide `bevy_tasks::logical_core_count` and `bevy_tasks::physical_core_count` have been removed. `logical_core_count` has been replaced with `bevy_tasks::available_parallelism`, which works identically. If `bevy_tasks::physical_core_count` is required, the `num_cpus` crate can be used directly, as these two were just aliases for `num_cpus` APIs.
…4970) # Objective As of Rust 1.59, `std::thread::available_parallelism` has been stabilized. As of Rust 1.61, the API matches `num_cpus::get` by properly handling Linux's cgroups and other sandboxing mechanisms. As bevy does not have an established MSRV, we can replace `num_cpus` in `bevy_tasks` and reduce our dependency tree by one dep. ## Solution Replace `num_cpus` with `std::thread::available_parallelism`. Wrap it to have a fallback in the case it errors out and have it operate in the same manner as `num_cpus` did. This however removes `physical_core_count` from the API, though we are currently not using it in any way in first-party crates. --- ## Changelog Changed: `bevy_tasks::logical_core_count` -> `bevy_tasks::available_parallelism`. Removed: `bevy_tasks::physical_core_count`. ## Migration Guide `bevy_tasks::logical_core_count` and `bevy_tasks::physical_core_count` have been removed. `logical_core_count` has been replaced with `bevy_tasks::available_parallelism`, which works identically. If `bevy_tasks::physical_core_count` is required, the `num_cpus` crate can be used directly, as these two were just aliases for `num_cpus` APIs.
Objective
As of Rust 1.59,
std::thread::available_parallelism
has been stabilized. As of Rust 1.61, the API matchesnum_cpus::get
by properly handling Linux's cgroups and other sandboxing mechanisms.As bevy does not have an established MSRV, we can replace
num_cpus
inbevy_tasks
and reduce our dependency tree by one dep.Solution
Replace
num_cpus
withstd::thread::available_parallelism
. Wrap it to have a fallback in the case it errors out and have it operate in the same manner asnum_cpus
did.This however removes
physical_core_count
from the API, though we are currently not using it in any way in first-party crates.Changelog
Changed:
bevy_tasks::logical_core_count
->bevy_tasks::available_parallelism
.Removed:
bevy_tasks::physical_core_count
.Migration Guide
bevy_tasks::logical_core_count
andbevy_tasks::physical_core_count
have been removed.logical_core_count
has been replaced withbevy_tasks::available_parallelism
, which works identically. Ifbevy_tasks::physical_core_count
is required, thenum_cpus
crate can be used directly, as these two were just aliases fornum_cpus
APIs.