5.1。概观

• 我缓存读取（Ir等于执行的指令数），I1缓存读取未命中（I1mr）和LL缓存指令读取misses（ILmr）。

• D缓存读取（Dr等于内存读取次数），D1缓存读取未命中（D1mr）和LL缓存数据读取misses（DLmr）。

• D缓存写入（Dw等于存储器写入数），D1缓存写入未命中（D1mw）和LL缓存数据写入未命中（DLmw）。

• 条件分支执行（Bc）和条件分支mispredicted（Bcm）。

• 间接分支执行（Bi）和间接分支错误（Bim）。

5.2。使用Cachegrind，cg_annotate和cg_merge

要在程序上运行Cachegrind prog，请运行：

valgrind --tool = cachegrind prog

程序将执行（缓慢）。完成后，将打印如下的摘要统计信息：

== 31751 ==我参考：27,742,716
== 31751 == I1 misses：276
== 31751 == LLi misses：275
== 31751 == I1 miss rate：0.0％
== 31751 == LLi miss rate：0.0％
== == 31751
== 31751 == D refs：15,430,290（10,955,517 rd + 4,474,773 wr）
== 31751 == D1 misses：41,185（21,905 rd + 19,280 wr）
== 31751 == LLd misses：23,085（3,987 rd + 19,098 wr）
== 31751 == D1失误率：0.2％（0.1％+ 0.4％）
== 31751 ==差错率：0.1％（0.0％+ 0.4％）
== == 31751
== 31751 == LL misses：23,360（4,262 rd + 19,098 wr）
== 31751 == LL错失率：0.0％（0.0％+ 0.4％）

首先总结指令读取的高速缓存访​​问，给出取得的数量（这是执行的指令数，这可以用于知道自己的权限），I1的次数以及LL指令的数量（LLi）未命中。

缓存访问数据跟随。信息类似于指令提取的信息，除了这些值还显示在读取和写入之间分开（注意每行 rd和 wr值都加在行的总数上）。

LL缓存的组合指令和数据数据就是这样。注意，相对于存储器访问的总数而不是L1未命中的数量来计算LL错误率。也就是 (ILmr + DLmr + DLmw) / (Ir + Dr + Dw) 不是 (ILmr + DLmr + DLmw) / (I1mr + D1mr + D1mw)

默认情况下不收集分支预测统计信息。为此，请添加该选项--branch-sim=yes。

除了打印摘要信息，Cachegrind还将更详细的剖析信息写入文件。默认情况下，该文件被命名 cachegrind.out.<pid>（<pid>程序的进程ID 在哪里 ），但可以使用该--cachegrind-out-file选项更改其名称。该文件是人类可读的，但意图由下一节中描述的随附程序cg_annotate解释。

.<pid>输出文件名中的默认后缀有两个目的。首先，这意味着您不必重命名不想覆盖的旧日志文件。其次，更重要的是，它允许使用--trace-children=yes生成子进程的程序选项进行正确的 分析。

输出文件可以是大的，对于大量应用程序构建完整调试信息的兆字节数。

在使用cg_annotate之前，如果可能，扩展窗口至少应该是120个字符，因为输出行可能相当长。

要获取功能函数摘要，请运行：

cg_annotate <filename>

在Cachegrind输出文件上。

输出的第一部分如下所示：

-------------------------------------------------- ------------------------------
I1缓存：65536 B，64 B，双向关联
D1缓存：65536 B，64 B，双向关联
LL缓存：262144 B，64 B，8路关联
命令：concord vg_to_ucode.c
事件记录：Ir I1mr ILmr Dr D1mr DLmr Dw D1mw DLmw
事件显示：Ir I1mr ILmr Dr D1mr DLmr Dw D1mw DLmw
事件排序顺序：Ir I1mr ILmr Dr D1mr DLmr Dw D1mw DLmw
门槛值：99％
选择注释：
自动注释：关闭

这是注释选项的摘要：

然后按照整个程序的总结统计：

-------------------------------------------------- ------------------------------
Irlmr ILmr Dr D1mr DLmr Dw D1mw DLmw
-------------------------------------------------- ------------------------------
27,742,716 276 275 10,955,517 21,905 3,987 4,474,773 19,280 19,098计划总额

这些与Cachegrind完成运行时提供的摘要类似。

然后来函数统计：

-------------------------------------------------- ------------------------------
Irlmr ILmr Dr D1mr DLmr Dw D1mw DLmw文件：功能
-------------------------------------------------- ------------------------------
8,821,482 5 5 2,242,702 1,621 73 1,794,230 0 0 getc.c：_IO_getc
5,222,023 4 4 2,276,334 16 12 875,959 1 1 concord.c：get_word
2,649,248 2 2 1,344,810 7,326 1,385。。。vg_main.c：STRCMP
2,521,927 2 2 591,215 0 0 179,398 0 0 concord.c：哈希
2,242,740 2 2 1,046,612 568 22 448,548 0 0 ctype.c：tolower
1,496,937 4 4 630,874 9,000 1,400 279,388 0 0 concord.c：insert897,991 51 51 897,831 95 30 62 1 1 ???598,068 1 1 299,034 0 0 149,517 0 0 ../sysdeps/generic/lockfile.c:__flockfile598,068 0 0 299,034 0 0 149,517 0 0 ../sysdeps/generic/lockfile.c:__funlockfile598,024 4 4 213,580 35 16 149,506 0 0 vg_clientmalloc.c：malloc446,587 1 1 215,973 2,167 430 129,948 14,057 13,957 concord.c：add_existing341,760 2 2 128,160 0 0 128,160 0 0 vg_clientmalloc.c：vg_trap_here_WRAPPER320,782 4 4 150,711 276 0 56,027 53 53 concord.c：init_hash_table298,998 1 1 106,785 0 0 64,071 1 1 concord.c：create149,518 0 0 149,516 0 0 1 0 0 ???：tolower @@ GLIBC_2.0149,518 0 0 149,516 0 0 1 0 0 ????：fgetc @@ GLIBC_2.095,983 4 4 38,031 0 0 34,409 3,152 3,150 concord.c：new_word_node85,440 0 0 42,720 0 0 21,360 0 0 vg_clientmalloc.c：vg_bogus_epilogue

每个功能由一file_name:function_name对标识 。如果列只包含一个点，则表示该函数不会执行该事件（例如，第三行显示不 strcmp()包含写入内存的指令）。这个名字 ???是用来如果文件名称和/或函数的名称无法从调试信息来确定。如果大多数条目具有该???:???程序可能未被编译的形式 -g。

值得注意的是，功能将来自concord.c于类别程序（例如）和库（例如getc.c）

有两种注释源文件的方法 - 通过将其手动指定为cg_annotate的参数或使用该 --auto=yes选项。例如，cg_annotate <filename> concord.c对于我们的示例，运行的输出 产生与上述相同的输出，后跟一个注释版本 concord.c，其中的一部分看起来像：

-------------------------------------------------- ------------------------------
- 用户注释源：concord.c
-------------------------------------------------- ------------------------------
Irlmr ILmr Dr D1mr DLmr Dw D1mw DLmw。。。。。。。。。void init_hash_table（char * file_name，Word_Node * table []）3 1 1。。。1 0 0 {。。。。。。。。。FILE * file_ptr;。。。。。。。。。Word_Info *数据;1 0 0。。。1 1 1 int line = 1，i;。。。。。。。。。5 0 0。。。3 0 0 data =（Word_Info *）create（sizeof（Word_Info））;。。。。。。。。。（i = 0; i <TABLE_SIZE; i ++）4,991 0 0 1,995 0 0 998 0 03,988 1 1 1,994 0 0 997 53 52 table [i] = NULL;。。。。。。。。。。。。。。。。。。/ *打开文件，检查。* /6 0 0 1 0 0 4 0 0 file_ptr = fopen（file_name，“r”）;2 0 0 1 0 0。。。if（！（file_ptr））{。。。。。。。。。fprintf（stderr，“无法打开'％s'。\ n”，file_name）;1 1 1。。。。。。出口（EXIT_FAILURE）;。。。。。。。。。}。。。。。。。。。165,062 1 1 73,360 0 0 91,700 0 0 while（（line = get_word（data，line，file_ptr））！= EOF）146,712 0 0 73,356 0 0 73,356 0 0 insert（data  - >; word，data-> line，table）;。。。。。。。。。4 0 0 1 0 0 2 0 0免费（数据）;4 0 0 1 0 0 2 0 0 fclose（file_ptr）;3 0 0 2 0 0。。。}

（尽管柱宽度自动最小化，但广泛的终端显然是有用的。）

每个源文件被清楚地标记为（User-annotated source）被手动选择用于注释。如果在-I/ --includeoptions中指定的目录之一中找到该文件 ，则会同时给出目录和文件。

每一行都用事件计数进行注释。不适用于一行的事件由点表示。这对于区分不能发生的事件和可以但不能发生的事件是有用的。

有时只执行一小部分源文件。为了最小化不感兴趣的输出，Cachegrind仅在注释行的一小段距离内显示注释行和行。间隙标有行号，以便您知道显示的代码来自哪个文件的哪个部分，例如：

（线704的图和代码）
- 第704行----------------------------------------
-  878行----------------------------------------
（第878行的数字和代码）

在注释行显示的上下文的数量由--context 选项控制。

要获取自动注释，请使用该--auto=yes选项。cg_annotate会自动注释每个函数摘要中提到的每个源文件。因此，为自动注释选择的文件会受到--sort和 --threshold选项的影响。每个源文件被清楚地标记为（Auto-annotated source）被自动选择。在输出结尾处提到无法找到的任何文件，例如：

-------------------------------------------------- ----------------
找不到以下选择自动注释的文件：
-------------------------------------------------- ----------------getc.cctype.c../sysdeps/generic/lockfile.c

这对于库文件是很常见的，因为库通常使用调试信息进行编译，但源文件通常不在系统中。如果选择了手动和自动注释的文件，则将其标记为User-annotated source。如果从调试信息中找到的文件名不够详细，请使用 -I/ --include选项告诉Valgrind寻找源文件的位置。

请注意，cg_annotate可能需要一些时间来消化大 cachegrind.out.<pid>文件，例如30秒或更长。还要注意，如果您的程序很大，自动注释可以产生大量的输出！

Valgrind也可以注释汇编代码程序，也可以注释为C程序生成的汇编代码。有时，这有助于了解当有趣的C代码行被转换成多个指令时，真正发生了什么。

为此，您只需要.s使用程序集级调试信息来汇编 文件。您可以使用compile将-SC / C ++程序编译为汇编代码，然后组装汇编代码文件 -g以实现此目的。然后，您可以以与C / C ++源文件相同的方式对汇编代码源文件进行配置和注释。

如果您的程序分叉，该子将继承所有为父级收集的分析数据。

如果输出文件格式字符串（受控制 --cachegrind-out-file）不包含%p，则父和子的输出将混合在单个输出文件中，这几乎肯定会使其不能被cg_annotate读取。

有几种情况，cg_annotate发出警告。

在注释期间可能发生的一些奇怪的事情：

这个列表看起来很长，但是这些例子应该是相当罕见的。

cg_merge是一个简单的程序，它读取由Cachegrind创建的多个配置文件，将它们合并在一起，并以相同的格式将结果写入另一个文件。然后，您可以使用cg_annotate <filename>如上所述来检查合并的结果 。如果您希望通过同一程序的多次运行来汇总成本，或者从具有相同程序的多个实例的单个并行运行中合并功能可能会很有用。

cg_merge被调用如下：

cg_merge -o outputfile file1 file2 file3 ...

它读取和检查file1，然后读取和检查file2并将其合并到运行总计中，然后与file3等同等 。最终结果将写入outputfile或标准输出，如果没有指定输出文件。

成本按每个功能，每行和每个指令进行总结。因为这样，输入文件的顺序不重要，虽然你应该注意只提一次文件，因为提到的两个文件将被添加两次。

cg_merge不会尝试检查输入文件是否来自相同可执行文件的运行。它将很乐意将来自完全不相关程序的配置文件合并在一起。然而，它检查Events:所有输入的 线条是否相同，以确保增加成本是有意义的。例如，将一个数字表示为从一个指定LL写入未命中的不同文件中的一个数字的数字的数字将是无意义的。

在阅读输入时，还会完成许多其他语法和理性检查。如果任何输入文件失败，cg_merge将停止并尝试打印有用的错误消息。

cg_diff是一个简单的程序，它读取由Cachegrind创建的两个配置文件，找到它们之间的区别，并以相同的格式将结果写入另一个文件。然后，您可以使用cg_annotate <filename>如上所述来检查合并的结果 。如果您想衡量一个程序的更改如何影响其性能，这是非常有用的。

cg_diff被调用如下：

cg_diff file1 file2

它读取和检查file1，然后读取和检查file2，然后计算差异（有效file1- file2）。最终结果写入标准输出。

费用是按功能计算的。每行费用并不总计，因为这样做太难了。例如，考虑区分两个配置文件，一个来自单个文件程序A，另一个来自同一程序A，其中在文件顶部插入单个空行。每一行一行计数都发生了变化。相比之下，每个功能的计数没有改变。每个函数的计数差异对于确定程序之间的差异仍然非常有用。注意，因为结果是两个轮廓的差异，许多计数将为负数; 这表示第二版中相关功能的计数少于第一版中的计数。

cg_diff不会尝试检查输入文件是否来自相同可执行文件的运行。它将很乐意将来自完全不相关程序的配置文件合并在一起。然而，它检查Events:所有输入的 线条是否相同，以确保增加成本是有意义的。例如，将一个数字表示为从一个指定LL写入未命中的不同文件中的一个数字的数字的数字将是无意义的。

