Entity Component System Framework that is CPU cache friendly

Question

I can not find a single framework implementation that is CPU cache friendly, which means that data on which systems traverse in each game loop cycle is stored in a contiguous memory.

Let's see, systems traverse on specific entities that satisfy their conditions, i.e. the entity should contain A, B, C components to be processed by X system. This means that I need a contiguous memory that contains all entities and components (not references, as far as references are not cache friendly, and you will have lots of cache misses) in order to obtain them from RAM as much fast as it is possible during the processing of X system. But right after the processing of X system, Y system starts to operate on a set of entities that satisfy to its conditions e. g.all entities containing A and B. This means that we deal with the same set of entities as X system plus some other entities that have A and B. This means that we have two contiguous memories which have duplicate data. First of all data duplication is very bad for known reasons. And also this, in its turn, means that we need a synchronization, which again is not CPU cache friendly as far as you need to find some entities from one vector and update with the new data which is contained in another vector.

This is just one of my thoughts. There are other, more realistic, thoughts for Entity Component System Framework data model, but in each model I could figure out there is the same problem: during each game loop cycle you can not prevent lots of cache misses because of not contiguous data.

Can anyone please suggest an implementation, article, example just something on this topic, that can help me understand what data model should be used to obtain cache friendly design, as this is one of the most critical things in game performance.

Answer 1

I would go with junkdog's answer (since I wrote the linked article ;)), but here's another, different, take on it:

If you want cache-friendly design, you need to list:

1. Your microprocessor
2. Your processor architecture
3. Your bus architecture
4. ...
5. Your per-sub-frame working-set size
6. Your total working set / RAM for all game-objects
7. The amount of interconnections in your specific game
8. ... etc

Depending on how tight/loose those requirements are, you will have different easy (or hard) decisions to make about your design. Game developers re-write mem-management frequently. They don't do this because they're stupid, they do it because it's easy / worthwhile to (re-)optimize per project (is this a AAA title? or a AA title? Are graphics more important? Or network latency? ... etc) and per-hardware (on PC, the target hardware changes every month)

I recommend you pick a set of hardware, create a simple ES-based game, and start tryign to design a cache-friendly mem usage - and document it publically, make it all open-source, and see if you can get other people interested in running your benchmarks.