为何特定环境变量大小下该函数运行速度大幅变慢？

问题背景 #

知名论文《Producing Wrong Data Without Doing Anything Obviously Wrong!》探讨了内存代码布局对程序性能的影响，重点分析了UNIX环境变量总大小的作用——环境变量会在程序执行前加载到栈中，引发地址偏移。

作者构造了一个对环境大小极度敏感的示例程序：

static int i = 0, j = 0, k = 0;
int main() {
    int g = 0, inc = 1;
    for (; g<65536; g++) {
        i += inc;
        j += inc;
        k += inc;
    }
    return 0;
}

该程序使用-O0编译以避免优化，生成的汇编代码如下：

1119:       55                      push   rbp
111a:       48 89 e5                mov    rbp,rsp
111d:       c7 45 f8 00 00 00 00    mov    DWORD PTR [rbp-0x8],0x0
1124:       c7 45 fc 01 00 00 00    mov    DWORD PTR [rbp-0x4],0x1
112b:       eb 37                   jmp    1164 <main+0x4b>
112d:       8b 15 e1 2e 00 00       mov    edx,DWORD PTR [rip+0x2ee1]        # 4014 <i>
1133:       8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
1136:       01 d0                   add    eax,edx
1138:       89 05 d6 2e 00 00       mov    DWORD PTR [rip+0x2ed6],eax        # 4014 <i>
113e:       8b 15 d4 2e 00 00       mov    edx,DWORD PTR [rip+0x2ed4]        # 4018 <j>
1144:       8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
1147:       01 d0                   add    eax,edx
1149:       89 05 c9 2e 00 00       mov    DWORD PTR [rip+0x2ec9],eax        # 4018 <j>
114f:       8b 15 c7 2e 00 00       mov    edx,DWORD PTR [rip+0x2ec7]        # 401c <k>
1155:       8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
1158:       01 d0                   add    eax,edx
115a:       89 05 bc 2e 00 00       mov    DWORD PTR [rip+0x2ebc],eax        # 401c <k>
1160:       83 45 f8 01             add    DWORD PTR [rbp-0x8],0x1
1164:       81 7d f8 ff ff 00 00    cmp    DWORD PTR [rbp-0x8],0xffff
116b:       7e c0                   jle    112d <main+0x14>
116d:       b8 00 00 00 00          mov    eax,0x0
1172:       5d                      pop    rbp
1173:       c3                      ret

通过hook __libc_start_main在main执行前设置性能计数器，已成功复现特定环境大小下CPU周期增加约44%的现象（已禁用ASLR和CPU频率缩放保证可复现性）。此时程序变量地址为：

&i       = 0x555555558014
&j       = 0x555555558018
&k       = 0x55555555801c
&g       = 0x7fffffffe018
&inc     = 0x7fffffffe01c

通过Linux perf API发现，该特定栈偏移导致L1数据缓存缺失率略有上升。测试所用Haswell CPU的L1数据缓存为32K、8路组相联，缓存行大小64B，地址最低6位之上的6位为缓存组索引。地址分析显示栈变量与全局静态变量映射到同一缓存组：

&i       = 0x555555558014 --> page offset = 0x014, index = 0x00, offset = 0x14
&j       = 0x555555558018 --> page offset = 0x018, index = 0x00, offset = 0x18
&k       = 0x55555555801c --> page offset = 0x01C, index = 0x00, offset = 0x1C
&g       = 0x7fffffffe018 --> page offset = 0x018, index = 0x00, offset = 0x18
&inc     = 0x7fffffffe01c --> page offset = 0x01C, index = 0x00, offset = 0x1C

即使将栈指针偏移16字节，栈变量仍处于同一缓存行，但此时性能下降可忽略不计。疑问：该异常现象的原因是什么？是否并非L1缓存缺失率导致的性能下降？

分析与结论 #

这个性能异常的核心原因不是单纯的L1缓存缺失率上升，而是缓存组冲突引发的伪共享+写回策略导致的额外缓存行驱逐与同步开销，具体拆解如下：

1. 缓存组冲突与伪共享的叠加 #

Haswell的L1d是8路组相联，当全局变量j/k与栈变量g/inc映射到同一缓存组（索引0x00）时，它们会竞争同一组内的缓存槽。虽然这些变量分属不同物理页面，但缓存组索引仅由地址中间位决定，因此会被分配到同一组。

更关键的是：

• j（0x8018）和g（0xe018）的缓存行内偏移完全相同（0x18），k（0x801c）和inc（0xe01c）的偏移也相同（0x1c）。
• 每次循环中，程序会先读全局变量j/k、写回更新后的值，同时读写栈变量g/inc。由于它们共享同一缓存组，CPU对其中一个变量执行写操作时，缓存行的MESI状态会被标记为Modified；后续访问同一组内另一变量时，会触发缓存行无效化与重新加载——这就是伪共享带来的额外开销。

2. 写回策略放大的开销 #

Haswell的L1d采用写回（Write-Back）策略，缓存行被驱逐时需要写回内存。由于全局变量和栈变量的访问频率极高（循环65536次），同一缓存组内的缓存槽会被频繁替换：

• 写全局变量时，缓存行被标记为Modified；访问栈变量时，该缓存行被驱逐并写回内存；下一次访问全局变量时又需要重新从内存加载，形成恶性循环。
• 这种驱逐-加载的循环带来的周期开销远大于单纯的缓存缺失，这也是为什么L1缺失率仅略有上升，但整体周期增加了44%——每次缺失都伴随着额外的写回操作，而普通缓存缺失仅需加载，无写回成本。

3. 栈偏移16字节后性能恢复的原因 #

当栈指针偏移16字节后，栈变量g和inc的地址变为0x7fffffffe008和0x7fffffffe00c，对应的缓存行偏移变为0x08和0x0c，与全局变量的偏移不再重叠。此时它们虽仍在同一缓存组，但缓存行内偏移不同，CPU可以在同一组的不同缓存槽中保留这些缓存行（8路组相联有足够槽位），不会触发频繁的驱逐与写回，因此性能下降可忽略。

总结：这个性能异常是缓存组冲突+伪共享+写回策略共同作用的结果，单纯的L1缓存缺失率上升只是表象，真正的元凶是频繁的缓存行驱逐与写回带来的额外周期开销。

内容的提问来源于stack exchange，提问作者ConfusedProgrammer