Entity Component System: System
2017-03-10
The third pillar of the ECS model is the System. A system is a routine that operates on entities and components.
Is a system stateful or stateless? Are systems internally scheduled or externally scheduled?
Can systems interleave on a single thread? Can systems run in parallel?
What does a system do when a necessary resource isn’t ready?
System is not a job system or a threadpool.
System pattern matching. Component iteration. Tuple of components, read/write. Automatic parallelization, checked manual parallelization.
Imagine we have 2 systems: PedestrianThink and VehicleThink. Let’s stipulate that a pedestrian is never a vehicle and a vehicle is never a pedestrian. Further assume both entity archetypes contain a Destination component that stores a position or entity reference the entity will move towards and these systems may write to that Destination.
In this situation the set of mutable component types each system will operate on are not disjoint but the set of entities each system will operate on are disjoint. It would be possible to prove this at runtime by taking the intersection of the set of entities both systems will operate on. But with our a priori knowledge we know this work to be unnecessary and furthermore this work would require a collaboration between the system that would introduce a serializing step before the systems can be scheduled to run in parallel.
It is unclear if this situation is important to address in practice. I’ve seen very little written on automatic scheduling of systems in an ECS. There is some literature on solving a more general problem. It may be best to implement an optional instrumentation layer to suggest system execution order and component set or entity set parallelism and then define our task graph statically (through code or data).
One final option is to analyze the set of entity archetypes to find disjoint sets of systems that may be run in parallel. This would handle the above vehicle/pedestrian case. This may requires constraining our entities to a predefined set of archetypes and giving up the ability to dynamically add/remove components or generate new archetypes on the fly. This method with these constraints gives us much more confidence than the entity set analysis which may give false positives. This may be a worthwhile trade-off. You could work around these constraints by generating every used permutation of archetype or by regenerating the task graph when a new archetype is created.
Finally here are like to previous ECS posts: