3 ms·
> did anyone even try this, ever? I think it depends on the granularity. Coarse-grained parallelism is already common: some things like AI (like your example)
by ratww 4y ago
> did anyone even try this, ever?
I think it depends on the granularity.
Coarse-grained parallelism is already common: some things like AI (like your example), Physics, Resource Management, Shader Compilation, Audio and even Netcode are already commonly run in separate threads.
However you won't see the updateInputs(), all the updateState() and sometimes even render() running in parallel for two reasons: first because it's often cheaper and easier/simpler to run in the main thread than dispatching async jobs anyway. Second because each operation often depends on the previous ones, and you can't wait until the next frame to take it into account: you often want instant feedback.
However these things can in theory be run in parallel without becoming chaos. ECS is often very parallelizable: you can run multiple Systems in different threads, as long as the output of one System is not a dependency of another running at the same time. You could also process multiple components of a system in multiple threads, but that would negate ECS main advantage: being cache-friendly by virtue of running in a single thread.
- Waterluvian 4y agoI think Bevy in Rust demonstrates this well. Your systems are structured in a dependency graph and, I think, automatically figure out what things can be done in parallel.