在阅读输入时，还会完成许多其他语法和理性检查。如果任何输入文件失败，cg_diff将停止并尝试打印有用的错误消息。

有时你会想要比较并排坐的两个版本的程序的Cachegrind配置文件。例如，你可能有 version1/prog.c和 version2/prog.c，其中第二个是第一个稍有不同。两者的直接比较将不是有用的 - 因为函数使用文件名进行限定，所以第一个版本 的功能 f将被列为 第二个版本。version1/prog.c:fversion2/prog.c:f

发生这种情况时，可以使用该--mod-filename选项。它的参数是Perl搜索和替换表达式，它将应用于Cachegrind输出文件中的所有文件名。它可用于删除文件名中的微小差异。例如，这个选项 --mod-filename='s/version[0-9]/versionN/'就足够了。

类似地，有时编译器自动生成某些功能并给它们随机化的名称。例如，GCC有时会自动生成名称类似的函数，T.1234后缀因构建而异。您可以使用该--mod-funcname选项来删除像这样的小差异; 它的工作方式与 --mod-filename。

5.3。Cachegrind命令行选项

--I1=<size>,<associativity>,<line size>

指定级别1指令高速缓存的大小，关联度和行大小。

--D1=<size>,<associativity>,<line size>

指定1级数据缓存的大小，关联度和行大小。

--LL=<size>,<associativity>,<line size>

指定最后一级缓存的大小，关联性和行大小。

--cache-sim=no|yes [yes]

启用或禁用缓存访问和错误计数的收集。

--branch-sim=no|yes [no]

启用或禁用分支指令和错误预测计数的收集。默认情况下，这是禁用的，因为Cachegrind下降了大约25％。请注意，您无法指定--cache-sim=no 并--branch-sim=no 在一起，因为这将使Cachegrind无法收集信息。

--cachegrind-out-file=<file>

将配置文件数据写入 file而不是默认的输出文件 cachegrind.out.<pid>。的 %p和%q格式说明可以用来嵌入进程ID和/或名称的环境变量的内容，由于是用于芯选项的情况下--log-file。

5.4。cg_annotate命令行选项

-h --help

显示帮助信息。

--version

显示版本号。

--show=A,B,C [default: all, using order in cachegrind.out.<pid>]

指定要显示的事件（和列顺序）。默认是使用cachegrind.out.<pid>文件中的所有 文件（并使用文件中的顺序）。如果你想集中精力，比如我缓存misses（--show=I1mr,ILmr）或数据读取misses（--show=D1mr,DLmr）或LL数据丢失（--show=DLmr,DLmw）。最适合使用 --sort。

--sort=A,B,C [default: order in cachegrind.out.<pid>]

指定逐个功能条目排序的事件。

--threshold=X [default: 0.1%]

设置函数功能摘要的阈值。如果占用主排序事件的计数的X％以上，则显示一个函数。如果自动注释，还会影响哪些文件被注释。

注意：可以为多个事件设置阈值，方法是附加--sort冒号和数字的任何事件 （不含空格）。例如，如果您想查看涵盖超过1％LL读取错误或1％LL写入未命中的每个功能，请使用此选项：

--sort=DLmr:1,DLmw:1

--auto=<no|yes> [default: no]

启用后，会自动注释可以找到的逐个功能摘要中提到的每个文件。还列出了无法找到的列表。

--context=N [default: 8]

在每个注释行之前和之后打印N行上下文。避免打印未执行的大部分源文件。使用大量（例如100000）显示所有源行。

-I<dir> --include=<dir> [default: none]

将目录添加到搜索文件的列表中。多-I/ --include 选项可以给添加多个目录。

5.5。cg_merge命令行选项

-o outfile

将配置文件数据写入outfile 而不是标准输出。

5.6。cg_diff命令行选项

-h --help

显示帮助信息。

--version

显示版本号。

--mod-filename=<expr> [default: none]

指定应用于所有文件名的Perl搜索和替换表达式。用于消除位于不同目录的程序的两个不同版本之间的路径中的小差异。

--mod-funcname=<expr> [default: none]

喜欢--mod-filename，但为文件名。有助于消除一些编译器生成的自动生成函数的随机化名称中的微小差异。

5.7。代表Cachegrind的信息

5.8。模拟细节

缓存模拟的具体特点如下：

