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

ECS: Guarenteed Parallelization Tests #4204

Open
james7132 opened this issue Mar 14, 2022 · 1 comment
Open

ECS: Guarenteed Parallelization Tests #4204

james7132 opened this issue Mar 14, 2022 · 1 comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use

Comments

@james7132
Copy link
Member

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.

@james7132 james7132 added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Mar 14, 2022
@maniwani
Copy link
Contributor

maniwani commented Mar 14, 2022

Blindly rely on the executor to properly handle parallelization.

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 .archetype_component_access(), they definitely aren't disjoint.

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)
}

bors bot pushed a commit that referenced this issue May 9, 2022
# 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.
robtfm pushed a commit to robtfm/bevy that referenced this issue May 10, 2022
# 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.
exjam pushed a commit to exjam/bevy that referenced this issue May 22, 2022
# 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.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this issue Feb 1, 2023
# 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
Status: Needs Implementation
Development

No branches or pull requests

2 participants