问题标签 [cachegrind]

我想使用 cachegrind 在 OpenJDK JVM 上进行一些性能分析。（顺便说一句，如果这不是一个好主意，我想了解原因。）

问题是它不断地在 JVM 中触发断言。那么我该怎么做才能使用 cachegrind 来运行呢？否则，请告诉我为什么这行不通。如果您可以建议替代缓存研磨。（请注意，我已经查看并使用了 perf。只是我很好奇像 cachegrind/callgrind 这样的工具在结果方面会有多么不同。）

受 SQLite 的启发，我正在考虑使用 valgrind 的“cachegrind”工具来进行可重现的性能基准测试。它输出的数字比我发现的任何其他计时方法都稳定得多，但它们仍然不是确定性的。例如，这是一个简单的 C 程序：

如果我编译它并在 cachegrind 下运行它，我会得到以下结果：

在这种情况下，“I refs”在两次运行之间仅相差 0.008%，但我仍然想知道为什么这些不同。在更复杂的程序（几十毫秒）中，它们的变化可能更大。有什么方法可以使运行完​​全可重现？

我正在尝试使用 cachegrind 测试我的程序在不同缓存大小上的性能。如何在命令中设置最后一级的缓存大小？（我已经读过应该使用标志 --LL 但它不起作用。你能给我一个命令的例子吗？）

非常感谢！

当我尝试使用wincachegrind并获取cachegrind文件时，它返回

找不到呼叫目标。

cachegrind.out 行号：68

有谁知道如何解决这个问题？

更新，这是错误的屏幕截图：

点击这个链接

我目前正试图了解我的一个 C 程序中的一些非常奇怪的行为。显然，在其末尾添加或删除看似无关紧要的行会极大地影响程序其余部分的性能。

我的程序看起来有点像这样：

理论上，fclose(input)主函数末尾的那一行应该无关紧要，因为操作系统应该在程序末尾自动关闭文件。然而，我观察到，当我包含 fclose 语句时，我的程序需要 2.5 秒才能运行，而当我将其注释掉时，我需要 5 秒。相差2倍！这不是由于程序开始或结束时的延迟：在.使用 fclose 语句的版本中，打印出来的速度明显更快。

我怀疑这可能与某些内存对齐或缓存未命中问题有关。如果我用另一个函数（例如 ftell）替换 fclose，它也需要 5 秒才能运行，如果我将large_buffer元素的大小减小到 <= 8000，那么它总是在 2.5 秒内运行，无论 fclose 语句是否存在。

但我真的很想能够 100% 确定这种奇怪行为背后的罪魁祸首是什么。是否有可能在某种分析器或其他工具下运行我的程序，这些工具会给我这些信息？到目前为止，我尝试在两个版本下运行，valgrind --tool=cachegrind但它报告了我的程序的两个版本的相同数量的缓存未命中 (0%)。

编辑1：在运行我的程序的两个版本后，perf stat -d -d -d我得到以下结果：

正如 kcachegrind 报告的那样，看起来在这两种情况下都很少有数据缓存未命中，但程序的较慢版本具有更差的分支预测和更多的指令缓存未命中和 iTLB 负载。这些差异中的哪一个最有可能导致测试用例之间运行时的 2 倍差异？

编辑2：有趣的事实，如果我用一条NOP指令替换“fclose”调用，显然我仍然可以保持奇怪的行为。

编辑 3：我的处理器是 Intel i5-2310（Sandy Bridge）

编辑 4：事实证明，如果我通过编辑程序集文件来调整数组的大小，它不会变得更快。显然，当我在 C 代码中更改它们的大小时它变得更快的原因是因为 gcc 决定重新排列二进制文件中的东西的顺序。

