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而过时--编译后的程序运行在line

• Aligning

• 上--它是缓存级别缓存行大小之一，如果有多个缓存级缓存线，超过一个缓存级别缓存行可能仍然会给其他级别缓存的结构大小提供有用的共享，不会造成超过两倍的开销。如果缓存行大小远大于结构大小，则对齐缓存行大小可能会导致更多开销。

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

Answer 1

以std::deque<T>为例。它通常使用给定大小的块来实现。但是你每块有多少个T呢？一个合理的答案是std::hardware_constructive_interference_size/sizeof(T)，如果sizeof(T)很小的话。

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