Is `fire-rules` parallelizable?

[ul]

Hey, thanks for the cool library, it made state management in the game I work on much simpler! I noticed that when I have rules for complex behaviours triggered every tick on a busy map they consume quite a lot of CPU. This is expected, of course, but I'm thinking if there is a way to increase the limit of entities I can process with these rules by parallelizing rules dependency graph execution?

[ul]

I did a brief search, and there is not much published about parallel Rete variations. Rate-NT allegedly is parallel but is closed source; there is also Lana described here https://core.ac.uk/download/pdf/266100752.pdf and TWIN here https://ieeexplore.ieee.org/document/120847

[oakes]

Hi again :D I haven't tried it but in theory I think each iteration of rule firing could be parallelized. The order they run in shouldn't matter (hence why then-queue and then-finally-queue are sets) and after running them in parallel I guess you could aggregate their subsequent changes to the session. But I'm not sure this would make up for the cost. The easier thing to try first would be to maintain multiple separate sessions on each thread, but that would only make sense if your game state could be segmented like that.

[ul]

Yeah, I guess running separate sessions is a technically easy way to make things faster, but it also puts back a lot of explicit thinking about data design that having a single giant DB of triplets freed me from 🤣 Since I asked this question, I have ported my burgeoning game to Nim since then, which gave me a bit of perf margin already.

But I'm not sure this would make up for the cost.

Maybe it would make up if we ran it on a warm thread pool rather than creating and destroying threads per function. But, of course, only the experiment will show for sure. Maybe I'll try at some point with the Nim implementation once parazoa-related optimisations are exhausted.