Understanding ECS. The L1 and L2 cache and What makes ECS so fast?

As explained in this video.

And this Wikipedia page.

Data-Oriented ECS? L1 and L2 cache.

this post is a continuation of the previous post, so if you haven't read it please do!

Whenever we try to access and update a position component in our ECS (Entity Component System), for example, if we were using Object-Oriented techniques the entire object would get loaded into memory to just update the position. That's fine if you're not trying to make a mass-scale super Triple-A engine and all you want to do is get Georgy here to walk across the screen. In that case, ECS might be completely overkill. But if you are wanting to handle millions of Entities at once, memory efficiency becomes more important. You can see what using conventional Object-Oriented techniques might look like, and why it's inefficient below:

As you can see we're loading all of Geargy and lots of components that we really don't care about. And it limits our ability to update lots of Georgy's. With ECS you only touch the data that you care about, and as a result, you can handle a LOT more Georgy's:

What you see above could be represented as a CPU cache. CPU cache? You can think of a CPU cache as essentially a super small very fast RAM that is very close to the processor. This Wikipedia page explains what caches do as:

When trying to read from or write to a location in the main memory, the processor checks whether the data from that location is already in the cache. If so, the processor will read from or write to the cache instead of the much slower main memory.

So you can see why it matters how we use the caches. And whenever we touch some data it uses up those caches. If we touch data as lightly as possible to use up as little of our cache as possible we'll be able to process a lot more, a lot faster. That is what ECS does for us and why it's so great! it helps us only touch the data we care about, therefore speeding up processing and using up less of our cache! 

ECS is just a name...

You can call this data structure whatever you want, but Unity has popularized "ECS" so I have been using the name. I was even thinking of making up my own name. Maybe DCS (Database Component System) or even ACPS (Archetype Component Processor System). But then people might not know what I am talking about so I'll stick with ECS for now.

Data-Oriented?

I'm pretty sure when people like Mike Acton (Acton not Action) talk about data-oriented, they're really just focusing on data-layout and "touching" as little data as possible as efficiently as possible, and not focusing on the actual code (eg. the actual code that moves our Georgy here across the screen) now you can see why. Because when you're wanting to make a super awesome game with TONS of enemies and massive physics terrain etc, that really just translates to a LOT of data. In the end, we are trying to maximize the amount of data our processors can handle, and that leads to making bigger and better games, with bigger worlds and more players and more features... you get the point.


I hope this post helped some of you with your questions, and if I got anything wrong, please, leave a comment and let me know I'll do my best to fix it. I didn't include any code in this post because I think just getting the concept down really well helps more than actual code examples.