第1章 从面向对象到面向数据

性能瓶颈的转移

章节导读

在计算机发展的早期，程序员的敌人是CPU。1970年代的处理器主频只有几兆赫兹，一条乘法指令可能需要几十个时钟周期，内存反而相对"快"——至少内存与CPU之间的速度差距并不悬殊。那个时代的优化技巧围绕着如何减少指令数展开：查表代替计算、位运算代替算术运算、循环展开减少分支。面向对象编程正是在这样的背景下逐渐成熟起来的：既然CPU是瓶颈，那么用抽象来管理日益复杂的软件结构就是划算的买卖，多态、继承、封装带来的间接开销与CPU的缓慢相比不值一提。

然而从1980年代开始，情况发生了戏剧性的变化。得益于摩尔定律和一系列微架构创新（流水线、乱序执行、分支预测、超标量），CPU主频以每年约60%的速度增长，三十年间提升了大约500倍——从4MHz的8088到4GHz以上的现代处理器。但DRAM内存的访问延迟呢？同期只改善了大约2倍。1980年访问主存需要约200纳秒，相当于几百个CPU周期；今天访问主存仍然需要约60-100纳秒，但这已经相当于两三百个CPU周期。换句话说，以CPU周期衡量，内存变慢了一百倍。这就是著名的"内存墙"（Memory Wall）问题。

为了缓解这道墙，硬件工程师在CPU和主存之间插入了多级缓存：L1缓存约3-4个周期，L2约10-14个周期，L3约40-70个周期，主存则是200-300个周期。一次L1命中与一次主存访问之间的差距高达百倍。于是性能瓶颈悄然转移了：现代程序的性能不再主要取决于执行了多少条指令，而取决于数据能否及时喂给CPU。一个缓存不友好的程序，其CPU利用率可能只有5%——也就是说，昂贵的执行单元95%的时间都在空转等待数据。

面向对象设计（OOD）诞生并繁荣于CPU瓶颈时代，它的核心抽象——对象、继承层次、虚函数、指针链接的容器——在缓存时代暴露出严重问题。考虑一个典型的粒子系统：一万个粒子，每个粒子是一个Particle对象，包含位置（3个float）、速度（3个float）、颜色（4个字节）、生命周期、渲染状态、指向材质的指针等，总共约128字节。每帧更新时我们只需要位置和速度共24字节，但由于对象在内存中连续布局（AoS，Array of Structures），CPU每次加载一个64字节的缓存行，其中只有24字节是有用的——缓存利用率不到20%。更糟的是，如果粒子通过指针存储在std::vector<Particle*>中，它们可能散落在堆的各个角落，每次访问都是一次潜在的缓存未命中。

面向数据设计（DOD）给出的答案简单得令人吃惊：把同类数据放在一起。将一万个粒子的x坐标存成一个数组，y坐标一个数组，z坐标一个数组，速度同理（SoA，Structure of Arrays）。更新位置时，CPU加载的每一个缓存行都是100%有用的数据，内存带宽利用率提升数倍，实测性能提升可达7倍。这不是什么黑魔法，只是让数据布局匹配访问模式。

本章将带你完成从"以对象为中心"到"以数据为中心"的思维转变。我们会追溯性能瓶颈转移的历史，剖析OOD抽象在缓存时代的真实成本，并给出DOD的三个核心问题：我们有什么数据？我们如何访问这些数据？数据如何随时间变化？Richard Fabian在书中反复强调，面向数据设计不是一种新的编程语言特性，而是一种思考方式——把程序看作数据变换的流水线，而不是对象之间发消息的社交网络。这种视角转换是后续所有章节（缓存友好结构、SIMD、组件化）的基础。

核心概念

• AoS vs SoA
• 缓存命中率
• 内存带宽
• 数据局部性

要点精析

