Aspects

[amethyst]

Aspects

[OvermindDL1]

My take on Aspects (proven quite efficient for me in the past, though this mock-up is still being optimized so ignore the couple of highly inefficient loops that can be fairly easily fixed...): https://github.com/OvermindDL1/OverECS/blob/master/main.cpp

[torkleyy]

@OvermindDL1 Could you please explain how you're using the information provided by aspects in order to gain performance benefits? More specifically, even though we can know which systems are compatible to run in parallel, we don't exactly know when we may run the next system (we had to wait for a whole set of systems to finish if we want to be sure).

[OvermindDL1]

@OvermindDL1 Could you please explain how you're using the information provided by aspects in order to gain performance benefits? More specifically, even though we can know which systems are compatible to run in parallel, we don't exactly know when we may run the next system (we had to wait for a whole set of systems to finish if we want to be sure).

Internally at world startup (I required all systems to be registered ahead of time, though could be enabled/disabled) I built up a tree of run order and just greedily grabbed systems from the tree to run their update calls. Branches in a tree could not go 'up' until the previous layer of those nodes were done, but other nodes could go up fine if they completed first. It was pretty simple but it worked well for me. I did not show off the 'optional' components that a system might access in my example above but those were used in the tree so optional's counted as full access, even though they were not touched for the family/cache registration.

[torkleyy]

@OvermindDL1

So you store a topological sort of the systems in order to estimate which system is likely to be executed next? And additionally a graph for actually checking this?

EDIT: I just read you're only talking about a tree. So you're actually doing most of this stuff at runtime? That's actually what I have so far, because I couldn't find a clever way of precomputing anything... Seems to be a NP-complete problem.

[OvermindDL1]

@torkleyy It is generated at runtime on load since I may not know the systems I'll be loading in to the world at compile-time, but I do know what I will be loading in by the time I instance the world. It is a topological sort though, with an 'end-node' to handle special events (my systems can be set to read only from a components so they can run concurrently with others that read only, but I have a lot of mine do that but instead send 'changesets' to another system that is processed at the end of all the other to run a callback to to make actual changes after checking that the preconditions are met, this is a pretty complex part of mine that you have to be careful to get right so it is only used for certain kind of trivially parallizable areas).

And yes, it is NP-complete, just cache it on world/ecs load and only read it from then-on out. It does not always generate the 'best' tree, but I have not really cared enough to fix that.