关于Apple Clang中std::hardware_destructive_interference_size取值合理性的问询

嘿，我来帮你捋一捋这个问题～

首先得说，Apple Clang 17.0.0终于支持std::hardware_destructive_interference_size和std::hardware_constructive_interference_size这两个C++17常量，这本身确实是个值得开心的小进步对吧？

你疑惑为什么它取值64而不是你预期的128，咱们先把这两个常量的核心作用搞明白：

• std::hardware_destructive_interference_size：核心是帮你避开伪共享——也就是两个被不同线程访问的变量，不小心挤在同一个CPU缓存行里，导致缓存频繁失效拖慢性能。这个值的设计目标是：只要两个变量的起始地址间隔大于等于它，就能保证它们不会落在同一个“对性能影响最大的缓存行”里。
• std::hardware_constructive_interference_size：则是反过来，帮你把需要频繁一起访问的数据塞进同一个缓存行，提升访问效率，这个值就是单个缓存行能容纳的最大连续数据参考大小。

那为什么Apple Clang给的是64？这主要和自家M系列芯片的硬件配置挂钩：目前M1、M2、M3这些芯片的L1数据缓存行大小都是64字节，而L1是CPU访问速度最快的缓存层级，伪共享在L1层面的性能影响是最直接的。Apple Clang的实现是对齐了自家硬件的核心缓存配置，所以取了L1的缓存行大小作为这两个常量的值。

你预期128，大概率是混淆了不同缓存层级的大小（比如M系列的L2缓存行是128字节），或者参考了其他平台的实现（比如某些x86_64服务器CPU的L2缓存行是128字节，对应的编译器取值可能是128）。但这里要明确：C++标准并没有强制要求这两个常量必须等于某一级缓存的固定大小，它是实现定义的——也就是编译器厂商会根据自家目标硬件的最优化场景来选合适的值。

所以结论是：你的预期可能来自其他硬件或场景的经验，但Apple Clang的64字节取值并不是“错了”，而是适配了Apple自家芯片的实际缓存配置，是合理的。如果你的特定性能场景确实需要128字节的间隔，也可以自行定义一个常量，再结合实际的性能测试来验证效果～

备注：内容来源于stack exchange，提问作者Jody Hagins