CPU与内存速度的历史分化是理解DOD的起点。1980年的Intel 8088主频4.77MHz，访问主存约200纳秒，折合不到1000个周期；2020年的处理器主频可达5GHz，访问主存仍是约80纳秒，但已折合400个周期以上。三十年间CPU快了约500倍，DRAM延迟只改善了约2倍，两者之间出现了两个数量级的鸿沟。硬件的应对方案是缓存层次结构：现代CPU普遍有32-48KB的L1数据缓存（4周期）、256KB-1MB的L2（12周期）、8-32MB的共享L3（40-70周期），最后才是200-300周期的主存。这意味着同一个"读内存"操作，根据数据在不在缓存中，成本可以相差100倍。程序员如果忽视这个层次结构，就等于在按1980年的假设写2020年的代码。DOD的第一原则由此而来：让程序访问的数据尽可能留在缓存里，让每次缓存行加载都物有所值。

AoS（Array of Structures）布局的缓存浪费可以用粒子系统精确量化。假设Particle结构体包含位置vec3（12字节）、速度vec3（12字节）、颜色rgba（4字节）、生命值float（4字节）、状态枚举（4字节）、材质指针（8字节）、回调函数指针（8字节）以及若干其他字段，总计128字节。每帧物理更新只读写位置和速度共24字节。在AoS布局下，一万个粒子占据1.28MB内存，而更新所需的数据只有240KB。CPU以64字节缓存行为单位加载数据，每行128字节的结构体跨越两行，其中有效数据仅24字节，缓存利用率约为24/128=18.75%。这意味着为了完成240KB的有效数据搬运，实际要从内存读取1.28MB——超出L2容量，每帧都产生大量缓存未命中。这就是OOD"把相关行为和数据封装在一起"的直觉在性能上的代价：封装单元（对象）与访问单元（字段子集）不匹配。

SoA（Structure of Arrays）布局通过按字段拆分数组，让缓存利用率接近100%。将粒子系统改写为float x[10000], y[10000], z[10000], vx[10000], vy[10000], vz[10000]之后，位置更新循环只触碰x、y、z、vx、vy、vz六个数组，每个数组40KB，总计240KB——恰好是有效数据量，没有任何浪费。每个64字节缓存行装载16个连续的float，全部参与计算。实测中，SoA版本相比AoS版本在位置更新上通常有5-7倍的性能提升，这个数字来自三方面：缓存未命中减少（带宽利用率提升约5倍）、硬件预取器能够识别简单的顺序访问模式并提前加载、以及紧凑的循环体让编译器更容易进行自动向量化。SoA不是万能药——如果访问模式是"随机取一个粒子的全部字段"，AoS反而更好——但它完美匹配了游戏和科学计算中最常见的模式：对所有实体的同一字段做批量变换。

DOD的三个核心问题构成了完整的设计方法论。第一问：我们有什么数据？这要求开发者像数据库设计者一样列出所有实体和属性，而不是像OOD那样先画类图。第二问：我们如何访问这些数据？哪些字段总是一起被读写？访问是顺序的还是随机的？频率是每帧一次还是每秒一次？第三问：数据如何随时间变化？哪些字段是热数据（每帧更新），哪些是冷数据（初始化后几乎不变）？回答这三个问题后，数据布局几乎是自动推导出来的：一起访问的数据放在一起，访问频率不同的数据分开存放，批量变换的数据排成连续数组。Fabian指出，这三个问题本质上就是关系数据库设计中的范式化思想在内存布局上的应用——数据库工程师五十年前就知道不要把冷字段和热字段放在同一张表里，而游戏程序员直到2000年代才重新发现这个道理。

虚函数与指针追逐（pointer chasing）是OOD的两大隐形成本。虚函数调用本身只多几条指令（加载vtable指针、间接跳转），真正的代价在于：第一，间接跳转难以被分支预测器预测，一次预测失败要浪费15-20个周期；第二，vtable本身可能不在缓存中；第三，虚函数阻碍编译器内联，而内联是后续所有优化（常量传播、向量化）的前提。指针追逐则更致命：链表、树、std::map、vector<T*>这类结构，每次解引用指针都可能触发一次缓存未命中，而且由于下一个节点的地址存储在当前节点中，硬件预取器完全无法预测，未命中延迟无法被隐藏。一个遍历百万节点链表的循环，即使每个节点只做一次加法，也可能因为每节点一次约100纳秒的未命中而耗时0.1秒——计算本身只需要不到1毫秒。DOD的答案是用连续数组加索引（或称"槽位映射"）替代指针结构，把不可预测的随机访问转化为可预测的顺序访问。

