Linux C++：如何分析由于缓存未命中而浪费的时间？

Question

我知道我可以使用 gprof 对我的代码进行基准测试。

但是，我有这个问题——我有一个智能指针，它具有额外的间接级别（将其视为代理对象）。

结果，我有了这个额外的层，它几乎影响所有功能，并且具有缓存功能。

有没有办法测量我的 CPU 由于缓存未命中而浪费的时间？

Answer 1

Linux 从 2.6.31 开始支持 perf。这允许您执行以下操作：

• 使用 -g 编译代码以包含调试信息
• 运行代码，例如使用最后一级缓存未命中计数器：perf record -e LLC-loads,LLC-load-misses yourExecutable
• 运行性能报告
  • 确认初始消息后，选择 LLC-load-misses 行，
  • 然后例如第一个函数和
  • 然后注释。您应该看到这些行（在汇编代码中，被原始源代码包围）和一个数字，该数字指示发生缓存未命中的行的最后一级缓存未命中的比例。

Answer 2

你可以尝试 cachegrind 它是前端 kcachegrind。

Answer 3

您可以找到一个访问 CPU 性能计数器的工具。每个内核中可能有一个寄存器用于计算 L1、L2 等未命中次数。或者，Cachegrind 执行逐周期模拟。

然而，我不认为这会是有洞察力的。您的代理对象可能是通过它们自己的方法进行修改的。 传统的分析器会告诉您这些方法花费了多少时间。没有分析工具会告诉您如果没有缓存污染源，性能将如何提高。这是减少程序工作集的大小和结构的问题，这不容易推断。

快速 Google 搜索发现了 boost::intrusive_ptr您可能会感兴趣。它似乎不支持像 weak_ptr 这样的东西，但是转换你的程序可能很简单，然后你就可以确定地知道非侵入式引用计数的成本。

Answer 4

继续沿着 @Mike_Dunlavey 的答案：

首先，使用您最喜欢的工具获取基于时间的配置文件：VTune 或 PTU 或 OProf。

然后，获取缓存未命中配置文件。 L1 高速缓存未命中，或 L2 高速缓存未命中，或...

即，第一个配置文件将“花费的时间”与每个程序计数器相关联。
第二个将“高速缓存未命中次数”值与每个程序计数器相关联。

注意：我经常“减少”数据，通过函数或（如果我有技术）通过循环对其进行总结。或者按 64 字节的 bin。比较各个程序计数器通常没有用，因为性能计数器是模糊的 - 您看到报告缓存未命中的位置通常是与实际发生位置不同的几条指令。

好的，现在绘制这两个配置文件以进行比较。以下是我认为有用的一些图表：

“冰山”图表：X 轴是 PC，正 Y 轴是时间，负 Y 访问是缓存未命中。寻找同时上升和下降的地方。

（“交错”图表也很有用：同样的想法，X 轴是 PC，在 Y 轴上绘制时间和缓存缺失，但具有不同颜色的窄垂直线，通常是红色和蓝色。时间和缓存都很多的地方花费的未命中将有精细交错的红色和蓝色线，几乎看起来是紫色的，这延伸到 L2 和 L3 缓存未命中，所有这些都在同一张图表上。时间或缓存未命中，或者更好的是，时间或缓存未命中最大数据点的百分比。如果比例错误，您将看不到任何内容。）

XY 图表：对于每个。采样箱（PC、函数、循环或...）绘制一个点，其 X 坐标是标准化时间，Y 坐标是标准化缓存未命中。如果您在右上角获得大量数据点 - 大的 %age 时间和大的 %age 缓存未命中 - 这是有趣的证据。或者，忘记点数 - 如果上角所有百分比的总和很大...

请注意，不幸的是，您经常必须自己进行这些分析。上次我检查过 VTune 不适合你。我使用过 gnuplot 和 Excel。 （警告：Excel 在超过 64000 个数据点时会崩溃。）

---

更多建议：

如果您的智能指针是内联的，您可能会得到到处都是的计数。在理想的情况下，您将能够追溯到 PC 的原始源代码行。在这种情况下，您可能需要稍微推迟一下减少时间：查看所有单独的 PC；将它们映射回源代码行；然后将它们映射到原始函数中。许多编译器（例如 GCC）都有允许您执行此操作的符号表选项。

顺便说一句，我怀疑您的问题不在于智能指针导致缓存抖动。除非你正在做 smart_ptr到处都是。如果您正在执行 smart_ptr，并且 sizeof(Obj) + 大于 4*sizeof(Obj*) （并且如果 smart_ptr 本身并不大），那么它就不会那么多。

更可能的是，智能指针执行的额外间接级别导致了您的问题。

的是，我在午餐时与一个人交谈，他有一个使用句柄的引用计数智能指针，即间接级别，类似于

template<typename T> class refcntptr {
    refcnt_handle<T> handle;
public:
    refcntptr(T*obj) {
        this->handle = new refcnt_handle<T>();
        this->handle->ptr = obj;
        this->handle->count = 1;
    }
};
template<typename T> class refcnt_handle {
    T* ptr;
    int count;
    friend refcnt_ptr<T>;
};

（我不会这样编码，但它用于说明。）

巧合 间接 this->handle->ptr 可能是一个很大的性能问题。或者甚至是三重间接，this->handle->ptr->field。至少，在具有 5 个周期 L1 缓存命中的机器上，每个 this->handle->ptr->field 将花费 10 个周期。并且比单个指针追逐更难重叠。但是，更糟糕的是，如果每个都是 L1 缓存未命中，即使到 L2 只有 20 个周期……嗯，隐藏 2*20=40 个周期的缓存未命中延迟比单个 L1 未命中要困难得多。

一般来说，避免智能指针中的间接级别是个好建议。您可以通过让智能指针指向对象和句柄来使智能指针更大，而不是指向所有智能指针所指向的句柄（句柄本身也指向对象）。 （这不再是通常所说的句柄，而更像是一个信息对象。）

例如

template<typename T> class refcntptr {
    refcnt_info<T> info;
    T* ptr;
public:
    refcntptr(T*obj) {
        this->ptr = obj;
        this->info = new refcnt_handle<T>();
        this->info->count = 1;
    }
};
template<typename T> class refcnt_info {
    T* ptr; // perhaps not necessary, but useful.
    int count;
    friend refcnt_ptr<T>;
};

，无论如何 - 时间配置文件是您最好的朋友。

---

哦，是的 - 英特尔 EMON 硬件还可以告诉您在 PC 上等待了多少个周期。这可以区分大量的 L1 未命中和少量的 L2 未命中。

Answer 5

这取决于您使用的操作系统和 CPU。例如，对于 Mac OS X 和 x86 或 ppc，Shark 将进行缓存未命中分析。 Linux 上的 Zoom 也是如此。

Answer 6

如果您运行的是 AMD 处理器，则可以获得 CodeAnalyst，显然像啤酒一样免费。

Answer 7

我的建议是使用 PTU （性能英特尔的调优实用程序）。

该实用程序是 VTune 的直接后代，提供最佳可用的采样分析器。您将能够跟踪 CPU 在哪里花费或浪费时间（借助可用的硬件事件），并且不会减慢您的应用程序或扰乱配置文件。
当然，您将能够收集您正在查找的所有缓存行未命中事件。

Answer 8

另一个基于 CPU 性能计数器的分析工具是 oprofile。您可以使用 kcachegrind 查看其结果。

Answer 9

这是一般答案。

例如，如果您的程序花费了 50% 的时间在缓存未命中中，那么当您暂停它时，程序计数器有 50% 的时间将位于它正在等待导致内存读取的确切位置。缓存未命中。