-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
ECS: Guarenteed Parallelization Tests #4204
Comments
I get what you're saying, but just wanted to say the executor does properly handle parallelization. If two systems see an intersection on their That relies on runtime information, though. Not sure if there's a way to statically prove that two systems can't run in parallel. This is what the current results mean. // these aren't known until you actually spawn entities and have archetypes
let some_access = some_system.archetype_component_access();
let other_access = other_system.archetype_component_access();
if some_access.is_compatible(other_access) {
// these systems definitely do not conflict
} else {
// these systems definitely conflict
}
let some_access = some_system.component_access();
let other_access = other_system.component_access();
if some_access.is_compatible(other_access) {
// these systems can never conflict
} else {
// these systems may or may not conflict (depends on the archetypes)
} |
# Objective - (Eventually) reduce noise in reporting access conflicts between unordered systems. - `SystemStage` only looks at unfiltered `ComponentId` access, any conflicts reported are potentially `false`. - the systems could still be accessing disjoint archetypes - Comparing systems' filtered access sets can maybe avoid that (for statically known component types). - #4204 ## Solution - Modify `SparseSetIndex` trait to require `PartialEq`, `Eq`, and `Hash` (all internal types except `BundleId` already did). - Add `is_compatible` and `get_conflicts` methods to `FilteredAccessSet<T>` - (existing method renamed to `get_conflicts_single`) - Add docs for those and all the other methods while I'm at it.
# Objective - (Eventually) reduce noise in reporting access conflicts between unordered systems. - `SystemStage` only looks at unfiltered `ComponentId` access, any conflicts reported are potentially `false`. - the systems could still be accessing disjoint archetypes - Comparing systems' filtered access sets can maybe avoid that (for statically known component types). - bevyengine#4204 ## Solution - Modify `SparseSetIndex` trait to require `PartialEq`, `Eq`, and `Hash` (all internal types except `BundleId` already did). - Add `is_compatible` and `get_conflicts` methods to `FilteredAccessSet<T>` - (existing method renamed to `get_conflicts_single`) - Add docs for those and all the other methods while I'm at it.
# Objective - (Eventually) reduce noise in reporting access conflicts between unordered systems. - `SystemStage` only looks at unfiltered `ComponentId` access, any conflicts reported are potentially `false`. - the systems could still be accessing disjoint archetypes - Comparing systems' filtered access sets can maybe avoid that (for statically known component types). - bevyengine#4204 ## Solution - Modify `SparseSetIndex` trait to require `PartialEq`, `Eq`, and `Hash` (all internal types except `BundleId` already did). - Add `is_compatible` and `get_conflicts` methods to `FilteredAccessSet<T>` - (existing method renamed to `get_conflicts_single`) - Add docs for those and all the other methods while I'm at it.
# Objective - (Eventually) reduce noise in reporting access conflicts between unordered systems. - `SystemStage` only looks at unfiltered `ComponentId` access, any conflicts reported are potentially `false`. - the systems could still be accessing disjoint archetypes - Comparing systems' filtered access sets can maybe avoid that (for statically known component types). - bevyengine#4204 ## Solution - Modify `SparseSetIndex` trait to require `PartialEq`, `Eq`, and `Hash` (all internal types except `BundleId` already did). - Add `is_compatible` and `get_conflicts` methods to `FilteredAccessSet<T>` - (existing method renamed to `get_conflicts_single`) - Add docs for those and all the other methods while I'm at it.
What problem does this solve or what need does it fill?
To ensure maximum performance, we should be able to test that at least two (if not N) different systems will not block each other during execution (ignoring any explicit labeling or ordering).
What solution would you like?
A testing utility that, given two or more systems, returns false if all of them cannot run in parallel. This would allow using assert tests to ensure that said tests are broken if the systems would serialize execution in any way.
What alternative(s) have you considered?
Blindly rely on the executor to properly handle parallelization.
Additional context
A lot of optimizations that rely on splitting large monolithic systems into smaller disjoint ones that can run in parallel cannot be easily enforced via unit tests right now.
The text was updated successfully, but these errors were encountered: