std::hardware_constructive_interference_size 有用吗？

Posted 2023-02-22

【中文标题】std::hardware_constructive_interference_size 有用吗？

【英文标题】：Is std::hardware_constructive_interference_size ever useful?

【发布时间】：2020-05-05 10:16:28

【问题描述】：

该领域的现有问题仍然没有专门提出我的问题：

Understanding std::hardware_destructive_interference_size and std::hardware_constructive_interference_size Correct way to ensure sharing with std::hardware_constructive_interference_size

第二个的答案实际上让我问这个问题。

所以，假设我想进行建设性干预。而且我将几个变量放入适合std::hardware_constructive_interference_size 的单个结构中：

struct together

  int a;
  int b;
;

如果不适合 static_assert，优势似乎太弱，无法禁止编译：

// Not going to do the below:
static_assert(sizeof(together) <= std::hardware_constructive_interference_size);

仍然对齐有助于避免结构跨度：

struct alignas(std::hardware_constructive_interference_size) together

  int a;
  int b;
;

但是，仅在结构大小上对齐也可以达到相同的效果：

struct alignas(std::bit_ceil(2*sizeof(int))) together

  int a;
  int b;
;

如果结构大小大于std::hardware_constructive_interference_size，将其与结构大小对齐可能仍然有帮助，因为：

编译时提示可能会在运行编译程序的更高 CPU 上过时 它是缓存级别缓存线大小之一，如果有多个，超过一个缓存级别缓存线可能仍然会提供其他级别缓存线的有用共享 按结构大小对齐不会产生超过两倍的开销。如果缓存线大小远大于结构大小，则对齐缓存线大小可能会导致更多开销。

那么，std::hardware_constructive_interference_size 还有什么意义吗？

【参考方案1】：

考虑std::deque<T>。它通常使用给定大小的块来实现。但是每个块存储多少个 T？一个合理的答案是std::hardware_constructive_interference_size/sizeof(T)，如果sizeof(T) 很小。

类似地，具有小字符串优化的字符串类可能以std::hardware_constructive_interference_size 的大小为目标。通常，当您可以拥有具有高引用局部性的运行时可变数量的数据时，该大小很有用。