1. 回测系统性能瓶颈分析：为什么内存布局和缓存优化如此重要？
做量化回测的朋友，十有八九都遇到过这个问题：策略逻辑明明没问题，可回测跑起来就是慢得像蜗牛。你加再多核心、上再高主频，速度就是上不去。
我刚开始做回测系统时也踩过这个坑。当时写了一个看起来挺漂亮的策略，逻辑清晰、代码整洁，结果一跑历史数据——好家伙，5年的分钟级数据，跑了快两个小时。我当时就纳闷：CPU占用率才30%多，内存也没用满，到底卡在哪了？
后来我才明白，问题出在内存布局和缓存上。说白了，你的CPU大部分时间不是在算数据，而是在等数据。
冯·诺依曼瓶颈：CPU快，内存慢
先说说这个老生常谈的问题。冯·诺依曼架构下，CPU和内存是分开的。CPU每秒能处理几十亿条指令，但内存的响应速度呢？大概只有CPU的十分之一甚至更慢。
这就好比一个顶级大厨（CPU）配了一个慢悠悠的传菜员（内存）。大厨一分钟能炒10道菜，可传菜员一分钟只能端1道菜过来。结果大厨大部分时间都在干等——这就是所谓的「冯·诺依曼瓶颈」。
在回测系统里，这个问题被放大了。你想想看，回测要处理海量的历史数据：OHLCV、订单簿、交易记录……这些数据都存在内存里。CPU每算一笔交易，就要去内存里取一次数据。一来一回，时间全耗在路上了。
现代CPU缓存层次结构：L1、L2、L3
为了解决这个矛盾，硬件工程师想了个办法：在CPU和内存之间加几层「小缓存」。这就是我们常说的L1、L2、L3缓存。
我画了一张图，帮你理解这个层次结构：
这张图你看懂了吗？越靠近CPU的缓存，速度越快，但容量越小。L1缓存只有几十KB，但延迟只有1纳秒左右。L3缓存有十几MB，但延迟已经到15纳秒了。至于主内存？100纳秒起步。
你可能会问：这跟回测系统有什么关系？关系大了。
数据局部性原理：回测系统的命门
数据局部性分两种：时间局部性和空间局部性。
- 时间局部性：刚用过的数据，很可能马上再用。比如循环里的计数器。
- 空间局部性：刚用过的数据附近的数据，很可能马上要用。比如数组里相邻的元素。
回测系统里，我们处理的数据结构决定了局部性的好坏。我举个例子：
// 不好的内存布局：结构体数组（AoS）
struct Bar {
double open;
double high;
double low;
double close;
double volume;
};
Bar bars[1000000];
// 遍历时，每次只用到close，但整个结构体都被加载到缓存
for (int i = 0; i < 1000000; i++) {
process(bars[i].close);
}这段代码有什么问题？你想想看，每次循环只用到close这一个字段，但CPU从内存里取数据时，会把整个Bar结构体（40字节）都加载到缓存行里。缓存行一般64字节，也就是说，一次加载只用了8字节的有效数据，其余32字节都是浪费的。
我曾经在一个回测项目里，把数据结构从AoS改成SoA（数组结构体），回测速度直接提升了3倍。当时团队里的人都惊呆了——代码逻辑完全没变，只是重新排了一下数据。
缓存未命中：性能杀手
当CPU需要的数据不在缓存里，就会发生缓存未命中（Cache Miss）。这时候CPU只能干等着，从主内存里把数据搬过来。一次未命中，浪费几十纳秒。
在回测系统里，缓存未命中有多严重？我算过一笔账：
| 场景 | 每次访问耗时 | 100万次访问总耗时 |
|---|---|---|
| L1缓存命中 | ~1ns | ~1ms |
| L2缓存命中 | ~4ns | ~4ms |
| L3缓存命中 | ~15ns | ~15ms |
| 主内存访问（未命中） | ~100ns | ~100ms |
你看，同样是100万次数据访问，缓存命中率和未命中之间，性能差了100倍。回测系统动辄处理几千万甚至上亿条数据，这个差距就是几秒和几分钟的区别。
回测系统的数据访问模式
回测系统的数据访问有它自己的特点：
- 顺序扫描为主：大部分时候是按时间顺序遍历K线数据
- 随机访问为辅：偶尔需要跳转到特定时间点
- 频繁访问少量字段：比如只用到close和volume，很少用到open和high
- 多标的并行处理：同时处理多个股票或合约的数据
这些特点决定了，优化内存布局时，要优先保证顺序扫描的效率。说白了，就是让数据在内存里排得整整齐齐，CPU读起来一气呵成。
我个人的习惯是，在设计回测系统的数据结构之前，先画一张数据访问的热力图。看看哪些字段被频繁访问，哪些字段很少用到。然后把高频字段放在一起，低频字段另起炉灶。这样缓存利用率最高。
嗯，这一章先讲到这里。记住一句话：回测系统的性能瓶颈，往往不在算法复杂度，而在内存访问模式。把数据布局搞好了，性能提升立竿见影。
公众号:蓝海资料掘金营，微信deep3321