英特尔X86与AMD X86 CPU上的非对齐访问性能

Question

我已经实现了一个简单的线性探测哈希映射，并具有一系列结构存储器布局。结构保留键，值和标志，指示条目是否有效。默认情况下，该结构被编译器填充，因为密钥和值是64位整数，但是该条目仅占用8个布尔。因此，我还尝试以非对齐的访问为代价打包结构。我希望由于更高的内存密度，从包装/未对准版本中获得更好的性能（我们不会在传输填充字节上浪费带宽）。

当在Intel Xeon Gold 5220S CPU上基准该哈希地图（单线线程，GCC 11.2，-O3和-March =本机）时，我看到填充版本与未对准版本之间没有性能差异。但是，在AMD EPYC 7742 CPU（相同的设置）上，我发现了未对准和填充之间的性能差异。这是一个图形，描述了X轴上不同的成功查询率（0,25,50,75,100）的结果25％和50％的结果： ，您可以看到，如您所见在英特尔上，灰色和蓝色（圆形和方形）线几乎重叠，结构堆积的好处是边缘的。但是，在AMD上，代表未对准/包装结构的线始终较高，即，我们有更多的吞吐量。

为了调查这一点，我尝试构建一个较小的微型计算标准。在此微博结中，我们执行类似的基准测试，但是没有哈希地图找到逻辑（即，我们只是在阵列中选择随机索引并在那里稍微推进一点）。请在此处找到基准：

#include <atomic>
#include <chrono>
#include <cstdint>
#include <iostream>
#include <random>
#include <vector>

void ClobberMemory() { std::atomic_signal_fence(std::memory_order_acq_rel); }

template <typename T>
void doNotOptimize(T const& val) {
  asm volatile("" : : "r,m"(val) : "memory");
}

struct PaddedStruct {
  uint64_t key;
  uint64_t value;
  bool is_valid;

  PaddedStruct() { reset(); }

  void reset() {
    key = uint64_t{};
    value = uint64_t{};
    is_valid = 0;
  }
};

struct PackedStruct {
  uint64_t key;
  uint64_t value;
  uint8_t is_valid;

  PackedStruct() { reset(); }

  void reset() {
    key = uint64_t{};
    value = uint64_t{};
    is_valid = 0;
  }
} __attribute__((__packed__));

int main() {
  const uint64_t size = 134217728;
  uint16_t repetitions = 0;
  uint16_t advancement = 0;

  std::cin >> repetitions;
  std::cout << "Got " << repetitions << std::endl;
  std::cin >> advancement;
  std::cout << "Got " << advancement << std::endl;
  std::cout << "Initializing." << std::endl;

  std::vector<PaddedStruct> padded(size);
  std::vector<PackedStruct> unaligned(size);
  std::vector<uint64_t> queries(size);

  // Initialize the structs with random values + prefault
  std::random_device rd;
  std::mt19937 gen{rd()};
  std::uniform_int_distribution<uint64_t> dist{0, 0xDEADBEEF};
  std::uniform_int_distribution<uint64_t> dist2{0, size - advancement - 1};

  for (uint64_t i = 0; i < padded.size(); ++i) {
    padded[i].key = dist(gen);
    padded[i].value = dist(gen);
    padded[i].is_valid = 1;
  }

  for (uint64_t i = 0; i < unaligned.size(); ++i) {
    unaligned[i].key = padded[i].key;
    unaligned[i].value = padded[i].value;
    unaligned[i].is_valid = 1;
  }

  for (uint64_t i = 0; i < unaligned.size(); ++i) {
    queries[i] = dist2(gen);
  }

  std::cout << "Running benchmark." << std::endl;

  ClobberMemory();
  auto start_padded = std::chrono::high_resolution_clock::now();
  PaddedStruct* padded_ptr = nullptr;
  uint64_t sum = 0;
  for (uint16_t j = 0; j < repetitions; j++) {
    for (const uint64_t& query : queries) {
      for (uint16_t i = 0; i < advancement; i++) {
        padded_ptr = &padded[query + i];
        if (padded_ptr->is_valid) [[likely]] {
          sum += padded_ptr->value;
        }
      }
      doNotOptimize(sum);
    }
  }

  ClobberMemory();
  auto end_padded = std::chrono::high_resolution_clock::now();
  uint64_t padded_runtime = static_cast<uint64_t>(std::chrono::duration_cast<std::chrono::milliseconds>(end_padded - start_padded).count());
  std::cout << "Padded Runtime (ms): " << padded_runtime << " (sum = " << sum << ")" << std::endl;  // print sum to avoid that it gets optimized out

  ClobberMemory();
  auto start_unaligned = std::chrono::high_resolution_clock::now();
  uint64_t sum2 = 0;
  PackedStruct* packed_ptr = nullptr;
  for (uint16_t j = 0; j < repetitions; j++) {
    for (const uint64_t& query : queries) {
      for (uint16_t i = 0; i < advancement; i++) {
        packed_ptr = &unaligned[query + i];
        if (packed_ptr->is_valid) [[likely]] {
          sum2 += packed_ptr->value;
        }
      }
      doNotOptimize(sum2);
    }
  }
  ClobberMemory();
  auto end_unaligned = std::chrono::high_resolution_clock::now();
  uint64_t unaligned_runtime = static_cast<uint64_t>(std::chrono::duration_cast<std::chrono::milliseconds>(end_unaligned - start_unaligned).count());
  std::cout << "Unaligned Runtime (ms): " << unaligned_runtime << " (sum = " << sum2 << ")" << std::endl;
}

运行基准测试时，我选择重复= 3，而Advancement = 5，即，在编译和运行它之后，您必须输入3（并按Newline），然后输入5并按Enter/Newline。我将源代码更新为（a）避免编译器的循环展开，因为重复/进步是硬编码，并且（b）将指针切换到该向量，因为它更类似于哈希地图的作用。

在英特尔CPU上，我得到：

填充运行时（MS）：13204 非对齐的运行时（MS）：12185

在AMD CPU上，我得到：

填充运行时（MS）：28432 非对齐的运行时（MS）：22926

因此，在此微型计算标准中，英特尔仍然从未对齐的访问中受益一点，对于AMD CPU而言，绝对和相对改进都更高。我无法解释这一点。通常，从我从相关的信息中学到的内容，只要它留在单个缓存线（1）中，单个成员的不一致的访问就与对齐访问一样昂贵。同样在（1）中，给出了（2）的引用，该引用声称​​缓存提取宽度可能与缓存线大小不同。但是，除了Linus Torvalds邮件外，我找不到其他任何其他文档的加速器提取宽度的文档，尤其是对于我的混凝土两个CPU而言，我无法以某种方式弄清楚这是否与此有关。

有人知道为什么AMD CPU从结构包装中受益更多吗？如果这是关于减少内存带宽消耗，我应该能够看到对这两个CPU的影响。而且，如果带宽使用情况相似，我不明白可能导致差异的原因。

（1）相关的so线程：准确地在x86_64上准确基准非对齐访问速度？

（2）

Answer 1

英特尔Xeon Gold 5220s（以及所有其他Skylake/Cascadelake Xeon处理器）上的L1数据缓存提取宽度最高为64个自然平整的Bytes每个周期。

对于不会越过Cacheline边界的任何大小和对齐组合的组合，核心可以执行每个周期的两个负载。我尚未测试SKX/CLX处理器上的所有组合，但是在Haswell/Broadwell上，每当载荷越过Cacheline边界时，吞吐量都会减少到每个周期的一个负载，我认为SKX/CLX相似。可以将其视为必要的功能，而不是“惩罚” - 拆卸负载可能需要使用两个端口来加载一对相邻行，然后将所请求的线的部分组合到目标寄存器的有效负载中。

交叉页面边界的负载具有较大的性能惩罚，但是要测量它，您必须非常谨慎地理解和控制这两个页面的页面表条目的位置：DTLB，STLB，在卡希斯中或主内存中。我的回忆是，最常见的情况非常快 - 部分是因为“下一页预摘要”非常擅长将下一页的PTE输入预加载到TLB中，然后再在一系列负载到第一个载荷结束之前页。唯一令人痛苦的情况是跨越页面边界的商店，并且英特尔编译器非常努力地避免这种情况。

我尚未详细查看示例代码，但是如果我执行此分析，我会谨慎地固定处理器频率，测量指令和周期计数，并计算每个更新的指令和周期的平均数量。 （我通常将核心频率设置为标称（TSC）频率，以使数字更易于使用。）对于自然对准的情况，应该很容易查看组件代码并估算周期计数应是。如果测量值类似于该情况的观察结果，则可以参考对基线的更可靠的理解，从而开始查看未对齐的访问的开销。

硬件性能计数器也对这种情况也很有价值，尤其是DTLB_LOAD_MISSES事件和L1D.Beplacement事件。只需几个高延迟TLB Miss或L1D Miss Events就可以偏向平均值。

Answer 2

使用24字节数据结构时，高速线访问的数量可能与使用17字节数据结构时相同。

请参阅此博客文章：