使用x86 CPUID指令自动确定模拟的缓存配置（缓存大小，关联性和行大小）。如果您有一台机器，（a）不支持CPUID指令，或（b）在不提供任何缓存信息的早期化身中支持，那么Cachegrind将回退到使用默认配置3/4速龙）。Cachegrind会告诉你是否发生这种情况。可以手动指定的命令行的高速缓存中的一个，两个或所有三个级别（I1 / D1 / LL）使用 --I1， --D1和 --LL选项。对于缓存参数对模拟有效，集合的数量（每个组中的高速缓存行数量的关联性）必须是2的幂。

在PowerPC平台Cachegrind不能自动确定缓存配置，所以你将需要与指定它 --I1， --D1和 --LL选项。

其他值得注意的行为：

如果您有兴趣模拟具有不同属性的缓存，编写自己的缓存模拟器或修改现有缓存模拟器并不是特别难 cg_sim.c。我们有兴趣从任何人那里听到。

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

使用16384个2位饱和计数器的数组来预测条件分支。用于分支指令的数组索引部分地由分支指令的地址的低位进行计算，并且部分地使用最后几个条件分支的采取/未采取的行为。因此，任何具体分支的预测都取决于它自己的历史和以前分支的行为。这是提高预测精度的标准技术。

对于间接分支（即跳转到未知目的地），Cachegrind使用一个简单的分支目标地址预测器。使用由分支指令地址的低位9位索引的512个条目的数组预测目标。预计每个分支将跳到与上次相同的地址。任何其他行为都会导致错误预测。

最近的处理器具有更好的分支预测因子，特别是更好的间接分支预测器。Cachegrind的预测器设计是故意保守的，以便代表大型安装的处理器的基础，预先广泛部署更复杂的间接分支预测器。具体来说，晚期型号Pentium 4（Prescott），Pentium M，Core和Core 2具有比Cachegrind建模的更复杂的间接分支预测器。

Cachegrind不会模拟一个返回栈预测器。它假设处理器完美地预测函数返回地址，这个假设可能接近于true。

参见轩尼诗和帕特森的经典文本“计算机体系结构：定量方法”，第4版（2007），第2.3节（第80-89页），用于现代分支预测器的背景。

Valgrind的缓存分析有一些缺点：

值得注意的另一件事是，结果非常敏感。更改正在分析的可执行文件的大小，或其使用的任何共享库的大小，甚至文件名的长度可能会影响结果。变化会很小，但如果您的程序发生变化，不要指望完美的重复性结果。

更新近的GNU / Linux发行版将解决空间随机化问题，其中相同程序的相同运行将其共享库加载到不同位置，作为安全措施。这也扰乱了结果。

虽然这些因素意味着您不应该将结果信任为超级准确，但应该足够接近有用。

5.9。实施细节

了解Cachegrind如何工作的最佳参考是Nicholas Nethercote的“动态二进制分析和仪器”第3章。它可在Valgrind出版物页面上找到。

文件格式相当简单，基本上是给每个行的成本中心，按文件和功能分组。它也是完全一般的和自我描述的，因为它可以用于可以逐行计算的任何事件，而不仅仅是缓存和分支预测器事件。例如，早期版本的Cachegrind没有分支预测器模拟。添加此文件后，文件格式无需更改。所以格式（和因此，cg_annotate）可以被其他工具使用。

文件格式：

file :: = desc_line * cmd_line events_line data_line + summary_line
desc_line :: =“desc：”ws？non_nl_string
cmd_line :: =“cmd：”ws？CMD
events_line :: =“events：”ws？（事件ws）+
data_line :: = file_line | fn_line | count_line
file_line :: =“fl =”filename
fn_line :: =“fn =”fn_name
count_line :: = line_num ws？（计数ws）+
summary_line :: =“summary：”ws？（计数ws）+
count :: = num | “”

哪里：

“desc：”行的内容打印在摘要的顶部。这是提供模拟特定信息的通用方式，例如为高速缓存模拟提供高速缓存配置。

可以为每个文件/ fn /行号显示多行信息。在这种情况下，命名事件的计数将被累积。

计数可以是“”。代表零。这使得文件更容易让人阅读。

在每个计数的数量 line和 summary_line不应超过在事件的数量 event_line。如果每个数字line较少，cg_annotate会将那些丢失的对象视为“。”。条目。这节省了空间。

A file_line更改当前文件名。A fn_line 更改当前函数名称。A count_line包含与当前文件名/ fn_name相关的计数。一个“fn =” file_line， fn_line必须出现在任何count_lines 之前 给出第一个count_lines 的上下文。

每个file_line通常会紧随其后的是a fn_line。但它不一定是。

摘要行是多余的，因为它只保留每个事件的总计数。但这是对数据的有益的健康检查; 如果每个事件的总计与摘要行不匹配，则出现了错误。