Haswell内存访问

Question

我正在尝试使用AVX -AVX2指令集来查看连续阵列上的流媒体性能.所以我有下面的例子,我做基本的内存读取和存储.

#include <iostream>
#include <string.h>
#include <immintrin.h>
#include <chrono>
const uint64_t BENCHMARK_SIZE = 5000;

typedef struct alignas(32) data_t {
  double a[BENCHMARK_SIZE];
  double c[BENCHMARK_SIZE];
  alignas(32) double b[BENCHMARK_SIZE];
}
data;

int main() {
  data myData;
  memset(&myData, 0, sizeof(data_t));

  auto start = std::chrono::high_resolution_clock::now();

  for (auto i = 0; i < std::micro::den; i++) {
    for (uint64_t i = 0; i < BENCHMARK_SIZE; i += 1) {
      myData.b[i] = myData.a[i] + 1;
    }
  }
  auto end = std::chrono::high_resolution_clock::now();
  std::cout << (end - start).count() / std::micro::den << " " << myData.b[1]
            << std::endl;
}

在用g ++编译之后 - 4.9 -ggdb -march = core-avx2 -std = c ++ 11 struct_of_arrays.cpp -O3 -o struct_of_arrays

对于基准大小4000,我看到每个周期性能和时序都非常好的指令.但是,一旦我将基准大小增加到5000,我看到每个周期的指令显着下降并且还有延迟跳跃.现在我的问题是,虽然我可以看到性能下降似乎与L1缓存有关,但我无法解释为什么这种情况突然发生.

为了提供更多见解,如果我使用Benchmark size 4000和5000运行perf

| Event                               | Size=4000 | Size=5000 |
|-------------------------------------+-----------+-----------|
| Time                                |    245 ns |    950 ns |
| L1 load hit                         |    525881 |    527210 |
| L1 Load miss                        |     16689 |     21331 |
| L1D writebacks that access L2 cache |   1172328 | 623710387 |
| L1D Data line replacements          |   1423213 | 624753092 |

所以我的问题是,为什么会发生这种影响,考虑到haswell应该能够提供2*32字节的读取,并且每个周期存储32个字节？

编辑1

我意识到这个代码gcc巧妙地消除了对myData.a的访问,因为它被设置为0.为了避免这种情况,我做了另一个略有不同的基准测试,其中a是明确设置的.

#include <iostream>
#include <string.h>
#include <immintrin.h>
#include <chrono>
const uint64_t BENCHMARK_SIZE = 4000;

typedef struct alignas(64) data_t {
  double a[BENCHMARK_SIZE];
  alignas(32) double c[BENCHMARK_SIZE];

  alignas(32) double b[BENCHMARK_SIZE];

}
data;

int main() {
  data myData;
  memset(&myData, 0, sizeof(data_t));
  std::cout << sizeof(data) << std::endl;
  std::cout << sizeof(myData.a) << " cache lines " << sizeof(myData.a) / 64
            << std::endl;
  for (uint64_t i = 0; i < BENCHMARK_SIZE; i += 1) {
    myData.b[i] = 0;
    myData.a[i] = 1;
    myData.c[i] = 2;
  }

  auto start = std::chrono::high_resolution_clock::now();
  for (auto i = 0; i < std::micro::den; i++) {
    for (uint64_t i = 0; i < BENCHMARK_SIZE; i += 1) {
      myData.b[i] = myData.a[i] + 1;  
    }
  }
  auto end = std::chrono::high_resolution_clock::now();
  std::cout << (end - start).count() / std::micro::den << " " << myData.b[1]
            << std::endl;
}

第二个例子将读取一个数组并写入其他数组.这个产生不同尺寸的跟随性能输出:

| Event          | Size=1000   | Size=2000   | Size=3000   | Size=4000     |
|----------------+-------------+-------------+-------------+---------------|
| Time           | 86  ns      | 166 ns      | 734 ns      | 931    ns     |
| L1 load hit    | 252,807,410 | 494,765,803 | 9,335,692   | 9,878,121     |
| L1 load miss   | 24,931      | 585,891     | 370,834,983 | 495,678,895   |
| L2 load hit    | 16,274      | 361,196     | 371,128,643 | 495,554,002   |
| L2 load miss   | 9,589       | 11,586      | 18,240      | 40,147        |
| L1D wb acc. L2 | 9,121       | 771,073     | 374,957,848 | 500,066,160   |
| L1D repl.      | 19,335      | 1,834,100   | 751,189,826 | 1,000,053,544 |

同样的模式在答案中被指出,随着数据集大小数据的增加不再适合L1,L2成为瓶颈.同样有趣的是,预取似乎并没有帮助,L1未命中率也大大增加.虽然,我希望看到至少50%的命中率,考虑到读取L1的每个缓存行将成为第二次访问的命中(每次迭代读取64字节缓存行32字节).然而,一旦数据集溢出到L2,似乎L1命中率下降到2%.考虑到数组与L1高速缓存大小并不真正重叠,这不应该是因为高速缓存冲突.所以这部分对我来说仍然没有意义.

Answer 1

执行摘要:
不同的缓存级别可以为相同的基本工作负载维持不同的峰值带宽,因此使用不同大小的数据集会极大地影响性能.

更长的解释:
考虑到哈斯威尔,根据这篇文章的例子可以,这并不是很令人惊讶

每个周期维持2个负载和1个存储

但这只是说申请L1.如果您继续阅读,请看L2

每个周期都可以为数据或指令缓存提供完整的64B线

由于每次迭代需要一个加载和一个存储,因此将数据集驻留在L1中将允许您享受L1带宽并可能达到每次迭代的吞吐量,同时将数据集溢出到L2将迫使你等待更长时间.这取决于系统中的双倍大小,但由于它最常见的是8字节,4000*2阵列*8字节= 64k,这超过了大多数当前系统的L1大小.然而,Peter Cords在评论中建议原始代码可能已经优化了零数据阵列(我不相信,但它有可能)

现在,一旦开始超出下一个缓存级别,就会发生两件事:

1. L1-writebacks:请注意,文章没有提到回写,这是一个额外的惩罚,你必须支付带宽(从你的性能输出可以看出 - 虽然它看起来有点陡峭).将数据保存在L1中意味着您不必进行任何驱逐,而在L2中有一些数据意味着从L2读取的每一行都必须从L1中抛出一条现有的行 - 其中一半被修改为您的代码并需要显式回写.这些事务必须首先读取每次迭代使用的两个数据元素的值 - 请记住,存储还必须首先读取旧数据,因为部分行未使用且需要合并.

2. 缓存替换策略 - 请注意,由于缓存是关联的,并且很可能使用LRU方案,并且由于您按顺序遍历数组,因此缓存使用模式可能会填充第一种关联方式,然后继续第二种方式,等等 - 当你填写最后一个方式时,如果L2中仍然需要数据(在较大的数据集情况下),你可能会从第一种方式逐出所有行,因为它们是最近的 - 尽管这也意味着他们是你接下来要使用的那些.这是数据集大于缓存的LRU的缺点.

这解释了为什么由于这种访问模式导致性能下降的原因,一旦超过缓存大小至少一个方向的大小(L1缓存的1/8).

关于性能结果的最后一个评论 - 你已经预料到,对于5000个元素的情况,L1命中率会下降到一个很好的回合零,我相信它确实如此.但是,HW预取可能会使您看起来仍然在L1中击中它,因为它在实际数据读取之前运行.您仍然需要等待这些预取来传输数据,更重要的是,因为您正在测量带宽 - 它们仍然占用与实际负载/存储相同的带宽,但它们不会被perf计算,导致您相信你一直有L1命中.这至少是我最好的猜测 - 你可以通过禁用预取和再次测量来检查(我似乎经常给出这个建议,抱歉是这样的拖累).

编辑1(跟随你的)

很好地了解了被淘汰的阵列,它解决了双倍大小的神秘感 - 它确实是64位,所以要么是4000个元素的一个数组,要么是每个2000个元素的2个数组(在你的修复之后),你可以在L1中使用.现在溢出发生在3000个元素.L1命中率现在很低,因为L1无法发出足够的预取以在2个不同的流之前运行.

至于期望每个负载将为2次迭代带来64字节线 - 我看到一些非常有趣的东西 - 如果你总结从内存单元发出的负载数量(L1命中+ L1未命中),你会看到2000个元素的情况几乎是1000个元素的2倍,但3000和4000个案例分别不是3x和4x,而是一半.具体来说,每个阵列有3000个元素,访问量比2000个元素少!
这让我怀疑内存单元能够将每两个加载合并到一个内存访问中,但只有在进入L2及更高版本时才能合并.当你想到它时,这是有道理的,没有理由发出另一个查询L2的访问权限,如果你已经有一个待处理的那条线路,并且这是一种可行的方法来缓解该级别的较低带宽.我猜测由于某种原因,第二次加载甚至没有计算,然后作为L1查找,并没有帮助你想看到的命中率(你可以检查指示有多少负载传递执行的计数器 - 应该可能是真的).这只是一个预感,但我不确定计数器是如何定义的,但它确实符合我们看到的访问次数.