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] - Copy TaskPool resoures to subapps #4792

Closed
wants to merge 1 commit into from

Conversation

james7132
Copy link
Member

Objective

Fixes #4791. ParallelExecutor inserts a default CompteTaskPool if there isn't one stored as a resource, including when it runs on a different world. When spawning the render sub-app, the main world's ComputeTaskPool is not cloned and inserted into the render app's, which causes a second ComputeTaskPool with the default configuration to be spawned. This results in an excess number of threads being spawned.

Solution

Copy the task pools from the main world to the subapps upon creating them.

Alternative

An alternative to this would be to make the task pools global, as seen in #2250 or bevyengine/rfcs#54.

@james7132 james7132 added C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times A-Tasks Tools for parallel and async work A-Rendering Drawing game state to the screen A-App Bevy apps and plugins labels May 18, 2022
@alice-i-cecile alice-i-cecile added the S-Needs-Benchmarking This set of changes needs performance benchmarking to double-check that they help label May 18, 2022
@hymm
Copy link
Contributor

hymm commented May 18, 2022

This makes sense to me. The task pool configuration should be managing all the threads in the app.

Ran many_cubes. Unsurprisingly seeing a small perf hit with this change. This is mostly expected since on my machine (12 logical cores) there are only 6 compute threads available, while on main the default pool was allocating 12 to the render world.

image

The perf regression will be fixed by #4740. We could potentially roll up this change with that PR. I'm also ok merging this in by itself too, since the behavior isn't currently correct.

@james7132 james7132 added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Benchmarking This set of changes needs performance benchmarking to double-check that they help labels May 19, 2022
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is clearly the correct behavior. Generating a new taskpool for each subapp is too inflexible and surprising.

@alice-i-cecile
Copy link
Member

bors r+

bors bot pushed a commit that referenced this pull request May 30, 2022
# Objective
Fixes #4791. `ParallelExecutor` inserts a default `CompteTaskPool` if there isn't one stored as a resource, including when it runs on a different world. When spawning the render sub-app, the main world's `ComputeTaskPool` is not cloned and inserted into the render app's, which causes a second `ComputeTaskPool` with the default configuration to be spawned. This results in an excess number of threads being spawned.

## Solution
Copy the task pools from the main world to the subapps upon creating them.

## Alternative
An alternative to this would be to make the task pools global, as seen in #2250 or bevyengine/rfcs#54.
@bors bors bot changed the title Copy TaskPool resoures to subapps [Merged by Bors] - Copy TaskPool resoures to subapps May 30, 2022
@bors bors bot closed this May 30, 2022
james7132 added a commit to james7132/bevy that referenced this pull request Jun 7, 2022
# Objective
Fixes bevyengine#4791. `ParallelExecutor` inserts a default `CompteTaskPool` if there isn't one stored as a resource, including when it runs on a different world. When spawning the render sub-app, the main world's `ComputeTaskPool` is not cloned and inserted into the render app's, which causes a second `ComputeTaskPool` with the default configuration to be spawned. This results in an excess number of threads being spawned.

## Solution
Copy the task pools from the main world to the subapps upon creating them.

## Alternative
An alternative to this would be to make the task pools global, as seen in bevyengine#2250 or bevyengine/rfcs#54.
@james7132 james7132 deleted the fix-4791 branch June 22, 2022 08:20
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
# Objective
Fixes bevyengine#4791. `ParallelExecutor` inserts a default `CompteTaskPool` if there isn't one stored as a resource, including when it runs on a different world. When spawning the render sub-app, the main world's `ComputeTaskPool` is not cloned and inserted into the render app's, which causes a second `ComputeTaskPool` with the default configuration to be spawned. This results in an excess number of threads being spawned.

## Solution
Copy the task pools from the main world to the subapps upon creating them.

## Alternative
An alternative to this would be to make the task pools global, as seen in bevyengine#2250 or bevyengine/rfcs#54.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-App Bevy apps and plugins A-Rendering Drawing game state to the screen A-Tasks Tools for parallel and async work C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times 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.

All subapps use their own ComputeTaskPool by default
4 participants