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

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

更长的解释：
考虑到哈斯威尔，根据this article提到的情况，这并不奇怪。可以

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

但是只说申请L1。如果你继续阅读，你会看到L2

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

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

现在，一旦你开始超越下一个缓存级别，就会发生两件事：

L1-writebacks ：请注意，文章没有提到回写，这是您必须在带宽方面支付的额外费用（从您的perf输出可以看出） - 虽然它确实看起来有点陡峭）。将数据保存在L1中意味着您不必进行任何驱逐，而在L2中有一些数据意味着从L2读取的每一行都必须从L1中抛出一条现有线 - 其中一半是由您的代码修改并要求显式回写。这些事务必须首先读取每次迭代使用的两个数据元素的值 - 请记住，存储还必须首先读取旧数据，因为部分行未使用且需要合并。
< / LI>
缓存替换策略 - 请注意，由于缓存是关联的，很可能使用LRU方案，并且由于您按顺序遍历数组，因此缓存使用模式可能会填充第一种关联方式，然后转到第二种方式，依此类推 - 当你填写最后一种方式时，如果L2中需要有静态数据（在较大的数据集情况下），你＆＃39 ; d可能从第一种方式逐出所有线路，因为它们是最近最少使用的线路，尽管这也意味着它们是您接下来要使用的线路。这是数据集大于缓存的LRU的缺点。

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

关于性能结果的最后评论 - 您预计L1命中率将下降到5000元素情况的良好回合零，我相信它确实如此。但是，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查找，并且没有帮助你想要看到的命中率（你可以检查指示有多少载荷通过执行的计数器） - 那应该是真的）。这只是一个预感，但我不确定计数器是如何定义的，但它确实符合我们看到的访问次数。

Answer 2

我也在Haswell上，但是我无法重现相同的结果。您确定使用了正确的性能事件吗？我很好奇，可以进一步调查并亲自分析代码。但是首先，让我们仅通过静态分析代码来确定预期的装载和存储数量，然后将其与我们得到的数字进行比较，看看它们是否有意义。您正在使用gcc 4.9。这是使用-march=core-avx2 -O3为循环嵌套发出的汇编代码：

  4007a8:   48 8d 85 d0 2a fe ff    lea    -0x1d530(%rbp),%rax
  4007af:   90                      nop
  4007b0:   c5 f5 58 00             vaddpd (%rax),%ymm1,%ymm0
  4007b4:   48 83 c0 20             add    $0x20,%rax
  4007b8:   c5 fd 29 80 60 38 01    vmovapd %ymm0,0x13860(%rax)
  4007bf:   00 
  4007c0:   48 39 c2                cmp    %rax,%rdx
  4007c3:   75 eb                   jne    4007b0 <main+0x50>
  4007c5:   83 e9 01                sub    $0x1,%ecx
  4007c8:   75 de                   jne    4007a8 <main+0x48>

