您所看到的基本上是存储缓冲区与存储到加载转发相结合的效果，允许每个核心大部分独立工作，尽管共享一个缓存行。正如我们将在下面看到的，这确实是一个奇怪的情况，更多的争用是不好的，在某种程度上，更多的争用突然让事情变得非常快！
现在，按照传统的争用观点，您的代码似乎是高争用的，因此比理想的要慢得多。然而，发生的情况是，一旦每个内核在其写入缓冲区中获得单个挂起的写入，所有以后的读取都可以从写入缓冲区（存储转发）中得到满足，并且即使在核心已失去缓存行的所有权。这将大部分工作变成了完全本地化的操作。缓存线仍在内核之间来回跳动，但它与内核执行路径分离，只需要不时地实际提交存储1。
该std::atomic版本根本无法使用这种魔法，因为它必须使用locked 操作来保持原子性并破坏存储缓冲区，因此您会看到争用的全部成本和长延迟原子操作的成本2。
让我们试着收集一些证据来证明这就是正在发生的事情。下面的所有讨论都涉及用于强制读取和写入atomic的基准的非版本。volatilebuffer
让我们首先检查程序集，以确保它符合我们的预期：
0000000000400c00 <fn(unsigned char volatile*)>:
400c00: ba 00 65 cd 1d mov edx,0x1dcd6500
400c05: 0f 1f 00 nop DWORD PTR [rax]
400c08: 0f b6 07 movzx eax,BYTE PTR [rdi]
400c0b: 83 c0 01 add eax,0x1
400c0e: 83 ea 01 sub edx,0x1
400c11: 88 07 mov BYTE PTR [rdi],al
400c13: 75 f3 jne 400c08 <fn(unsigned char volatile*)+0x8>
400c15: f3 c3 repz ret
这很简单：一个五指令循环，一个字节加载，一个加载字节的增量，一个字节存储，最后是循环增量和条件跳转回顶部。在这里，gcc 通过分解subandjne来抑制宏融合而错过了优化，但总的来说它没问题，并且存储转发延迟无论如何都会限制循环。
接下来，我们来看看 L1D 未命中的数量。每次核心需要写入被窃取的行时，它都会遭受 L1D 未命中，我们可以用 来衡量perf。一、单线程（N=1）情况：
$ perf stat -e task-clock,cycles,instructions,L1-dcache-loads,L1-dcache-load-misses ./cache-line-increment
Performance counter stats for './cache-line-increment':
1070.188749 task-clock (msec) # 0.998 CPUs utilized
2,775,874,257 cycles # 2.594 GHz
2,504,256,018 instructions # 0.90 insn per cycle
501,139,187 L1-dcache-loads # 468.272 M/sec
69,351 L1-dcache-load-misses # 0.01% of all L1-dcache hits
1.072119673 seconds time elapsed
这与我们预期的差不多：基本上为零的 L1D 未命中（占总数的 0.01%，可能主要来自循环外的中断和其他代码），以及刚刚超过 500,000,000 次命中（几乎完全匹配循环迭代的次数）。另请注意，我们可以轻松计算每次迭代的周期：大约 5.5 5。这主要反映了存储到加载转发的成本，加上一个周期的增量，这是一个携带的依赖链，因为相同的位置被重复更新（并且volatile意味着它不能被提升到寄存器中）。
我们来看看N=4案例：
$ perf stat -e task-clock,cycles,instructions,L1-dcache-loads,L1-dcache-load-misses ./cache-line-increment
Performance counter stats for './cache-line-increment':
5920.758885 task-clock (msec) # 3.773 CPUs utilized
15,356,014,570 cycles # 2.594 GHz
10,012,249,418 instructions # 0.65 insn per cycle
2,003,487,964 L1-dcache-loads # 338.384 M/sec
61,450,818 L1-dcache-load-misses # 3.07% of all L1-dcache hits
1.569040529 seconds time elapsed
正如预期的那样，L1 负载从 5 亿跃升至 20 亿，因为有 4 个线程每个执行 5 亿负载。L1D未命中的数量也增加了约 1,000 倍，达到约 6,000 万。尽管如此，与 20 亿负载（以及 20 亿商店 - 未显示，但我们知道它们就在那里）相比，这个数字仍然不算多。每次未命中大约需要 33 次加载和大约 33 次存储。这也意味着每次未命中之间有 250 个周期。
这并不真正适合高速缓存线在内核之间不规则地弹跳的模型，一旦一个内核获得该线，另一个内核就需要它。我们知道，共享 L2 的内核之间的线路可能会在 20-50 个周期内反弹，因此每 250 个周期发生一次未命中的比率似乎很低。
两个假设
对于上述行为，我想到了几个想法：
也许这个芯片中使用的 MESI 协议变体是“智能”的，并且可以识别出多个内核之间的一条线路是热的，但每次内核获得锁定时只完成少量工作并且线路花费更多时间在 L1 之间移动和 L2 比实际满足某些核心的负载和存储。有鉴于此，一致性协议中的一些智能组件决定为每条线路强制执行某种最小“拥有时间”：在一个核心获得线路后，即使另一个核心要求它也会保持 N 个周期（其他核心只需要等待）。
这将有助于平衡缓存线乒乓的开销与实际工作，代价是“公平”和其他内核的响应能力，有点像不公平和公平锁之间的权衡，并抵消此处描述的效果，一致性协议越快、越公平，一些（通常是合成的）循环可能执行得越差。
现在我从来没有听说过这样的事情（之前的链接显示，至少在桑迪桥时代，事情正朝着相反的方向发展），但这当然是可能的！
所描述的存储缓冲区效应实际上正在发生，因此大多数操作几乎可以在本地完成。
一些测试
让我们尝试通过一些修改来区分两种情况。
读取和写入不同的字节
显而易见的方法是更改fn()工作功能，以便线程仍然在同一缓存行上竞争，但存储转发无法启动。
我们只是从 location 读取x然后写入 locationx + 1怎么样？我们将给每个线程两个连续的位置（即thr[i] = std::thread(&fn, &buffer[i*2])），因此每个线程都在两个私有字节上运行。修改后的fn()样子：
for (int i=0; i<500000000; i++)
unsigned char temp = p[0];
p[1] = temp + 1;
}
核心循环与之前的非常相似：
400d78: 0f b6 07 movzx eax,BYTE PTR [rdi]
400d7b: 83 c0 01 add eax,0x1
400d7e: 83 ea 01 sub edx,0x1
400d81: 88 47 01 mov BYTE PTR [rdi+0x1],al
400d84: 75 f2 jne 400d78
唯一改变的是我们写入[rdi+0x1]而不是[rdi].
load->add->store->load...现在正如我上面提到的，由于循环携带的依赖性，即使在最好的单线程情况下，原始（相同位置）循环实际上运行相当缓慢，每次迭代大约 5.5 个周期。这个新代码打破了这个链条！负载不再依赖于存储，因此我们几乎可以并行执行所有操作，并且我希望这个循环每次迭代运行大约 1.25 个周期（5 条指令 / CPU 宽度为 4）。
这是单线程案例：
$ perf stat -e task-clock,cycles,instructions,L1-dcache-loads,L1-dcache-load-misses ./cache-line-increment
Performance counter stats for './cache-line-increment':
318.722631 task-clock (msec) # 0.989 CPUs utilized
826,349,333 cycles # 2.593 GHz
2,503,706,989 instructions # 3.03 insn per cycle
500,973,018 L1-dcache-loads # 1571.815 M/sec
63,507 L1-dcache-load-misses # 0.01% of all L1-dcache hits
0.322146774 seconds time elapsed
因此，每次迭代3大约需要 1.65 个周期，比增加相同位置快大约三倍。
4个线程怎么样？
$ perf stat -e task-clock,cycles,instructions,L1-dcache-loads,L1-dcache-load-misses ./cache-line-increment
Performance counter stats for './cache-line-increment':
22299.699256 task-clock (msec) # 3.469 CPUs utilized
57,834,005,721 cycles # 2.593 GHz
10,038,366,836 instructions # 0.17 insn per cycle
2,011,160,602 L1-dcache-loads # 90.188 M/sec
237,664,926 L1-dcache-load-misses # 11.82% of all L1-dcache hits
6.428730614 seconds time elapsed
所以它比相同位置的情况慢了大约 4 倍。现在，它不仅比单线程情况慢一点，而且慢了大约20 倍。这就是您一直在寻找的竞争！现在 L1D 未命中的数量也增加了 4 倍，这很好地解释了性能下降，并且与当存储到加载转发无法隐藏争用时，未命中将增加很多的想法一致。
增加商店之间的距离
另一种方法是增加存储和后续加载之间的时间/指令距离。我们可以通过增加方法SPAN中的连续位置来做到这一点fn()，而不是总是相同的位置。例如，如果SPAN是 4，则连续增加 4 个位置，例如：
for (long i=0; i<500000000 / 4; i++) {
p[0]++;
p[1]++;
p[2]++;
p[3]++;
}
请注意，我们仍然总共增加了 5 亿个位置，只是将增量分布在 4 个字节中。直觉上，您会期望整体性能会提高，因为您现在SPAN与 length 具有并行依赖关系1/SPAN，因此在上述情况下，您可能会期望性能提高 4 倍，因为 4 条并行链可以以大约 4 倍的总吞吐量继续运行。
这是我们实际得到的 1 线程和 3 线程4的时间（以周期为单位） ，SPAN值从 1 到 20：
最初，您会看到单线程和多线程情况下的性能显着提高；在两种情况下完美并行的情况下，aSPAN从 1 增加到 2 和 3 接近于理论预期。
单线程情况的渐近线比单位置写入快 4.25 倍：此时存储转发延迟不是瓶颈，其他瓶颈已经接管（主要是最大 IPC 和存储端口争用）。
但是，多线程情况非常不同！一旦你达到SPAN大约 7 的 a ，性能迅速变差，稳定在大约 2.5 倍的SPAN=1情况下，与最佳性能相比几乎 10 倍SPAN=5。发生的情况是存储到加载转发停止发生，因为存储和后续加载在时间/周期上相距足够远，以至于存储已退出到 L1，因此加载实际上必须获得线路并参与 MESI。
还绘制了 L1D 未命中，如上所述，它表示内核之间的“缓存行传输”。单线程情况基本为零，与性能无关。然而，多线程案例的性能几乎可以准确跟踪缓存未命中。对于SPAN2 到 6 范围内的值，存储转发仍在工作，未命中的比例相应减少。显然，由于核心循环更快，核心能够在每次高速缓存行传输之间“缓冲”更多存储。
另一种思考方式是，在有争议的情况下，L1D 未命中基本上是每单位时间恒定的（这是有道理的，因为它们基本上与 L1->L2->L1 延迟以及一些一致性协议开销有关），所以在高速缓存行传输之间可以做的工作越多越好。
这是多跨度案例的代码：
void fn(Type *p) {
for (long i=0; i<500000000 / SPAN; i++) {
for (int j = 0; j < SPAN; j++) {
p[j]++;
}
}
}
为从 1 到 20perf的所有值运行的 bash 脚本：SPAN
PERF_ARGS=${1:--x, -r10}
for span in {1..20}; do
g++ -std=c++11 -g -O2 -march=native -DSPAN=$span cache-line-increment.cpp -lpthread -o cache-line-increment
perf stat ${PERF_ARGS} -e cycles,L1-dcache-loads,L1-dcache-load-misses,machine_clears.count,machine_clears.memory_ordering ./cache-line-increment
done
最后，将结果“转置”为适当的 CSV：
FILE=result1.csv; for metric in cycles L1-dcache-loads L1-dcache-load-misses; do { echo $metric; grep $metric $FILE | cut -f1 -d,; } > ${metric}.tmp; done && paste -d, *.tmp
最终测试
您可以进行最后一项测试，以证明每个内核都有效地私下完成了大部分工作：使用线程在同一位置工作的基准版本（不会改变性能特征）检查总和的最终计数器值（您需要int计数器而不是char）。如果一切都是原子的，那么总和将是 20 亿，在非原子的情况下，总数与该值的接近程度是对核心绕过线路的频率的粗略衡量。如果核心几乎完全私下工作，价值将接近 5 亿而不是 20 亿，我想这就是你会发现的（价值相当接近 5 亿）。
通过一些更巧妙的递增，您甚至可以让每个线程跟踪它们递增的值来自上次递增而不是另一个线程递增的频率（例如，通过使用值的几位来存储线程标识符）。通过更聪明的测试，您实际上可以重建缓存线在内核之间移动的方式（是否存在模式，例如，内核 A 是否更愿意将其移交给内核 B？）以及哪些内核对最终值的贡献最大，等等
这一切都留作练习:)。
1最重要的是，如果英特尔有一个合并存储缓冲区，在该缓冲区中，与较早存储完全重叠的较晚存储会杀死较早存储，则每次获取该行时，它只需将一个值提交给 L1（最新存储）。
2你不能在这里真正分开这两种效果，但我们稍后会通过击败存储到加载转发来做到这一点。
3比我预期的要多一点，可能是调度不当导致端口压力。如果gcc只是所有sub和jne融合，它每次迭代运行 1.1 个周期（仍然比我预期的 1.0 差）。我会使用它-march=haswell来代替，-march=native但我不会回去更改所有数字。
4结果也适用于 4 个线程：但我只有 4 个内核，而且我在后台运行 Firefox 之类的东西，所以少用 1 个内核可以使测量的噪音小得多。以周期为单位测量时间也很有帮助。
5在此 CPU 架构上，在存储数据准备好之前负载到达的存储转发似乎在 4 到 5 个周期之间交替，平均为 4.5 个周期。