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.

Sign up for GitHub

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

Jump to bottom

Inter-handler parallelism #4

Closed
rj00a opened this issue Jan 27, 2024 · 1 comment
Closed

Inter-handler parallelism #4

rj00a opened this issue Jan 27, 2024 · 1 comment
Assignees
@rj00a

Comments

@rj00a
Copy link
Owner

rj00a commented Jan 27, 2024 •
edited
Loading

Inter-handler parallelism allows multiple handlers to run in parallel with each other, safely and automatically. This is one of bevy_ecs's most attractive features. However, bevy_ecs's implementation has some problems in my experience.

  1. bevy_tasks is known to be slower than rayon.
  2. Parallelism is all or nothing -- systems that don't do enough work to be worth parallelizing get run in parallel anyway. This is a problem because parallelization has significant overhead.
  3. Systems are able to reserve entity identifiers in parallel and apply commands in an unspecified order. This introduces nondeterministic behavior into the program.

evenio can address these problems by

  1. Use rayon instead of bevy_tasks. This goes well with Intra-system parallelism #3 since rayon is already exposed in the public API.
  2. Distinguish parallel from non-parallel handlers. Users must opt-in to parallelism on a per-handler basis. This is especially important since evenio encourages users to create small handlers that handle individual entities.
  3. Spawning entities and sending events requires exclusive access to the event queue, so sending events cannot be done in parallel.
@rj00a rj00a mentioned this issue Jan 29, 2024
Closed
@rj00a rj00a self-assigned this Jan 29, 2024
@rj00a rj00a changed the title Intra-system parallelism Inter-system parallelism Feb 2, 2024
@rj00a rj00a changed the title Inter-system parallelism Inter-handler parallelism Feb 27, 2024
This was referenced Apr 5, 2024
Closed
Merged
rj00a added a commit that referenced this issue Apr 13, 2024
@rj00a
Implement non-'static events. (#42)
6a2f784 
Closes #41

This PR removes the `'static` bound from the `Event` trait.
`World::send` can now send events containing borrowed data from outside
the `World`. However, `Sender::send` still requires `'static`.

## Additional Changes
- Removed `World::send_many`. I wasn't sure how to make the lifetimes
correct here, and the method doesn't have any real benefits until #4 or
#5 is implemented. It could be added again if needed.
- Added `Event::This<'a>`. Because `Event` is no longer `'static`, we
need this associated type in order to get a canonical `TypeId`. It also
resolves a tricky lifetime issue in the implementation of `HandlerParam`
for `Receiver`/`ReceiverMut`. This does mean that `Event` is now an
`unsafe` trait, but it can continue to be implemented safely with the
derive macro.
@rj00a
Copy link
Owner Author

rj00a commented Apr 27, 2024

Closing as not planned due to #42

@rj00a rj00a closed this as not planned Won't fix, can't repro, duplicate, stale Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rj00a rj00a

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@rj00a