Entity component system which is the CPU cache

Question

I can not find any framework implementation that is friendly to the CPU cache, which means that the data about which systems pass in each cycle of the game cycle is stored in adjacent memory .

Let's see, systems intersect with specific objects that satisfy their conditions, that is, the object must contain components A, B, C, which must be processed by system X. This means that I need continuous memory containing all entities and components (and not links, since the links are not cache related and you will have a lot of cache misses) to get them from RAM as fast as possible while processing the X system. But immediately after processing system X, system Y starts working with a set of objects satisfying its egall conditions containing A and B. This means that we are dealing with the same set of objects as system X, and some other objects that have A and B. This means that we have two contiguous memories that have duplicate data.First of all, data duplication is very bad for well-known reasons. And this, in turn, means that we need synchronization, which again is not a cache cache, because you need to find some objects from one vector and update new data that is contained in another vector.

This is just one of my thoughts. There are other, more realistic thoughts for the Entity Component System Framework data model, but in each model I could understand that there is the same problem: during each cycle of the game cycle, you cannot prevent many cache misses due to disjoint data.

Can someone suggest a version, article, example, just something on this topic that can help me understand which data model should be used to get a caching design, since this is one of the most important things in game performance.

Answer 1

I would go with the junkdog answer (since I wrote a related article;)), but here is another, different, take it:

, :

• ...
• /
• ... ..

, / , ( ) , . mem-management. , , , ( AAA AA? ?)... ..) ( , )

, ES tryign , , , .

Answer 2

/t = : - , ECS .

, java- entreri artemis-odb ( PackedComponents/, : ) , " 1: BigArray ".

Answer 3

, , , . , , . /. , , , , .

, , , , , , , , . .

, , . ( ):

- :

:

radix, , . , , , . -, ( , ), . ( ), ( /, ), .

, ( , ), , , , , , , , , , .

, , , , , , , , , , , . , , .

I never found the need to go that far. I just do generalized sorting against entity identifiers from time to time in order to generally improve access patterns of all systems (but without an optimal solution for any given system). Your use case may require an optimal version, but I would suggest just focusing on key systems with big hot spots that really benefit from this.