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

[Merged by Bors] - Swap out num_cpus for std::thread::available_parallelism #4970

Closed
wants to merge 1 commit into from

Conversation

james7132
Copy link
Member

@james7132 james7132 commented Jun 9, 2022

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.

@james7132 james7132 added C-Dependencies A change to the crates that Bevy depends on A-Tasks Tools for parallel and async work labels Jun 9, 2022
@james7132 james7132 changed the title Swap out num_cpus for std::threadavailable_parallelism Swap out num_cpus for std::thread::available_parallelism Jun 9, 2022
@hymm hymm added the M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide label Jun 9, 2022
pub fn available_parallelism() -> usize {
std::thread::available_parallelism()
.map(NonZeroUsize::get)
.unwrap_or(1)
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

@vacuus
Copy link

vacuus commented Jun 9, 2022

I don't know how important this is for Bevy, but std::thread::available_parallelism is erroneous for "environments where the available parallelism is controlled by cgroupv1" (rust-lang/rust#97911), leading to significantly higher memory usage in such environments. num_cpus doesn't have this issue.

@bjorn3
Copy link
Contributor

bjorn3 commented Jun 9, 2022

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.

@mockersf
Copy link
Member

mockersf commented Jun 9, 2022

games don't, but a game server using Bevy could

@bjorn3
Copy link
Contributor

bjorn3 commented Jun 9, 2022

At worst that would reduce efficiency, not cause crashes due to

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.

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.

@cart
Copy link
Member

cart commented Jun 10, 2022

Maybe we should just wait to see how rust-lang/rust#97925 plays out?

@Weibye Weibye added the S-Adopt-Me The original PR author has no intent to complete this work. Pick me up! label Aug 10, 2022
@james7132 james7132 removed the S-Adopt-Me The original PR author has no intent to complete this work. Pick me up! label Sep 10, 2022
@james7132 james7132 requested a review from bjorn3 September 10, 2022 19:32
@james7132
Copy link
Member Author

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.

Copy link
Contributor

@bjorn3 bjorn3 left a 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.

Copy link
Contributor

@bjorn3 bjorn3 left a 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)
Copy link
Contributor

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.

@james7132 james7132 added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Sep 14, 2022
@alice-i-cecile
Copy link
Member

bors r+

bors bot pushed a commit that referenced this pull request Sep 19, 2022
# 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.
@bors bors bot changed the title Swap out num_cpus for std::thread::available_parallelism [Merged by Bors] - Swap out num_cpus for std::thread::available_parallelism Sep 19, 2022
@bors bors bot closed this Sep 19, 2022
james7132 added a commit to james7132/bevy that referenced this pull request Oct 19, 2022
…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.
james7132 added a commit to james7132/bevy that referenced this pull request Oct 28, 2022
…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.
@james7132 james7132 deleted the available_parallelism branch December 12, 2022 06:43
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Tasks Tools for parallel and async work C-Dependencies A change to the crates that Bevy depends on M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants