May be this talk can explain more, about how it works on hardware and as result helps you to understand - performance depends on cache size or not (timing 3:10:00)
Watched it and apart from the fact that ECS is locked at 16k chunks no mention of the benchmark impact of different cache sizes or chip types or SIMD instruction sets on Burst performance.
What would be the best ECS/Burst demos/samples to be used as a benchmark to test ECS on different CPUs?
I really don’t understand what are you aiming for with this, but just like they are testing CPUs on different applications, you can do the same, just write a very large and demanding application using ECS and run on different CPUs.
Or if Unity releases the MegaCity demo, that would do in my opinion.
Since the memory access pattern when using ECS tends to be much more linear, does the CPU cache size still matter that much as it does for random access?
To test this we need a single application and several almost identical CPUs with just different amounts of cache. That is a problem if you don’t have a test lab.
Exactly what happens when you as a developer put together an amazing ECS game and it runs amazingly on your PC and test hardware but nowhere near as well on players pc hardware.
As a general rule of thumb, larger and larger caches, longer out of order execution pipes etc have the largest positive impact on poorly laid out code. OO code, branchy code, code with non-linear memory access.
Linear memory access is always the fastest thing you can do regardless of how big or small the cache is or what hardware it is running on. A larger cache improves things for ECS linear data layout too of course, but the code doesn’t rely on it to get great perf. It doesn’t fall off a cliff when the cache is too small…
Thats one of the awesome properties of ECS, that it scales well to old hardware.