编辑 5：更多证据表明重要的是 JMP 指令的精确地址：如果我在代码开头添加一个 NOP（而不是 printf），它会变得更快。同样，如果我从代码的开头删除一条无用的指令，它也会变得更快。当我在不同版本的 gcc 上编译我的代码时，它也变得更快，尽管生成的汇编代码是相同的。唯一的区别是开始时的调试信息，并且二进制文件的各个部分的顺序不同。

我目前正在学习 Linux 下的各种分析和性能实用程序，尤其是 valgrind/cachegrind。

我有以下玩具程序：

g++ -O2 -g main.cpp编译并运行该程序valgrind --tool=cachegrind ./a.out，然后cg_annotate cachegrind.out.31694 --auto=yes产生以下结果：

我担心的是这条线：

为什么这条线有这么多缓存未命中？数据在连续内存中，每次迭代我都在读取 64 字节的数据（假设缓存线的长度为 64 字节）。

我在 Ubuntu Linux 18.04.1、内核 4.19、g++ 7.3.0 上运行这个程序。电脑是AMD 2400G。

我为这个明显的差异绞尽脑汁：

• 我的页面大约需要 8 秒才能加载。
• Wincachegrind 说我的页面只需要 0.8 秒

我终于在 kcachegrind 中加载了相同的 cachegrind 文件，并得到了与实际页面加载一致的结果。

那么为什么 wincachegrind 给我的 curl 调用的值不正确呢？看起来所有超过 1 秒的值都被错误地报告了 10 倍..？

http://imgur.com/eMjmALA

是否有实用的工具来检测是否由于空间或时间局部性而重用缓存行（避免缓存未命中）？

我在cachegrind中找不到相关讨论。我只能找到这篇论文和这篇论文，但找不到其中介绍的工具。

我有一个编译为 x86-64 机器代码的 C++ 函数，我想测量它在给定输入上的运行时间。我希望能够知道何时更改我的代码会导致性能下降，因此我想在 CI 中运行此基准测试并测试该函数最多需要 X 毫秒才能运行。

但是，执行时间是不确定的，所以这样的测试会很不稳定。

有没有我可以用来使这个测试具有确定性的工具？我想通过在模拟器中运行代码并使用一些启发式方法来近似总时间，我想这样的工具将给出执行时间的确定性估计（在给定的 CPU 模型上以给定的时钟速率和给定的 RAM 时钟/延迟）运行时间。

（一个简单的启发式方法是计算机器指令退役并假设每条指令 Y ns，但更复杂的方法也将查看内存访问和模型缓存命中/未命中。我看不出这种工具不能的技术原因t 存在，除了考虑到现代 CPU 架构的复杂性和它们支持的指令集的大小，编写一个得到接近准确的估计值的程序会很棘手。）

我是 cachegrind 用于程序分析的长期用户，最近又回去查看官方文档：https ://valgrind.org/docs/manual/cg-manual.html

其中，多处引用了 2000 年代中期的 CPU 模型、实现决策和仿真模型，还有一些声明表明“现代”处理器上的某些行为发生了变化：

LL 缓存通常复制 L1 缓存的所有条目 [...] 这是 Pentium 芯片的标准配置，但 AMD Opterons、Athlon 和 Durons 使用专有的 LL 缓存 [...]

Cachegrind 模拟了 2004 年左右主流桌面/服务器处理器的典型分支预测器。

最新的处理器具有更好的分支预测器 [...] Cachegrind 的预测器设计是故意保守的，以便代表在更复杂的间接分支预测器广泛部署之前的大量处理器安装基础。特别是，后期模型 Pentium 4s (Prescott)、Pentium M、Core 和 Core 2 具有比 Cachegrind 建模的更复杂的间接分支预测器。

现在我想知道

• 在最新一代 CPU 上开发时，这些选择中有多少在 2021 年仍然适用，
• cachegrind 的实现是否已更新以反映最新的 CPU，但手册已过时，
• cachegrind 是否由于模拟遗留行为而在现代 CPU 上显示出偏差的结果。

非常感谢任何见解！