c++ - std::hardware_constructive_interference_size 有用吗？

Question

该领域的现有问题仍然没有具体询问我的问题:

• 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还有什么意义吗？

Answer 1

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

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