把程序理解为数据变换（transformation of data）是DOD的哲学内核。OOD的世界观是"对象互相发送消息"，程序是一张对象协作图；DOD的世界观是"数据从一种形态流动到另一种形态"，程序是一条流水线。以游戏为例：输入设备产生原始事件数据，变换为游戏意图；意图数据与实体状态数据结合，变换为新的实体状态；实体状态变换为动画姿态数据；姿态数据变换为顶点缓冲；顶点数据变换为像素。每个阶段都是"读入一批数据、写出一批数据"的纯变换。这种视角的好处是：每个变换阶段可以独立选择最优的数据布局和算法，阶段之间的接口是明确的数据格式而非模糊的对象协议。这也解释了为什么图形API（OpenGL、Vulkan、DirectX）全部采用DOD风格——顶点缓冲、索引缓冲、常量缓冲，全是SoA式的裸数据数组，因为GPU本身就是极致的数据变换机器。

游戏工业从OOD到DOD的转型提供了最有说服力的真实案例。2000年代中期，主流游戏引擎普遍采用深度继承层次：GameObject派生出Character，Character派生出PlayerCharacter和EnemyCharacter，每个类携带自己的虚函数和成员数据。随着实体种类爆炸（RPG中数百种物品、NPC、载具），这种设计导致三大问题：内存中对象布局碎片化、更新循环充满虚调用和类型分支、新增能力需要修改继承树。2007年前后，以《地牢围攻》的GDC演讲为标志，组件化架构（后来演化为ECS）开始流行；2010年代，DICE的Frostbite、Unity的DOTS、守望先锋的ECS相继证明数据导向架构能支撑数百个实体的每帧模拟。守望先锋的开发团队报告，将粒子系统从OOP重写为SoA布局后，同样的硬件上粒子数量提升了近一个数量级。这些案例的共同点是：转型不是为了代码优雅，而是为了在固定的硬件预算内塞进更多游戏内容。

OOD的抽象成本在缓存时代被系统性低估。封装告诉我们"不要关心对象内部表示"，但DOD指出：在性能关键路径上，内部表示恰恰是你最需要关心的东西。一个std::list<Node>在接口上与std::vector<Node>同样优雅，性能却可能相差50倍以上；一个持有shared_ptr成员的对象图，其遍历成本是连续数组的数十倍。抽象的价值在于隐藏变化，但当"数据在内存中如何摆放"成为性能的决定因素时，把它隐藏起来就等于放弃了控制权。Fabian的立场并非废除抽象，而是重新划定抽象的边界：在业务逻辑层、UI层，OOD的抽象依然是管理复杂性的最佳工具；在每帧执行百万次的模拟内核、渲染管线、物理求解器中，抽象必须让位于对数据的直接掌控。判断标准很简单：这段代码每秒执行多少次？处理多少数据？如果答案是"百万次、兆字节级"，就该用DOD。

分支与数据依赖是另一个被忽视的维度。OOD代码中常见的模式是遍历异构对象集合，对每个对象做类型判断或虚调用——这产生了数据依赖的分支流，分支预测器面对交替出现的类型时命中率骤降，每次预测失败代价15-20个周期。DOD通过"按类型分批处理"消除这类分支：与其遍历所有实体并问"你是不是可渲染的？"，不如维护一个可渲染实体的索引数组，直接遍历它。这就是所谓的数据驱动控制流：用数据的组织方式替代运行时的条件判断。同样的思想也体现在排序预处理上——先按材质对绘制对象排序，再顺序绘制，把渲染状态切换（昂贵）转化为数据重排（一次性成本）。分支消除带来的收益常常与缓存收益叠加，这也是为什么DOD重构后的代码往往有超出预期的加速比。

