实体组件系统框架,CPU缓存友好

Nar*_*rek 4 data-modeling entity-system artemis

我找不到一个CPU缓存友好的框架实现,这意味着每个游戏循环周期中系统遍历的数据存储在连续的内存中.

让我们看看,系统遍历满足其条件的特定实体,即实体应包含要由X系统处理的A,B,C组件.这意味着我需要一个包含所有实体和组件的连续内存(不是引用,只要引用不是缓存友好的,并且你将有很多缓存未命中),以便尽可能快地从RAM中获取它们在X系统的处理过程中.但是在处理X系统之后,Y系统开始在满足其条件的一组实体上运行,例如包含A和B的所有实体.这意味着我们处理与X系统相同的一组实体以及其他一些实体.有A和B.这意味着我们有两个连续的记忆,它们有重复的数据.首先,由于已知原因,数据复制非常糟糕.而且,这反过来意味着我们需要一个同步,只要你需要从一个向量中找到一些实体并使用另一个向量中包含的新数据进行更新,这同样不再是CPU缓存.

这只是我的一个想法.对于实体组件系统框架数据模型还有其他更现实的想法,但在每个模型中我都可以发现存在同样的问题:在每个游戏循环周期中,由于不连续的数据,您无法阻止大量缓存未命中.

任何人都可以建议一个实现,文章,这个主题的例子,这可以帮助我理解应该使用什么数据模型来获得缓存友好的设计,因为这是游戏性能中最关键的事情之一.

Ada*_*dam 7

我会选择junkdog的答案(因为我写了链接的文章;)),但这是另一个,不同的,接受它:

如果您想要缓存友好的设计,您需要列出:

  1. 你的微处理器
  2. 你的处理器架构
  3. 你的巴士架构
  4. ...
  5. 您的每子框架工作集大小
  6. 所有游戏对象的总工作集/ RAM
  7. 特定游戏中的互连量
  8. ......等

根据这些要求的紧密程度或松散程度,您将对设计做出不同的简单(或难以)决策.游戏开发人员经常重新编写内存管理.他们不这样做是因为他们是愚蠢的,他们这样做是因为每个项目(重新)优化每个项目很容易/值得(这是一个AAA标题?还是AA标题?图形更重要吗?还是网络延迟? ..等)和每个硬件(在PC上,目标硬件每月更改)

我建议你选择一套硬件,创建一个简单的基于ES的游戏,并开始尝试设计一个缓存友好的内存使用 - 并公开记录,使其全部开源,看看你是否可以让其他人感兴趣在运行你的基准测试.