如何从实体组件系统游戏引擎中的cpu缓存中受益？

我经常阅读ECS游戏引擎文档，这是明智使用cpu缓存的良好架构。

但是我不知道如何从cpu缓存中受益。

如果将组件保存在连续内存中的数组（或池）中，则只有在顺序读取组件的情况下，才是使用cpu缓存BUT的好方法。

当我们使用系统时，它们需要实体列表，这些列表是具有特定类型组件的实体列表。

但是这些列表以随机的方式而不是顺序地提供了组件。

那么如何设计ECS以最大化缓存命中率呢？

编辑：

例如，物理系统需要具有RigidBody和Transform组件的实体的实体列表（有一个RigidBody池和一个Transform组件池）。

因此，其更新实体的循环将如下所示：

for (Entity eid in entitiesList) {
    // Get rigid body component
    RigidBody *rigidBody = entityManager.getComponentFromEntity<RigidBody>(eid);

    // Get transform component
    Transform *transform = entityManager.getComponentFromEntity<Transform>(eid);

    // Do something with rigid body and transform component
}

问题在于，entity1的RigidBody组件可以在其池的索引2处，而entity1的Tranform组件在其池的索引0处（因为某些实体可以具有某些组件，而其他组件不能具有其他组件，并且是因为添加/删除了实体/组件）。

因此，即使组件在内存中是连续的，也会随机读取它们，因此它将有更多的缓存未命中，不是吗？

除非有一种方法可以预取循环中的下一个组件？

Mick West的文章全面介绍了线性化实体组件数据的过程。几年前，它在Tony Hawk系列产品上使用了比现在少得多的令人印象深刻的硬件，从而极大地提高了性能。他基本上对每种不同类型的实体数据（位置，得分和诸如此类）使用了全局的，预先分配的数组，并在他的系统范围update()功能的不同阶段引用了每个数组。您可以假设每个实体的数据在这些全局数组的每个数组中都位于相同的数组索引，因此，例如，如果首先创建播放器，则它的数据可能[0]在每个数组中。

Christer Ericsson针对C和C ++ 的幻灯片甚至更具体地介绍了缓存优化。

为了提供更多细节，您应该尝试针对每种数据类型（例如position，xy和z）使用连续的内存块（最容易分配为数组），以确保良好的引用局部性，并在每个数据块中分别使用update()为了临时性起见，请在各个阶段进行操作，即确保在给定update()调用中重用要重用的任何数据之前，不通过硬件的LRU算法刷新高速缓存。正如您所暗示的那样，您不想通过分配实体和组件为离散对象new，因为每个实体实例上不同类型的数据将被交织，从而减少了引用的位置。

如果您在组件（数据）之间存在相互依赖关系，以至于您绝对无法承受将某些数据与其关联数据（例如，Transform + Physics，T​​ransform + Renderer）分开的话，则可以选择在Physics和Renderer阵列中复制Transform数据。 ，以确保所有相关数据都适合每个关键性能操作的缓存行宽度。

还请记住，L2和L3缓存（如果可以在目标平台上假设这些缓存）在减轻L1缓存可能遭受的问题（例如行宽限制）方面起到了很大的作用。因此，即使在一次L1丢失时，这些安全网也通常会阻止对主内存的调用，这比对任何级别的缓存的调用要慢几个数量级。

关于写入数据的注意事项写入不会调出到主存储器。默认情况下，当今的系统启用了写回缓存：写一个值仅将其写到（初始）缓存中，而不是写到主内存中，因此您不会因此而成为瓶颈。仅当从主内存请求数据时（缓存中不会发生数据）并且陈旧时，才会从缓存中更新主内存。