c++ - L1-cache缓存2KB数据时内存带宽崩溃的原因

问题描述

在一个自学项目中，我借助以下代码测量了内存的带宽（这里转述一下，整个代码在问题的末尾）：

unsigned int doit(const std::vector<unsigned int> &mem){
   const size_t BLOCK_SIZE=16;
   size_t n = mem.size();
   unsigned int result=0;
   for(size_t i=0;i<n;i+=BLOCK_SIZE){           
             result+=mem[i];
   }
   return result;
}

//... initialize mem, result and so on
int NITER = 200; 
//... measure time of
   for(int i=0;i<NITER;i++)
       resul+=doit(mem)

BLOCK_SIZE以这样一种方式选择，即每次整数加法都会获取整个 64 字节的高速缓存行。我的机器（Intel-Broadwell）每个整数加法需要大约 0.35 纳秒，所以上面的代码可以使高达 182GB/s 的带宽饱和（这个值只是一个上限，可能相当偏离，重要的是不同大小的带宽比率）。代码用g++和编译-O3。

改变向量的大小，我可以观察到 L1(*)-、L2-、L3 缓存和 RAM 内存的预期带宽：

然而，有一个效果我真的很难解释：L1 缓存的测量带宽崩溃，大小约为 2 kB，这里的分辨率略高：

我可以在我可以访问的所有机器（具有 Intel-Broadwell 和 Intel-Haswell 处理器）上重现结果。

我的问题： 2 KB 左右的内存大小导致性能崩溃的原因是什么？

(*) 我希望我理解正确，对于 L1 缓存不是 64 字节，而是每次添加只有 4 个字节被读取/传输（没有更快的缓存必须填充缓存行），所以 L1 的绘制带宽是只有上限，而不是 badwidth 本身。

Edit : When the step size in the inner for-loop is chosen to be

8（而不是 16）崩溃发生在 1KB
4（而不是 16）崩溃发生 0.5KB

即当内部循环由大约 31-35 步/读取组成时。这意味着崩溃不是由于内存大小，而是由于内部循环中的步骤数。

如@user10605163's great answer所示，它可以用分支未命中来解释。

用于重现结果的列表

bandwidth.cpp：

#include <vector>
#include <chrono>
#include <iostream>
#include <algorithm>


//returns minimal time needed for one execution in seconds:
template<typename Fun>
double timeit(Fun&& stmt, int repeat, int number)
{  
   std::vector<double> times;
   for(int i=0;i<repeat;i++){
       auto begin = std::chrono::high_resolution_clock::now();
       for(int i=0;i<number;i++){
          stmt();
       }
       auto end = std::chrono::high_resolution_clock::now();
       double time = std::chrono::duration_cast<std::chrono::nanoseconds>(end-begin).count()/1e9/number;
       times.push_back(time);
   }
   return *std::min_element(times.begin(), times.end());
}


const int NITER=200;
const int NTRIES=5;
const size_t BLOCK_SIZE=16;


struct Worker{
   std::vector<unsigned int> &mem;
   size_t n;
   unsigned int result;
   void operator()(){
        for(size_t i=0;i<n;i+=BLOCK_SIZE){           
             result+=mem[i];
        }
   }

   Worker(std::vector<unsigned int> &mem_):
       mem(mem_), n(mem.size()), result(1)
   {}
};

double PREVENT_OPTIMIZATION=0.0;


double get_size_in_kB(int SIZE){
   return SIZE*sizeof(int)/(1024.0);
}

double get_speed_in_GB_per_sec(int SIZE){
   std::vector<unsigned int> vals(SIZE, 42);
   Worker worker(vals);
   double time=timeit(worker, NTRIES, NITER);
   PREVENT_OPTIMIZATION+=worker.result;
   return get_size_in_kB(SIZE)/(1024*1024)/time;
}


int main(){

   int size=BLOCK_SIZE*16;
   std::cout<<"size(kB),bandwidth(GB/s)\n";
   while(size<10e3){
       std::cout<<get_size_in_kB(size)<<","<<get_speed_in_GB_per_sec(size)<<"\n";
       size=(static_cast<int>(size+BLOCK_SIZE)/BLOCK_SIZE)*BLOCK_SIZE;
   }

   //ensure that nothing is optimized away:
   std::cerr<<"Sum: "<<PREVENT_OPTIMIZATION<<"\n";
}

create_report.py：

import sys
import pandas as pd
import matplotlib.pyplot as plt

input_file=sys.argv[1]
output_file=input_file[0:-3]+'png'
data=pd.read_csv(input_file)

labels=list(data)    
plt.plot(data[labels[0]], data[labels[1]], label="my laptop")
plt.xlabel(labels[0])
plt.ylabel(labels[1])   
plt.savefig(output_file)
plt.close()

构建/运行/创建报告：

>>> g++ -O3 -std=c++11 bandwidth.cpp -o bandwidth
>>> ./bandwidth > report.txt
>>> python create_report.py report.txt
# image is in report.png

标签： c++linuxperformancex86-64intel

解决方案

我稍微改变了这些值：NITER = 100000并NTRIES=1得到一个噪音较小的结果。

我现在没有可用的 Broadwell，但是我在 Coffee-Lake 上尝试了你的代码，性能下降了，不是 2KB，而是大约 4.5KB。此外，我发现略高于 2KB 的吞吐量行为不稳定。

图中的蓝线对应于您的测量值（左轴）：

这里的红线是的结果perf stat -e branch-instructions,branch-misses，给出了未正确预测的分支比例（百分比，右轴）。如您所见，两者之间存在明显的反相关性。

查看更详细的perf报告，我发现基本上所有这些分支错误预测都发生在Worker::operator(). 如果循环分支的采用/未采用模式变得太长，分支预测器将无法跟踪它，因此内部循环的出口分支将被错误预测，导致吞吐量急剧下降。随着迭代次数的进一步增加，这种单一错误预测的影响将变得不那么显着，从而导致吞吐量恢复缓慢。

有关下降前不稳定行为的更多信息，请参阅下面@PeterCordes 的评论。

在任何情况下，避免分支错误预测的最佳方法是避免分支，因此我手动展开循环Worker::operator()，例如：

void operator()(){
    for(size_t i=0;i+3*BLOCK_SIZE<n;i+=BLOCK_SIZE*4){
         result+=mem[i];
         result+=mem[i+BLOCK_SIZE];
         result+=mem[i+2*BLOCK_SIZE];
         result+=mem[i+3*BLOCK_SIZE];
    }
}

展开 2、3、4、6 或 8 次迭代会得到以下结果。请注意，我没有纠正由于展开而被忽略的向量末尾的块。因此蓝线中的周期性峰值应该被忽略，周期性图案的下限基线是实际带宽。

正如你所看到的，分支错误预测的比例并没有真正改变，但是由于分支的总数被展开迭代的因素减少了，它们不再对性能有很大的贡献。

如果循环展开，处理器还有一个额外的好处是可以更自由地进行无序计算。

如果这应该有实际应用，我建议尝试给热循环一个编译时固定的迭代次数或对可分割性的一些保证，以便（可能有一些额外的提示）编译器可以决定最佳数量迭代展开。

c++ - L1-cache缓存2KB数据时内存带宽崩溃的原因

问题描述

解决方案

推荐阅读