最后必须澄清DOD的适用边界，避免走向另一个极端。DOD不是要取代OOD，而是补充OOD。对于用户界面、业务规则、配置管理、网络协议解析这类代码，瓶颈在人的理解速度而非机器的执行速度，OOD的封装、继承、多态依然是正确的选择——强行SoA化只会让代码难以维护而毫无性能收益。DOD的主战场有三个特征：数据量大（万级以上实体）、变换频繁（每帧或每次请求）、模式规整（同类数据做同类操作）。游戏引擎的模拟与渲染、数据库的存储引擎、科学计算的数值内核、机器学习框架的张量运算，都属于这一类。一个成熟的工程团队会采用分层策略：外层用OOD组织系统架构，内层热点用DOD组织数据与算法，两层之间用清晰的接口隔离。这种混合策略正是本书第5章实践指南的核心内容。

代码示例

struct Particle {
  float px, py, pz;
  float vx, vy, vz;
  unsigned char r, g, b, a;
  float lifetime;
  int state;
  void* material;
  void (*onDeath)(Particle*);
  float pad[10];
};

Particle particles[10000];

void updateAoS(float dt) {
  for (int i = 0; i < 10000; ++i) {
    particles[i].px += particles[i].vx * dt;
    particles[i].py += particles[i].vy * dt;
    particles[i].pz += particles[i].vz * dt;
    particles[i].lifetime -= dt;
  }
}

上面是典型的AoS粒子系统。Particle结构体共128字节，其中每帧更新真正需要的只有px、py、pz、vx、vy、vz和lifetime共28字节，缓存利用率约22%。一万个粒子占1.28MB，超出典型L2缓存容量，updateAoS每帧都会产生数千次缓存未命中。注意结构体中的material指针和onDeath函数指针——它们只在粒子死亡时才被访问，却占据了每个缓存行的宝贵空间，把热数据（位置速度）挤得更分散。这个例子展示了OOD封装直觉的直接后果：把"概念上属于同一个东西"的数据放在一起，而不是把"时间上一起被访问"的数据放在一起。用perf stat测量这段代码，会看到L1-dcache-load-misses高得惊人，IPC（每周期指令数）低于0.5。

struct ParticleSystem {
  float px[10000], py[10000], pz[10000];
  float vx[10000], vy[10000], vz[10000];
  float lifetime[10000];
  unsigned char rgba[10000][4];
  int state[10000];
  void* material[10000];
};

void updateSoA(ParticleSystem* ps, float dt) {
  for (int i = 0; i < 10000; ++i) {
    ps->px[i] += ps->vx[i] * dt;
    ps->py[i] += ps->vy[i] * dt;
    ps->pz[i] += ps->vz[i] * dt;
    ps->lifetime[i] -= dt;
  }
}

SoA版本将每个字段拆分为独立数组。updateSoA只触碰px、py、pz、vx、vy、vz、lifetime七个数组，共280KB，且每个数组内部完全连续。CPU加载的每个64字节缓存行包含16个有效float，利用率100%。硬件预取器能识别这种简单的顺序流并提前数个缓存行加载数据，使未命中延迟几乎完全被隐藏。更重要的是，这个循环体是编译器自动向量化的理想目标：无分支、无指针别名、固定步长，开启-O3和-march=native后GCC/Clang会自动生成AVX指令，一次处理8个float。实测中SoA版本相比AoS版本加速5-7倍，若再叠加手动SIMD可达10倍以上。注意冷数据（rgba、material、state）被隔离到独立数组，只有渲染和死亡处理阶段才会加载它们，物理更新阶段的缓存完全留给热数据。

struct Node {
  int value;
  Node* next;
};

int sumList(Node* head) {
  int sum = 0;
  while (head) {
    sum += head->value;
    head = head->next;
  }
  return sum;
}

int sumArray(const int* values, int n) {
  int sum = 0;
  for (int i = 0; i < n; ++i) sum += values[i];
  return sum;
}

这组对比展示了指针追逐的代价。sumList遍历链表，每个节点16字节（value加next指针）分散在堆上，next指针形成不可预测的依赖链：必须先加载当前节点才能知道下一个节点的地址，硬件预取器完全失效。一百万个节点的链表求和，若节点全部未命中缓存，每次约100纳秒，总耗时约0.1秒。sumArray处理同样一百万个int（4MB连续内存），预取器全速工作，缓存行利用率100%（64字节行装16个int，而链表节点每64字节只有4字节有效数据），总耗时约1毫秒——相差100倍。这就是DOD对"用指针表达关系"的根本性质疑：在缓存时代，索引数组、连续存储、批量遍历几乎总是优于链式结构。链表在教科书中的O(1)插入优势，在真实硬件上常被缓存未命中完全吞噬。

实验笔记

本实验要求你亲手测量AoS与SoA布局的性能差距，建立对缓存效应的定量直觉。实验分为四个部分。第一部分：环境搭建与基准测试框架。编写一个C++程序，包含AoS和SoA两个版本的粒子系统（各10万粒子），使用std::chrono::high_resolution_clock测量update函数执行1000次的总耗时，取中位数。编译时使用-O2（先不要开-O3，避免自动向量化混淆变量）。预期结果：SoA版本快4-8倍。第二部分：缓存利用率验证。使用perf stat -e cache-references,cache-misses,L1-dcache-load-misses ./benchmark分别测量两个版本，计算缓存未命中率。AoS版本的L1未命中率应显著高于SoA版本。同时用perf record和perf report定位热点，观察cycle事件在内存等待上的分布。第三部分：变量扫描实验。改变粒子数量（1千、1万、10万、100万），绘制性能比值曲线。你会发现当数据总量小于L2缓存时两者差距较小，超过L2后差距急剧拉大，超过L3后趋于稳定——这条曲线就是缓存层次结构的"指纹"。第四部分：混合布局探索。尝试一种折中方案：将位置和速度打包为struct HotData { float px,py,pz,vx,vy,vz; }的AoS数组（48字节，热数据紧凑），冷数据另放。测量其性能并与纯SoA对比，思考为什么48字节的热结构体（不足一个缓存行）也能获得接近SoA的性能。提交实验报告，包含测量数据表、perf输出截图、以及对第三部分曲线的解释。进阶挑战：用Intel VTune的Memory Access分析查看两个版本的带宽利用率，并尝试用编译器探索报告（GCC的-fopt-info-vec-missed）解释SoA版本为何能被自动向量化而AoS版本不能。

延伸阅读

• 《What Every Programmer Should Know About Memory》（Ulrich Drepper）：这篇2007年的长篇论文是缓存硬件的权威入门，详细解释了DRAM物理结构、缓存层次、TLB和NUMA。DOD的所有技巧都建立在这篇文档描述的硬件现实之上，建议至少精读第2、3章。
• 《The Memory Wall》系列博客（Norbert Juffa等）：多篇文章用实测数据展示了1980年至今CPU与内存速度的分化曲线，是理解"性能瓶颈转移"这一历史叙事的最直观材料，图表丰富，适合建立数量级直觉。
• Mike Acton的GDC 2014演讲《Data-Oriented Design and C++》：CERN工程师出身的Acton用大量真实测量数据炮轰OOD教条，是DOD社区最著名的布道演讲。其中" purpose of all programs is to transform data"的论断已成为DOD的口号。
• 《Pitfalls of Object Oriented Programming》（Tony Albrecht, GDC 2009）：以游戏引擎为例逐项分析虚函数、继承层次、容器选择带来的缓存成本，是游戏工业转向DOD的标志性演讲，配套幻灯片数据详实。
• 《Game Programming Patterns》（Robert Nystrom）第12章Data Locality：用循序渐进的示例代码讲解AoS、SoA、热冷分离等布局技巧，写作风格平易近人，适合作为Fabian原书的补充入门读物，全书可在网上免费阅读。
• Intel 64 and IA-32 Architectures Optimization Reference Manual：官方优化手册，第3章General Optimization Guidelines和第7章Optimizing Cache Usage提供了缓存行、预取、伪共享的硬件级细节，是深入验证DOD技巧的第一手资料。