每个内循环迭代只有一个对齐的32字节加载uop和一个对齐的32字节存储uop。外环跳闸计数为100万。内循环跳闸计数为BENCHMARK_SIZE / 4（由于矢量化）。因此，对L1的加载请求总数应约为1百万* {BENCHMARK_SIZE / 4，并且存储的总数也应大致相同。例如，如果BENCHMARK_SIZE为4000，则装入和存储请求的数量应分别为10亿。循环分支是非常可预测的，因此我们不必担心非退休的推测性负载和代码提取。

回想一下，Haswell中的L1D具有两个32字节加载端口和一个32字节存储端口。下图显示了我使用perf得到的结果。请注意，在进行这些测量时，同时启用了L1D和L2预取器。禁用超线程以消除可能的干扰，并利用其他4个可编程性能计数器。

可以观察到的第一件事是负载（MEM_UOPS_RETIRED.ALL_LOADS）和存储（MEM_UOPS_RETIRED.ALL_STORES）的数量与我们的静态分析相符。这很酷。但是，第一个关键观察结果是L1D负载命中数（MEM_LOAD_UOPS_RETIRED.L1_HIT）非常接近L1D负载数。这意味着L1D流式预取器能够及时预取大多数myData.a[i]访问。显然，L1D负载丢失（MEM_LOAD_UOPS_RETIRED.L1_MISS）的数量必须非常小。这适用于BENCHMARK_SIZE的所有值。

L1D_PEND_MISS.REQUEST_FB_FULL告诉我们请求加载或存储或软件预取请求未命中L1D但由于没有填充缓冲区而无法从加载/存储缓冲区发出的L1D的周期数。这似乎是一个重大问题。但是，此事件使我们无法确定加载，存储或两者都被阻止。我稍后将讨论另一件事。当BENCHMARK_SIZE等于或小于2000时，此事件计数可以忽略不计，因为在内循环的第一次迭代之后，所有以后的加载和存储都将命中缓存，从而消除了对填充缓冲区的需要。

L2_TRANS.RFO计算访问L2的RFO请求的数量。如果仔细观察该图，您会发现这似乎不到商店总数量的一半。这是有道理的，因为每两个连续的存储单元都位于同一高速缓存行中。因此，如果一个错过了L1D，则另一个会错过并在同一LFB条目中进行写合并，并且还会压缩到对L2的同一RFO请求中。我不知道为什么L2_TRANS.RFO不完全是MEM_UOPS_RETIRED.ALL_STORES的一半（正如我对BENCHMARK_SIZE> 2000的情况所期望的那样）。

根据手册，

L2_RQSTS.ALL_DEMAND_DATA_RD应该用于计算来自L1的需求数据加载的数量以及对L2的L1预取请求的数量。但这很小。我认为它仅计算需求数据加载的数量，或者L1流预取器可以直接与L3通信。无论如何，这对于此分析并不重要。

我们可以从该图得出结论，装入请求不在关键路径上，而存储请求在关键路径上。下一步显然是测量RESOURCE_STALLS.SB，以确定商店真正遭受的苦难。此事件计算由于存储缓冲区已满而导致的完整分配停顿周期的数量。

（图中的{cycles是指未停止的核心周期，基本上是执行时间。）

该图显示，分配器浪费了超过60％的执行时间，以等待存储缓冲区条目变为空闲状态。为什么会这样呢？两个L1D预取器仅跟踪加载请求并以S或E相干状态提取行。如果加载和存储到同一高速缓存行，并且没有其他核心拥有这些行的共享副本，则L1流媒体将以E状态预取这些行，从而有效地使加载和存储受益。但是在我们的示例中，存储位于不同的缓存行中，并且两个L1D预取器均未跟踪这些缓存行。写合并LFB很有帮助，但紧密的循环使L1D控制器不堪重负，并屈服于此，恳求加载/存储缓冲单元停止发出更多的存储请求。尽管仍然可以发出装入请求，因为它们大多命中高速缓存并且在这种情况下不需要LFB。因此，商店将堆积在商店缓冲区中，直到缓冲区变满为止，从而使分配器停顿。 LFB将主要被合并的商店未命中和L1流媒体的请求所竞争。因此，LFB的数量和存储缓冲区条目位于关键路径上。 L1D写端口的数量没有。当存储的阵列大小超过L1D的容量时，就会出现该关键路径。

为完整起见，这是一张图表，显示了退休指令的数量和执行时间（以秒为单位）。

@PeterCordes建议根据问题大小对测量值进行归一化。下图绘制了BENCHMARK_SIZE的不同值的规范化指令周期计数。周期和指令是不同的单位，因此我认为应该给每个轴分配自己的轴。但是，随后的图形似乎给人一种幻觉，即规范化的指令数变化很大，但事实并非如此，这毫无意义。因此，我决定将两者都绘制在同一根轴上，如图所示。从该图可以轻松观察到IPC和CPI，这很不错。

Haswell内存访问

2 个答案: