Parallelism in Bevy #2875
Replies: 1 comment
-
Great diagrams! This was briefly proposed in #2747 as well :) flecs uses a variant on this strategy for its parallelism, basically releasing entities into the next system as soon as their processing is complete. Unfortunately, this doesn't play very nicely with our ownership model. Archetype-components are the fundamental unit of parallelism that we use (which is nice for cache-friendly processing). Right now, if these are accessed mutably, they're locked until the system is complete. In order to bypass this, we'd need a) a way to signal that we're done processing this data b) a way to feed this information back into the scheduler before system completion. The strategy would basically be to release each archetype-component back into the available pool as soon as that batch completes, updating the bitset of current data accesses. Then, allow systems to start as long as at least some data is available to access, only completing when all of the relevant data has been handled. In general I think this would be possible but: a) I have no idea how we could do so ergonomically. Now, if we were working in an environment where system completion times were measured in minutes and we had more opportunities for parallelism than we knew what to do with (e.g. extract-transform-load in a cloud setting), I could totally see this approach being worth pursuing. |
Beta Was this translation helpful? Give feedback.
-
Bevy has two general types of parallelism, but there is possibly a missed opportunity to implement a third kind.
Is this third kind useful? Is it possible to implement practically and ergonomically?
Outer parallelism
Systems run in parallel. This is standard behaviour in the app schedule. This works with systems that process queries that are "disjointed".
Inner parallelism
Batches of entities are processed in parallel. This is implemented via the parallel iterators, and works with a single query (at a time).
Just in time? Greedy? For-each?
Systems are processed on entities (or batches of entities) as soon as they can be. In theory, this could have been implemented via for-each systems, but that had its own problems. Perhaps users could just write bigger systems that process these in parallel using tasks and parallel iterators, but the ergonomics aren't amazing. For example, as depicted below, you may have 3 unique "archetypes" of entities that undergo unique transformations (A, B, and C), then a fourth transformation (D) that depends on the results of the previous transformation, but could take in any of these entities, and processes these as soon as the relevant preceding transformation is completed.
Beta Was this translation helpful? Give feedback.
All reactions