问题标签 [cachegrind]

这是 cachegrind 输出的一部分。这部分代码已经执行了 1224 次。elmg1 是一个大小为 16 x 20 的无符号长数组。我的机器 L1 缓存大小为 32KB，缓存行大小为 64B，8 路集关联。

1. 对于 (i = 0; i < 20; i++) 78,336 2,448 2 50,184 0 0 1,224 0 0
2. {
3. telm01 = elmg1[i]; 146,880 0 0 73,440 0 0 24,480 0 0
4. telm31 = (telm01 << 3) ^ val1; 97,920 0 0 48,960 0 0 24,480 0 0
5. telm21 = (telm01 << 2) ^ (val1 >> 1); 146,880 1,224 1 48,960 0 0 24,480 0 0
6. telm11 = (telm01 << 1) ^ (val1 >> 2); 146,880 0 0 48,960 0 0 24,480 0 0
7. }

A. 我把它放在这里的原因是，在 for 循环内的第三行，我看到了许多 I1 未命中（还有一个 L2 未命中）。这有点令人困惑，我猜不出原因？

B. 我正在尝试优化（时间）一部分代码。以上只是一个小片段。我认为在我的程序内存访问中花费了我很多。就像上面的例子一样，elmg1 是一个 16 x 20 大小的无符号长数组。当我尝试在代码中使用它时，总会有一些失误，而在我的程序中，这些变量经常出现。有什么建议么？

C. 我需要分配和（有时初始化）这些无符号长整数。你能建议我更喜欢哪一个，calloc 或数组声明，然后显式初始化。顺便说一句，缓存处理它们的方式会有什么不同吗？

谢谢。

我正在分析一些代码并使用 cachegrind 来获取执行中的缓存未命中数（L2 和 L3）。

我的问题是如何根据缓存未命中来确定等待缓存准备就绪所花费的时间？

我想说“我的代码得到 90% 的 cpu 利用率”之类的话

是否可以根据缓存研磨输出来执行此操作？

同一算法的两个版本在 valgrind/cachegrind 下产生不同的总指令获取计数和周期估计。差异约为 25%。然而，处理时间非常相似（cachegrind-slow 版本实际上更短）：

• 版本 1：

  /li>

• 版本 2：

  /li>

这种行为是预期的吗？我怎样才能更多地了解为什么版本 1 速度较慢？

我打算使用缓存友好的方法将 2 个矩阵相乘（这将导致更少的未命中）

我发现这可以通过缓存友好的转置功能来完成。

但我找不到这个算法。我可以知道如何实现这一目标吗？

Suppose that I choose perf events instructions, LLC-load-misses, LLC-store-misses. Suppose further that I test a program prog varying its input. Is valgrind supposed to give me the "same" functional results for the same input and the same counter? That is, if one value in perf goes up, the one in valgrind should always do the same? Is there any impact in valgrind being a simulation that I should be aware of during profiling my code?

EDIT: BTW, before people grill me for not experimenting myself, I have to say that I (kinda) have, the problem is that I have a Sandybridge processor, and perf has a "bug" that prevents me from measuring LLC-* events. There is a patch, but I don't feel like recompiling my kernel...

我正在尝试为 cachegrind 配置 Xdebug，但我无法启用探查器功能以转储执行的网页。

我正在使用官方指南（以及更多类似设置的指南），但它似乎不起作用。

我在我的两台 Linux 机器（Ubuntu 和 Fedora）上都试过了。Xdebug 可以很好地进行调试，我可以启动valgrind --tool=cachegrind应用程序，因此两者都应该正确安装。

我在 php.ini 中激活和停用 profiler_enable 和 profiler_enable_trigger 选项并重新启动服务器，没有运气。更改了输出目录，因为我认为它可能与权限有关。使用?XDEBUG_PROFILER=1URL 中的标志作为参数似乎也无济于事。

与 cachegrind 的配置相关的任何其他线索？

I am doing some experiments with Cachegrind, Callgrind and Gem5. I noticed that a number of accesses were counted as read for cachegrind, as write for callgrind and for both read and write by gem5.

Let's take a very simple example:

I compile with:

gcc ex.c --static -o ex

So basically, according to the asm file, addl $1, -8(%rbp) is executed 100,000 times. Since it's both a read and a write, I was expecting 100k read and 100k write. However, cachegrind only counts them as read and callgrind only as write.

-

Could someone give me a reasonable explanation? Would I be correct to consider there are in fact ~100k reads and ~100k writes (i.e. 2 cache accesses for an addl)?

我对两个类似的函数进行了逐行计数，使用方式完全相同。函数声明行 (void f(...)) 的 Ir 计数非常不同：一个为 999,999,993，另一个仅为 284。这是什么意思？

我正在使用 Cachegrind 来检索没有 libc 编译的静态程序的缓存未命中数（只是_start调用我的 main 函数和 asm 中的退出系统调用）。该程序是完全确定的，指令和内存引用不会从一次运行到另一次运行。缓存与作为替换策略的 LRU 完全关联。

但是，我注意到未命中的数量有时会发生变化。更具体地说，在我转到不同的目录之前，未命中的次数总是相同的：

如果我一次又一次地执行相同的命令，我将继续得到相同的结果。但是如果我从不同的目录运行这个程序：

我什至从不同的目录得到不同的结果。

我还用 Pin 工具做了一些实验，使用这个我不需要更改目录来获取不同的值。但似乎可能值的集合非常有限，并且与 Cachegrind 完全相同。

我的问题是：这种差异的根源是什么？

我的第一个提示是我的程序在内存中的对齐方式不同，因此，在之前的运行中存储在同一行中的一些变量不再存在。这也可以解释有限数量的组合。但我虽然缓存研磨（和 Pin）正在使用虚拟地址，但我假设操作系统（Linux）总是提供相同的虚拟地址。还有什么想法吗？

编辑：您可以猜到读取 LLd 未命中，该程序仅使用 31 个不同的缓存行。此外，缓存只能包含 8 个缓存行。因此，即使在现实中，这种差异也无法通过第二次填充缓存的想法来解释（在最大情况下，L1 中只能保留 8 行）。

编辑 2： Cachegrind 的报告不是基于实际的缓存未命中（由性能计数器给出），而是模拟的结果。基本上，它模拟缓存的行为以计算未命中的数量。由于结果只是暂时的，这完全没问题，并且允许更改缓存属性（大小、关联性）。

编辑 3：我使用的硬件是 Linux 3.2 x86_64 上的 Intel Core i7。编译标志是 -static 并且对于某些程序 -nostdlib （IIRC，我现在不在家）。

出于好奇，我编写了几个不同版本的矩阵乘法并对它运行 cachegrind。在下面的结果中，我想知道哪些部分是 L1、L2、L3 未命中和引用，它们的真正含义是什么？下面是我的矩阵乘法代码，以防万一有人需要。

矩阵乘法代码。