Arceus.jl — A Lightning-Fast Behavior Resolution System

As I said, that ECS, is mathematically faster than what exist, dispatching entities to systems is O(s) where s is the number of systems
The package has archetypes but they contains entities index, which can be used to get any data about an Entity.
So systems get only the data they subscribed for (that is why the third argument of run! is a WeakRef to a vector of relevant indices) OR can decide to access ANY other components if they want to.
The number of entity doesn’t matter, nor the number of components doesn’t matter for dispatching.

For processing, I made it in such way optimization can be customized by the users.

I understand you are sceptical about this, but trust me, I readed numerous article and research paper about ECS and I guarantee you this ECS is optimal. And with Arceus added to it, it can become crazy fast. That’s why I forked this package :cowboy_hat_face:

And I will try Flecs discord, so that I can mind blow them, like if my computer fuelled with hopes, dreams, determination, intermittent electricity and potatoes can reach such speed, imagine on modern computer :smirking_face:

1 Like

As for your example, “1k components, 1M entities”. No ECS can handle that efficiently. Why ? because that amount of memory can’t be stored in the cache of the CPU. If we are unable to use the cache, we lose all the optimisation the ECS was made for and pay the price with latencies from the RAM.
ECS heavily leans on cache for fast access and processing. With 1k components, we risk having too much archetype, which will break memory locality and block SIMD/vectorization (which shine on large contiguous data), only leaving threading as a possible solution (which penalize CPU with less core.).
There will also be too much queries to do, one for each archetype (and queries are a well know slow down in archetypal ECS).
You may think “that why we should fuse them updates !” but as I said, it’s mere logic, if something is fusable, the user will be able to do it with some efforts. And to clarify more than 100 components/scene is already a rare case.
So for that very hypothetical situation, no ECS can handle that efficiently.
Why ? Because computer are not magic box with infinite power, they are limited and optimizations are often clearly bounded to some conditions.

Well, 1k component, 1M entities, maybe some ECS can’t handle that, but if it’s sparse, some can. Most entities might only have 20 components. Yeah…

yeah… :sweat_smile: