performance - 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缓存有关，我无法解释为什么这种情况如此突然发生。

为了提供更多见解，如果我以基准大小4000和5000运行性能

| 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;
}

第二个示例将读取一个数组，并写入另一个数组。
并且此代码针对不同的大小产生以下perf输出：

| 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

执行摘要：
对于相同的基本工作负载，不同的缓存级别可以维持不同的峰值带宽，因此拥有不同大小的数据集会极大地影响性能。

更长的解释：
this article举例来说，考虑到Haswell并不奇怪。能够



每个周期承受2个负载和1个存储



但这只是说要申请L1。如果继续阅读，您会发现L2



可以在每个周期为数据或指令高速缓存提供完整的64B行



由于每次迭代需要一个负载和一个存储，因此将数据集驻留在L1中将使您可以享受L1带宽并可能达到每次迭代的吞吐量，同时将数据集溢出到L2中迫使您等待更长的时间。这取决于您的系统中有多大的double，但是由于它通常是8字节，因此4000 * 2数组* 8字节= 64k，这超出了当前大多数系统的L1大小。但是，Peter Cords在评论中建议原始代码可能已经优化了零数据数组（我不相信，但这是有可能的）

现在，一旦您开始进入下一个缓存级别，就会发生两件事：


L1写回：请注意，本文没有提到写回，这是您必须在带宽方面付出的额外代价（从perf输出中可以看到，尽管看起来有些陡峭）。将数据保留在L1中意味着您不必进行任何驱逐，而在L2中保留一些数据意味着从L2读取的每一行都必须从L1中抛出一条现有的行-其中一半被修改。您的代码，并要求显式写回。这些事务必须首先读取每次迭代中使用的两个数据元素的值-请记住，由于该行的一部分尚未使用并且需要合并，因此存储也必须首先读取旧数据。
缓存替换策略-请注意，由于将缓存设置为关联的，并且很有可能使用LRU方案，并且由于您要依次遍历阵列，因此缓存的使用方式可能会填充第一种关联方式，然后继续使用第二种方式，依此类推-在最后填充时，如果L2中仍需要数据（在较大数据集的情况下），则您可能会从第一种方法中逐出所有行，因为它们是最近最少的，即使那也意味着它们就是您接下来要使用的。这是LRU的缺点，因为它的数据集大于缓存。


这解释了为什么由于这种访问模式，一旦您超出缓存大小至少一个单向大小（L1缓存的1/8），性能就会如此突然下降。

关于性能结果的最后一条评论-您曾预计，对于5000个元素的情况，L1命中率将下降到一个不错的第0轮，我相信确实如此。但是，硬件预取可以使您看起来仍然像在L1中一样，因为它在实际数据读取之前运行。您仍然必须等待这些预取才能带来数据，更重要的是，由于您正在测量带宽，它们仍然占用与实际加载/存储相同的带宽，但是perf并没有考虑它们，这使您相信你一直都有L1命中率至少这是我最好的猜测-您可以通过禁用预取并再次进行测量来进行检查（我似乎经常提供该建议，很抱歉给您带来麻烦）。



编辑1（跟随你的）

关于消除数组的绝妙解决方案，它解决了两倍大小的奥秘-实际上是64位，因此一个4000个元素的数组或2个每个2000个元素的数组（在修复之后）都可以容纳L1 。现在，溢出发生在3000个元素处。 L1的命中率现在很低，因为L1无法发出足够的预取来在您的2个不同流之前运行。

关于每个加载将为2次迭代带来64字节行的期望-我看到了一些非常有趣的事情-如果将存储单元发出的加载数量相加（L1命中+ L1未命中），您将看到2000元素的情况几乎是1000元素的2倍，但3000和4000的情况分别不是3x和4x，而是一半。具体来说，每个数组3000个元素比2000个元素具有更少的访问权限！
这使我怀疑存储单元是否能够将每2个负载合并到单个存储访问中，但仅在进入L2及更高版本时才可以。考虑到这一点，当您已经有一条待处理的L2线路时，没有理由发出另一次访问来查找L2的理由，这是减轻该级别较低带宽的一种可行方法。
我猜测由于某种原因，第二个负载甚至没有算作L1查找，并且对您希望看到的点击率没有帮助（您可以检查指示有多少个负载正在传递执行的计数器-这可能应该是真的）。不过，这只是预感，我不确定如何定义计数器，但是它确实符合我们看到的访问次数。