njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1 | <?xml version="1.0"?> <!-- -*- sgml -*- --> |
| 2 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
sewardj | 7aeb10f | 2006-12-10 02:59:16 +0000 | [diff] [blame] | 3 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" |
| 4 | [ <!ENTITY % vg-entities SYSTEM "../../docs/xml/vg-entities.xml"> %vg-entities; ]> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 5 | |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 6 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 7 | <chapter id="cg-manual" xreflabel="Cachegrind: a cache-miss profiler"> |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 8 | <title>Cachegrind: a cache and branch profiler</title> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 9 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 10 | <sect1 id="cg-manual.cache" xreflabel="Cache profiling"> |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 11 | <title>Cache and branch profiling</title> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 12 | |
| 13 | <para>To use this tool, you must specify |
| 14 | <computeroutput>--tool=cachegrind</computeroutput> on the |
| 15 | Valgrind command line.</para> |
| 16 | |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 17 | <para>Cachegrind is a tool for finding places where programs |
| 18 | interact badly with typical modern superscalar processors |
| 19 | and run slowly as a result. |
| 20 | In particular, it will do a cache simulation of your program, |
| 21 | and optionally a branch-predictor simulation, and can |
| 22 | then annotate your source line-by-line with the number of cache |
| 23 | misses and branch mispredictions. The following statistics are |
| 24 | collected:</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 25 | <itemizedlist> |
| 26 | <listitem> |
| 27 | <para>L1 instruction cache reads and misses;</para> |
| 28 | </listitem> |
| 29 | <listitem> |
| 30 | <para>L1 data cache reads and read misses, writes and write |
| 31 | misses;</para> |
| 32 | </listitem> |
| 33 | <listitem> |
| 34 | <para>L2 unified cache reads and read misses, writes and |
| 35 | writes misses.</para> |
| 36 | </listitem> |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 37 | <listitem> |
| 38 | <para>Conditional branches and mispredicted conditional branches.</para> |
| 39 | </listitem> |
| 40 | <listitem> |
| 41 | <para>Indirect branches and mispredicted indirect branches. An |
| 42 | indirect branch is a jump or call to a destination only known at |
| 43 | run time.</para> |
| 44 | </listitem> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 45 | </itemizedlist> |
| 46 | |
njn | c8cccb1 | 2005-07-25 23:30:24 +0000 | [diff] [blame] | 47 | <para>On a modern machine, an L1 miss will typically cost |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 48 | around 10 cycles, an L2 miss can cost as much as 200 |
| 49 | cycles, and a mispredicted branch costs in the region of 10 |
| 50 | to 30 cycles. Detailed cache and branch profiling can be very useful |
| 51 | for improving the performance of your program.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 52 | |
| 53 | <para>Also, since one instruction cache read is performed per |
| 54 | instruction executed, you can find out how many instructions are |
| 55 | executed per line, which can be useful for traditional profiling |
| 56 | and test coverage.</para> |
| 57 | |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 58 | <para>Branch profiling is not enabled by default. To use it, you must |
| 59 | additionally specify <computeroutput>--branch-sim=yes</computeroutput> |
| 60 | on the command line.</para> |
| 61 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 62 | |
| 63 | <sect2 id="cg-manual.overview" xreflabel="Overview"> |
| 64 | <title>Overview</title> |
| 65 | |
| 66 | <para>First off, as for normal Valgrind use, you probably want to |
| 67 | compile with debugging info (the |
| 68 | <computeroutput>-g</computeroutput> flag). But by contrast with |
| 69 | normal Valgrind use, you probably <command>do</command> want to turn |
| 70 | optimisation on, since you should profile your program as it will |
| 71 | be normally run.</para> |
| 72 | |
| 73 | <para>The two steps are:</para> |
| 74 | <orderedlist> |
| 75 | <listitem> |
| 76 | <para>Run your program with <computeroutput>valgrind |
| 77 | --tool=cachegrind</computeroutput> in front of the normal |
| 78 | command line invocation. When the program finishes, |
| 79 | Cachegrind will print summary cache statistics. It also |
| 80 | collects line-by-line information in a file |
| 81 | <computeroutput>cachegrind.out.pid</computeroutput>, where |
| 82 | <computeroutput>pid</computeroutput> is the program's process |
| 83 | id.</para> |
| 84 | |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 85 | <para>Branch prediction statistics are not collected by default. |
| 86 | To do so, add the flag |
| 87 | <computeroutput>--branch-sim=yes</computeroutput>. |
| 88 | </para> |
| 89 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 90 | <para>This step should be done every time you want to collect |
| 91 | information about a new program, a changed program, or about |
| 92 | the same program with different input.</para> |
| 93 | </listitem> |
| 94 | |
| 95 | <listitem> |
| 96 | <para>Generate a function-by-function summary, and possibly |
| 97 | annotate source files, using the supplied |
| 98 | <computeroutput>cg_annotate</computeroutput> program. Source |
| 99 | files to annotate can be specified manually, or manually on |
| 100 | the command line, or "interesting" source files can be |
| 101 | annotated automatically with the |
| 102 | <computeroutput>--auto=yes</computeroutput> option. You can |
| 103 | annotate C/C++ files or assembly language files equally |
| 104 | easily.</para> |
| 105 | |
| 106 | <para>This step can be performed as many times as you like |
| 107 | for each Step 2. You may want to do multiple annotations |
| 108 | showing different information each time.</para> |
| 109 | </listitem> |
| 110 | |
| 111 | </orderedlist> |
| 112 | |
sewardj | 94dc508 | 2007-02-08 11:31:03 +0000 | [diff] [blame] | 113 | <para>As an optional intermediate step, you can use the supplied |
| 114 | <computeroutput>cg_merge</computeroutput> program to sum together the |
| 115 | outputs of multiple Cachegrind runs, into a single file which you then |
| 116 | use as the input for |
| 117 | <computeroutput>cg_annotate</computeroutput>.</para> |
| 118 | |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 119 | <para>These steps are described in detail in the following |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 120 | sections.</para> |
| 121 | |
| 122 | </sect2> |
| 123 | |
| 124 | |
de | bc32e82 | 2005-06-25 14:43:05 +0000 | [diff] [blame] | 125 | <sect2 id="cache-sim" xreflabel="Cache simulation specifics"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 126 | <title>Cache simulation specifics</title> |
| 127 | |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 128 | <para>Cachegrind simulates a machine with independent |
| 129 | first level instruction and data caches (I1 and D1), backed by a |
| 130 | unified second level cache (L2). This configuration is used by almost |
| 131 | all modern machines. Some old Cyrix CPUs had a unified I and D L1 |
| 132 | cache, but they are ancient history now.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 133 | |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 134 | <para>Specific characteristics of the simulation are as |
| 135 | follows:</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 136 | |
| 137 | <itemizedlist> |
| 138 | |
| 139 | <listitem> |
| 140 | <para>Write-allocate: when a write miss occurs, the block |
| 141 | written to is brought into the D1 cache. Most modern caches |
| 142 | have this property.</para> |
| 143 | </listitem> |
| 144 | |
| 145 | <listitem> |
| 146 | <para>Bit-selection hash function: the line(s) in the cache |
| 147 | to which a memory block maps is chosen by the middle bits |
| 148 | M--(M+N-1) of the byte address, where:</para> |
| 149 | <itemizedlist> |
| 150 | <listitem> |
| 151 | <para>line size = 2^M bytes</para> |
| 152 | </listitem> |
| 153 | <listitem> |
| 154 | <para>(cache size / line size) = 2^N bytes</para> |
| 155 | </listitem> |
| 156 | </itemizedlist> |
| 157 | </listitem> |
| 158 | |
| 159 | <listitem> |
| 160 | <para>Inclusive L2 cache: the L2 cache replicates all the |
| 161 | entries of the L1 cache. This is standard on Pentium chips, |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 162 | but AMD Opterons, Athlons and Durons |
| 163 | use an exclusive L2 cache that only holds |
| 164 | blocks evicted from L1. Ditto most modern VIA CPUs.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 165 | </listitem> |
| 166 | |
| 167 | </itemizedlist> |
| 168 | |
| 169 | <para>The cache configuration simulated (cache size, |
| 170 | associativity and line size) is determined automagically using |
| 171 | the CPUID instruction. If you have an old machine that (a) |
| 172 | doesn't support the CPUID instruction, or (b) supports it in an |
| 173 | early incarnation that doesn't give any cache information, then |
| 174 | Cachegrind will fall back to using a default configuration (that |
| 175 | of a model 3/4 Athlon). Cachegrind will tell you if this |
| 176 | happens. You can manually specify one, two or all three levels |
| 177 | (I1/D1/L2) of the cache from the command line using the |
| 178 | <computeroutput>--I1</computeroutput>, |
| 179 | <computeroutput>--D1</computeroutput> and |
| 180 | <computeroutput>--L2</computeroutput> options.</para> |
| 181 | |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 182 | <para>On PowerPC platforms |
| 183 | Cachegrind cannot automatically |
| 184 | determine the cache configuration, so you will |
| 185 | need to specify it with the |
| 186 | <computeroutput>--I1</computeroutput>, |
| 187 | <computeroutput>--D1</computeroutput> and |
| 188 | <computeroutput>--L2</computeroutput> options.</para> |
| 189 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 190 | |
| 191 | <para>Other noteworthy behaviour:</para> |
| 192 | |
| 193 | <itemizedlist> |
| 194 | <listitem> |
| 195 | <para>References that straddle two cache lines are treated as |
| 196 | follows:</para> |
| 197 | <itemizedlist> |
| 198 | <listitem> |
| 199 | <para>If both blocks hit --> counted as one hit</para> |
| 200 | </listitem> |
| 201 | <listitem> |
| 202 | <para>If one block hits, the other misses --> counted |
| 203 | as one miss.</para> |
| 204 | </listitem> |
| 205 | <listitem> |
| 206 | <para>If both blocks miss --> counted as one miss (not |
| 207 | two)</para> |
| 208 | </listitem> |
| 209 | </itemizedlist> |
| 210 | </listitem> |
| 211 | |
| 212 | <listitem> |
| 213 | <para>Instructions that modify a memory location |
| 214 | (eg. <computeroutput>inc</computeroutput> and |
| 215 | <computeroutput>dec</computeroutput>) are counted as doing |
| 216 | just a read, ie. a single data reference. This may seem |
| 217 | strange, but since the write can never cause a miss (the read |
| 218 | guarantees the block is in the cache) it's not very |
| 219 | interesting.</para> |
| 220 | |
| 221 | <para>Thus it measures not the number of times the data cache |
| 222 | is accessed, but the number of times a data cache miss could |
| 223 | occur.</para> |
| 224 | </listitem> |
| 225 | |
| 226 | </itemizedlist> |
| 227 | |
| 228 | <para>If you are interested in simulating a cache with different |
| 229 | properties, it is not particularly hard to write your own cache |
| 230 | simulator, or to modify the existing ones in |
| 231 | <computeroutput>vg_cachesim_I1.c</computeroutput>, |
| 232 | <computeroutput>vg_cachesim_D1.c</computeroutput>, |
| 233 | <computeroutput>vg_cachesim_L2.c</computeroutput> and |
| 234 | <computeroutput>vg_cachesim_gen.c</computeroutput>. We'd be |
| 235 | interested to hear from anyone who does.</para> |
| 236 | |
| 237 | </sect2> |
| 238 | |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 239 | |
| 240 | <sect2 id="branch-sim" xreflabel="Branch simulation specifics"> |
| 241 | <title>Branch simulation specifics</title> |
| 242 | |
| 243 | <para>Cachegrind simulates branch predictors intended to be |
| 244 | typical of mainstream desktop/server processors of around 2004.</para> |
| 245 | |
| 246 | <para>Conditional branches are predicted using an array of 16384 2-bit |
| 247 | saturating counters. The array index used for a branch instruction is |
| 248 | computed partly from the low-order bits of the branch instruction's |
| 249 | address and partly using the taken/not-taken behaviour of the last few |
| 250 | conditional branches. As a result the predictions for any specific |
| 251 | branch depend both on its own history and the behaviour of previous |
| 252 | branches. This is a standard technique for improving prediction |
| 253 | accuracy.</para> |
| 254 | |
| 255 | <para>For indirect branches (that is, jumps to unknown destinations) |
| 256 | Cachegrind uses a simple branch target address predictor. Targets are |
| 257 | predicted using an array of 512 entries indexed by the low order 9 |
| 258 | bits of the branch instruction's address. Each branch is predicted to |
| 259 | jump to the same address it did last time. Any other behaviour causes |
| 260 | a mispredict.</para> |
| 261 | |
| 262 | <para>More recent processors have better branch predictors, in |
| 263 | particular better indirect branch predictors. Cachegrind's predictor |
| 264 | design is deliberately conservative so as to be representative of the |
| 265 | large installed base of processors which pre-date widespread |
| 266 | deployment of more sophisticated indirect branch predictors. In |
| 267 | particular, late model Pentium 4s (Prescott), Pentium M, Core and Core |
| 268 | 2 have more sophisticated indirect branch predictors than modelled by |
| 269 | Cachegrind. </para> |
| 270 | |
| 271 | <para>Cachegrind does not simulate a return stack predictor. It |
| 272 | assumes that processors perfectly predict function return addresses, |
| 273 | an assumption which is probably close to being true.</para> |
| 274 | |
| 275 | <para>See Hennessy and Patterson's classic text "Computer |
| 276 | Architecture: A Quantitative Approach", 4th edition (2007), Section |
| 277 | 2.3 (pages 80-89) for background on modern branch predictors.</para> |
| 278 | |
| 279 | </sect2> |
| 280 | |
| 281 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 282 | </sect1> |
| 283 | |
| 284 | |
| 285 | |
| 286 | <sect1 id="cg-manual.profile" xreflabel="Profiling programs"> |
| 287 | <title>Profiling programs</title> |
| 288 | |
| 289 | <para>To gather cache profiling information about the program |
| 290 | <computeroutput>ls -l</computeroutput>, invoke Cachegrind like |
| 291 | this:</para> |
| 292 | |
| 293 | <programlisting><![CDATA[ |
| 294 | valgrind --tool=cachegrind ls -l]]></programlisting> |
| 295 | |
| 296 | <para>The program will execute (slowly). Upon completion, |
| 297 | summary statistics that look like this will be printed:</para> |
| 298 | |
| 299 | <programlisting><![CDATA[ |
| 300 | ==31751== I refs: 27,742,716 |
| 301 | ==31751== I1 misses: 276 |
| 302 | ==31751== L2 misses: 275 |
| 303 | ==31751== I1 miss rate: 0.0% |
| 304 | ==31751== L2i miss rate: 0.0% |
| 305 | ==31751== |
| 306 | ==31751== D refs: 15,430,290 (10,955,517 rd + 4,474,773 wr) |
| 307 | ==31751== D1 misses: 41,185 ( 21,905 rd + 19,280 wr) |
| 308 | ==31751== L2 misses: 23,085 ( 3,987 rd + 19,098 wr) |
| 309 | ==31751== D1 miss rate: 0.2% ( 0.1% + 0.4%) |
| 310 | ==31751== L2d miss rate: 0.1% ( 0.0% + 0.4%) |
| 311 | ==31751== |
| 312 | ==31751== L2 misses: 23,360 ( 4,262 rd + 19,098 wr) |
| 313 | ==31751== L2 miss rate: 0.0% ( 0.0% + 0.4%)]]></programlisting> |
| 314 | |
| 315 | <para>Cache accesses for instruction fetches are summarised |
| 316 | first, giving the number of fetches made (this is the number of |
| 317 | instructions executed, which can be useful to know in its own |
| 318 | right), the number of I1 misses, and the number of L2 instruction |
| 319 | (<computeroutput>L2i</computeroutput>) misses.</para> |
| 320 | |
| 321 | <para>Cache accesses for data follow. The information is similar |
| 322 | to that of the instruction fetches, except that the values are |
| 323 | also shown split between reads and writes (note each row's |
| 324 | <computeroutput>rd</computeroutput> and |
| 325 | <computeroutput>wr</computeroutput> values add up to the row's |
| 326 | total).</para> |
| 327 | |
| 328 | <para>Combined instruction and data figures for the L2 cache |
| 329 | follow that.</para> |
| 330 | |
| 331 | |
| 332 | |
| 333 | <sect2 id="cg-manual.outputfile" xreflabel="Output file"> |
| 334 | <title>Output file</title> |
| 335 | |
| 336 | <para>As well as printing summary information, Cachegrind also |
sewardj | e1216cb | 2007-02-07 19:55:30 +0000 | [diff] [blame] | 337 | writes line-by-line cache profiling information to a user-specified |
| 338 | file. By default this file is named |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 339 | <computeroutput>cachegrind.out.pid</computeroutput>. This file |
sewardj | e1216cb | 2007-02-07 19:55:30 +0000 | [diff] [blame] | 340 | is human-readable, but is intended to be interpreted by the accompanying |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 341 | program <computeroutput>cg_annotate</computeroutput>, described |
| 342 | in the next section.</para> |
| 343 | |
| 344 | <para>Things to note about the |
| 345 | <computeroutput>cachegrind.out.pid</computeroutput> |
| 346 | file:</para> |
| 347 | |
| 348 | <itemizedlist> |
| 349 | <listitem> |
| 350 | <para>It is written every time Cachegrind is run, and will |
| 351 | overwrite any existing |
| 352 | <computeroutput>cachegrind.out.pid</computeroutput> |
| 353 | in the current directory (but that won't happen very often |
| 354 | because it takes some time for process ids to be |
| 355 | recycled).</para> |
sewardj | e1216cb | 2007-02-07 19:55:30 +0000 | [diff] [blame] | 356 | <para> |
| 357 | To use a basename other than the default |
sewardj | 8693e01 | 2007-02-08 06:47:19 +0000 | [diff] [blame] | 358 | <computeroutput>cachegrind.out</computeroutput>, |
sewardj | e1216cb | 2007-02-07 19:55:30 +0000 | [diff] [blame] | 359 | use the <computeroutput>--cachegrind-out-file</computeroutput> |
| 360 | switch.</para> |
| 361 | <para> |
| 362 | To add further qualifiers to the output filename you can use |
| 363 | the core's <computeroutput>--log-file-qualifier</computeroutput> |
sewardj | 8693e01 | 2007-02-08 06:47:19 +0000 | [diff] [blame] | 364 | flag. This extends the file name further with the text |
| 365 | <computeroutput>.lfq.</computeroutput>followed by the |
| 366 | contents of the environment variable specified by |
| 367 | <computeroutput>--log-file-qualifier</computeroutput>. |
| 368 | </para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 369 | </listitem> |
| 370 | <listitem> |
| 371 | <para>It can be huge: <computeroutput>ls -l</computeroutput> |
| 372 | generates a file of about 350KB. Browsing a few files and |
| 373 | web pages with a Konqueror built with full debugging |
| 374 | information generates a file of around 15 MB.</para> |
| 375 | </listitem> |
| 376 | </itemizedlist> |
| 377 | |
sewardj | 8d9fec5 | 2005-11-15 20:56:23 +0000 | [diff] [blame] | 378 | <para>The <computeroutput>.pid</computeroutput> suffix |
de | 7e109d1 | 2005-11-18 22:09:58 +0000 | [diff] [blame] | 379 | on the output file name serves two purposes. Firstly, it means you |
| 380 | don't have to rename old log files that you don't want to overwrite. |
| 381 | Secondly, and more importantly, it allows correct profiling with the |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 382 | <computeroutput>--trace-children=yes</computeroutput> option of |
| 383 | programs that spawn child processes.</para> |
| 384 | |
| 385 | </sect2> |
| 386 | |
| 387 | |
| 388 | |
| 389 | <sect2 id="cg-manual.cgopts" xreflabel="Cachegrind options"> |
| 390 | <title>Cachegrind options</title> |
| 391 | |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 392 | <!-- start of xi:include in the manpage --> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 393 | <para id="cg.opts.para">Using command line options, you can |
| 394 | manually specify the I1/D1/L2 cache |
| 395 | configuration to simulate. For each cache, you can specify the |
| 396 | size, associativity and line size. The size and line size |
| 397 | are measured in bytes. The three items |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 398 | must be comma-separated, but with no spaces, eg: |
| 399 | <literallayout> valgrind --tool=cachegrind --I1=65535,2,64</literallayout> |
| 400 | |
| 401 | You can specify one, two or three of the I1/D1/L2 caches. Any level not |
| 402 | manually specified will be simulated using the configuration found in |
| 403 | the normal way (via the CPUID instruction for automagic cache |
| 404 | configuration, or failing that, via defaults).</para> |
| 405 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 406 | <para>Cache-simulation specific options are:</para> |
| 407 | |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 408 | <variablelist id="cg.opts.list"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 409 | |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 410 | <varlistentry id="opt.I1" xreflabel="--I1"> |
| 411 | <term> |
| 412 | <option><![CDATA[--I1=<size>,<associativity>,<line size> ]]></option> |
| 413 | </term> |
| 414 | <listitem> |
| 415 | <para>Specify the size, associativity and line size of the level 1 |
| 416 | instruction cache. </para> |
| 417 | </listitem> |
| 418 | </varlistentry> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 419 | |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 420 | <varlistentry id="opt.D1" xreflabel="--D1"> |
| 421 | <term> |
| 422 | <option><![CDATA[--D1=<size>,<associativity>,<line size> ]]></option> |
| 423 | </term> |
| 424 | <listitem> |
| 425 | <para>Specify the size, associativity and line size of the level 1 |
| 426 | data cache.</para> |
| 427 | </listitem> |
| 428 | </varlistentry> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 429 | |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 430 | <varlistentry id="opt.L2" xreflabel="--L2"> |
| 431 | <term> |
| 432 | <option><![CDATA[--L2=<size>,<associativity>,<line size> ]]></option> |
| 433 | </term> |
| 434 | <listitem> |
| 435 | <para>Specify the size, associativity and line size of the level 2 |
| 436 | cache.</para> |
| 437 | </listitem> |
| 438 | </varlistentry> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 439 | |
sewardj | e1216cb | 2007-02-07 19:55:30 +0000 | [diff] [blame] | 440 | <varlistentry id="opt.cachegrind-out-file" xreflabel="--cachegrind-out-file"> |
| 441 | <term> |
| 442 | <option><![CDATA[--cachegrind-out-file=<basename> ]]></option> |
| 443 | </term> |
| 444 | <listitem> |
sewardj | 8693e01 | 2007-02-08 06:47:19 +0000 | [diff] [blame] | 445 | <para>Write the profile data to |
| 446 | <computeroutput>basename.pid</computeroutput> |
sewardj | e1216cb | 2007-02-07 19:55:30 +0000 | [diff] [blame] | 447 | rather than to the default output file, |
sewardj | 8693e01 | 2007-02-08 06:47:19 +0000 | [diff] [blame] | 448 | <computeroutput>cachegrind.out.pid</computeroutput>. |
sewardj | e1216cb | 2007-02-07 19:55:30 +0000 | [diff] [blame] | 449 | </para> |
| 450 | </listitem> |
| 451 | </varlistentry> |
| 452 | |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 453 | <varlistentry id="opt.cache-sim" xreflabel="--cache-sim"> |
| 454 | <term> |
| 455 | <option><![CDATA[--cache-sim=no|yes [yes] ]]></option> |
| 456 | </term> |
| 457 | <listitem> |
| 458 | <para>Enables or disables collection of cache access and miss |
| 459 | counts.</para> |
| 460 | </listitem> |
| 461 | </varlistentry> |
| 462 | |
| 463 | <varlistentry id="opt.branch-sim" xreflabel="--branch-sim"> |
| 464 | <term> |
| 465 | <option><![CDATA[--branch-sim=no|yes [no] ]]></option> |
| 466 | </term> |
| 467 | <listitem> |
| 468 | <para>Enables or disables collection of branch instruction and |
| 469 | misprediction counts. By default this is disabled as it |
| 470 | slows Cachegrind down by approximately 25%. Note that you |
| 471 | cannot specify <computeroutput>--cache-sim=no</computeroutput> |
| 472 | and <computeroutput>--branch-sim=no</computeroutput> |
| 473 | together, as that would leave Cachegrind with no |
| 474 | information to collect.</para> |
| 475 | </listitem> |
| 476 | </varlistentry> |
| 477 | |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 478 | </variablelist> |
| 479 | <!-- end of xi:include in the manpage --> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 480 | |
| 481 | </sect2> |
| 482 | |
| 483 | |
| 484 | |
| 485 | <sect2 id="cg-manual.annotate" xreflabel="Annotating C/C++ programs"> |
| 486 | <title>Annotating C/C++ programs</title> |
| 487 | |
| 488 | <para>Before using <computeroutput>cg_annotate</computeroutput>, |
| 489 | it is worth widening your window to be at least 120-characters |
| 490 | wide if possible, as the output lines can be quite long.</para> |
| 491 | |
| 492 | <para>To get a function-by-function summary, run |
| 493 | <computeroutput>cg_annotate --pid</computeroutput> in a directory |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 494 | containing a <filename>cachegrind.out.pid</filename> file. The |
| 495 | <emphasis>--pid</emphasis> is required so that |
| 496 | <computeroutput>cg_annotate</computeroutput> knows which log file to use |
| 497 | when several are present.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 498 | |
| 499 | <para>The output looks like this:</para> |
| 500 | |
| 501 | <programlisting><![CDATA[ |
| 502 | -------------------------------------------------------------------------------- |
| 503 | I1 cache: 65536 B, 64 B, 2-way associative |
| 504 | D1 cache: 65536 B, 64 B, 2-way associative |
| 505 | L2 cache: 262144 B, 64 B, 8-way associative |
| 506 | Command: concord vg_to_ucode.c |
| 507 | Events recorded: Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw |
| 508 | Events shown: Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw |
| 509 | Event sort order: Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw |
| 510 | Threshold: 99% |
| 511 | Chosen for annotation: |
| 512 | Auto-annotation: on |
| 513 | |
| 514 | -------------------------------------------------------------------------------- |
| 515 | Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw |
| 516 | -------------------------------------------------------------------------------- |
| 517 | 27,742,716 276 275 10,955,517 21,905 3,987 4,474,773 19,280 19,098 PROGRAM TOTALS |
| 518 | |
| 519 | -------------------------------------------------------------------------------- |
| 520 | Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw file:function |
| 521 | -------------------------------------------------------------------------------- |
| 522 | 8,821,482 5 5 2,242,702 1,621 73 1,794,230 0 0 getc.c:_IO_getc |
| 523 | 5,222,023 4 4 2,276,334 16 12 875,959 1 1 concord.c:get_word |
| 524 | 2,649,248 2 2 1,344,810 7,326 1,385 . . . vg_main.c:strcmp |
| 525 | 2,521,927 2 2 591,215 0 0 179,398 0 0 concord.c:hash |
| 526 | 2,242,740 2 2 1,046,612 568 22 448,548 0 0 ctype.c:tolower |
| 527 | 1,496,937 4 4 630,874 9,000 1,400 279,388 0 0 concord.c:insert |
| 528 | 897,991 51 51 897,831 95 30 62 1 1 ???:??? |
| 529 | 598,068 1 1 299,034 0 0 149,517 0 0 ../sysdeps/generic/lockfile.c:__flockfile |
| 530 | 598,068 0 0 299,034 0 0 149,517 0 0 ../sysdeps/generic/lockfile.c:__funlockfile |
| 531 | 598,024 4 4 213,580 35 16 149,506 0 0 vg_clientmalloc.c:malloc |
| 532 | 446,587 1 1 215,973 2,167 430 129,948 14,057 13,957 concord.c:add_existing |
| 533 | 341,760 2 2 128,160 0 0 128,160 0 0 vg_clientmalloc.c:vg_trap_here_WRAPPER |
| 534 | 320,782 4 4 150,711 276 0 56,027 53 53 concord.c:init_hash_table |
| 535 | 298,998 1 1 106,785 0 0 64,071 1 1 concord.c:create |
| 536 | 149,518 0 0 149,516 0 0 1 0 0 ???:tolower@@GLIBC_2.0 |
| 537 | 149,518 0 0 149,516 0 0 1 0 0 ???:fgetc@@GLIBC_2.0 |
| 538 | 95,983 4 4 38,031 0 0 34,409 3,152 3,150 concord.c:new_word_node |
| 539 | 85,440 0 0 42,720 0 0 21,360 0 0 vg_clientmalloc.c:vg_bogus_epilogue]]></programlisting> |
| 540 | |
| 541 | |
| 542 | <para>First up is a summary of the annotation options:</para> |
| 543 | |
| 544 | <itemizedlist> |
| 545 | |
| 546 | <listitem> |
| 547 | <para>I1 cache, D1 cache, L2 cache: cache configuration. So |
| 548 | you know the configuration with which these results were |
| 549 | obtained.</para> |
| 550 | </listitem> |
| 551 | |
| 552 | <listitem> |
| 553 | <para>Command: the command line invocation of the program |
| 554 | under examination.</para> |
| 555 | </listitem> |
| 556 | |
| 557 | <listitem> |
| 558 | <para>Events recorded: event abbreviations are:</para> |
| 559 | <itemizedlist> |
| 560 | <listitem> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 561 | <para><computeroutput>Ir</computeroutput>: I cache reads |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 562 | (ie. instructions executed)</para> |
| 563 | </listitem> |
| 564 | <listitem> |
| 565 | <para><computeroutput>I1mr</computeroutput>: I1 cache read |
| 566 | misses</para> |
| 567 | </listitem> |
| 568 | <listitem> |
| 569 | <para><computeroutput>I2mr</computeroutput>: L2 cache |
| 570 | instruction read misses</para> |
| 571 | </listitem> |
| 572 | <listitem> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 573 | <para><computeroutput>Dr</computeroutput>: D cache reads |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 574 | (ie. memory reads)</para> |
| 575 | </listitem> |
| 576 | <listitem> |
| 577 | <para><computeroutput>D1mr</computeroutput>: D1 cache read |
| 578 | misses</para> |
| 579 | </listitem> |
| 580 | <listitem> |
| 581 | <para><computeroutput>D2mr</computeroutput>: L2 cache data |
| 582 | read misses</para> |
| 583 | </listitem> |
| 584 | <listitem> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 585 | <para><computeroutput>Dw</computeroutput>: D cache writes |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 586 | (ie. memory writes)</para> |
| 587 | </listitem> |
| 588 | <listitem> |
| 589 | <para><computeroutput>D1mw</computeroutput>: D1 cache write |
| 590 | misses</para> |
| 591 | </listitem> |
| 592 | <listitem> |
| 593 | <para><computeroutput>D2mw</computeroutput>: L2 cache data |
| 594 | write misses</para> |
| 595 | </listitem> |
sewardj | 8badbaa | 2007-05-08 09:20:25 +0000 | [diff] [blame] | 596 | <listitem> |
| 597 | <para><computeroutput>Bc</computeroutput>: Conditional branches |
| 598 | executed</para> |
| 599 | </listitem> |
| 600 | <listitem> |
| 601 | <para><computeroutput>Bcm</computeroutput>: Conditional branches |
| 602 | mispredicted</para> |
| 603 | </listitem> |
| 604 | <listitem> |
| 605 | <para><computeroutput>Bi</computeroutput>: Indirect branches |
| 606 | executed</para> |
| 607 | </listitem> |
| 608 | <listitem> |
| 609 | <para><computeroutput>Bim</computeroutput>: Conditional branches |
| 610 | mispredicted</para> |
| 611 | </listitem> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 612 | </itemizedlist> |
| 613 | |
| 614 | <para>Note that D1 total accesses is given by |
| 615 | <computeroutput>D1mr</computeroutput> + |
| 616 | <computeroutput>D1mw</computeroutput>, and that L2 total |
| 617 | accesses is given by <computeroutput>I2mr</computeroutput> + |
| 618 | <computeroutput>D2mr</computeroutput> + |
| 619 | <computeroutput>D2mw</computeroutput>.</para> |
| 620 | </listitem> |
| 621 | |
| 622 | <listitem> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 623 | <para>Events shown: the events shown, which is a subset of the events |
| 624 | gathered. This can be adjusted with the |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 625 | <computeroutput>--show</computeroutput> option.</para> |
| 626 | </listitem> |
| 627 | |
| 628 | <listitem> |
| 629 | <para>Event sort order: the sort order in which functions are |
| 630 | shown. For example, in this case the functions are sorted |
| 631 | from highest <computeroutput>Ir</computeroutput> counts to |
| 632 | lowest. If two functions have identical |
| 633 | <computeroutput>Ir</computeroutput> counts, they will then be |
| 634 | sorted by <computeroutput>I1mr</computeroutput> counts, and |
| 635 | so on. This order can be adjusted with the |
| 636 | <computeroutput>--sort</computeroutput> option.</para> |
| 637 | |
| 638 | <para>Note that this dictates the order the functions appear. |
| 639 | It is <command>not</command> the order in which the columns |
| 640 | appear; that is dictated by the "events shown" line (and can |
| 641 | be changed with the <computeroutput>--show</computeroutput> |
| 642 | option).</para> |
| 643 | </listitem> |
| 644 | |
| 645 | <listitem> |
| 646 | <para>Threshold: <computeroutput>cg_annotate</computeroutput> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 647 | by default omits functions that cause very low counts |
| 648 | to avoid drowning you in information. In this case, |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 649 | cg_annotate shows summaries the functions that account for |
| 650 | 99% of the <computeroutput>Ir</computeroutput> counts; |
| 651 | <computeroutput>Ir</computeroutput> is chosen as the |
| 652 | threshold event since it is the primary sort event. The |
| 653 | threshold can be adjusted with the |
| 654 | <computeroutput>--threshold</computeroutput> |
| 655 | option.</para> |
| 656 | </listitem> |
| 657 | |
| 658 | <listitem> |
| 659 | <para>Chosen for annotation: names of files specified |
| 660 | manually for annotation; in this case none.</para> |
| 661 | </listitem> |
| 662 | |
| 663 | <listitem> |
| 664 | <para>Auto-annotation: whether auto-annotation was requested |
| 665 | via the <computeroutput>--auto=yes</computeroutput> |
| 666 | option. In this case no.</para> |
| 667 | </listitem> |
| 668 | |
| 669 | </itemizedlist> |
| 670 | |
| 671 | <para>Then follows summary statistics for the whole |
| 672 | program. These are similar to the summary provided when running |
de | 03e0e7c | 2005-12-03 23:02:33 +0000 | [diff] [blame] | 673 | <computeroutput>valgrind --tool=cachegrind</computeroutput>.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 674 | |
| 675 | <para>Then follows function-by-function statistics. Each function |
| 676 | is identified by a |
| 677 | <computeroutput>file_name:function_name</computeroutput> pair. If |
| 678 | a column contains only a dot it means the function never performs |
| 679 | that event (eg. the third row shows that |
| 680 | <computeroutput>strcmp()</computeroutput> contains no |
| 681 | instructions that write to memory). The name |
| 682 | <computeroutput>???</computeroutput> is used if the the file name |
| 683 | and/or function name could not be determined from debugging |
| 684 | information. If most of the entries have the form |
| 685 | <computeroutput>???:???</computeroutput> the program probably |
| 686 | wasn't compiled with <computeroutput>-g</computeroutput>. If any |
| 687 | code was invalidated (either due to self-modifying code or |
| 688 | unloading of shared objects) its counts are aggregated into a |
| 689 | single cost centre written as |
| 690 | <computeroutput>(discarded):(discarded)</computeroutput>.</para> |
| 691 | |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 692 | <para>It is worth noting that functions will come both from |
| 693 | the profiled program (eg. <filename>concord.c</filename>) |
| 694 | and from libraries (eg. <filename>getc.c</filename>)</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 695 | |
| 696 | <para>There are two ways to annotate source files -- by choosing |
| 697 | them manually, or with the |
| 698 | <computeroutput>--auto=yes</computeroutput> option. To do it |
| 699 | manually, just specify the filenames as arguments to |
| 700 | <computeroutput>cg_annotate</computeroutput>. For example, the |
| 701 | output from running <filename>cg_annotate concord.c</filename> |
| 702 | for our example produces the same output as above followed by an |
| 703 | annotated version of <filename>concord.c</filename>, a section of |
| 704 | which looks like:</para> |
| 705 | |
| 706 | <programlisting><![CDATA[ |
| 707 | -------------------------------------------------------------------------------- |
| 708 | -- User-annotated source: concord.c |
| 709 | -------------------------------------------------------------------------------- |
| 710 | Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw |
| 711 | |
| 712 | [snip] |
| 713 | |
| 714 | . . . . . . . . . void init_hash_table(char *file_name, Word_Node *table[]) |
| 715 | 3 1 1 . . . 1 0 0 { |
| 716 | . . . . . . . . . FILE *file_ptr; |
| 717 | . . . . . . . . . Word_Info *data; |
| 718 | 1 0 0 . . . 1 1 1 int line = 1, i; |
| 719 | . . . . . . . . . |
| 720 | 5 0 0 . . . 3 0 0 data = (Word_Info *) create(sizeof(Word_Info)); |
| 721 | . . . . . . . . . |
| 722 | 4,991 0 0 1,995 0 0 998 0 0 for (i = 0; i < TABLE_SIZE; i++) |
| 723 | 3,988 1 1 1,994 0 0 997 53 52 table[i] = NULL; |
| 724 | . . . . . . . . . |
| 725 | . . . . . . . . . /* Open file, check it. */ |
| 726 | 6 0 0 1 0 0 4 0 0 file_ptr = fopen(file_name, "r"); |
| 727 | 2 0 0 1 0 0 . . . if (!(file_ptr)) { |
| 728 | . . . . . . . . . fprintf(stderr, "Couldn't open '%s'.\n", file_name); |
| 729 | 1 1 1 . . . . . . exit(EXIT_FAILURE); |
| 730 | . . . . . . . . . } |
| 731 | . . . . . . . . . |
| 732 | 165,062 1 1 73,360 0 0 91,700 0 0 while ((line = get_word(data, line, file_ptr)) != EOF) |
| 733 | 146,712 0 0 73,356 0 0 73,356 0 0 insert(data->;word, data->line, table); |
| 734 | . . . . . . . . . |
| 735 | 4 0 0 1 0 0 2 0 0 free(data); |
| 736 | 4 0 0 1 0 0 2 0 0 fclose(file_ptr); |
| 737 | 3 0 0 2 0 0 . . . }]]></programlisting> |
| 738 | |
| 739 | <para>(Although column widths are automatically minimised, a wide |
| 740 | terminal is clearly useful.)</para> |
| 741 | |
| 742 | <para>Each source file is clearly marked |
| 743 | (<computeroutput>User-annotated source</computeroutput>) as |
| 744 | having been chosen manually for annotation. If the file was |
| 745 | found in one of the directories specified with the |
| 746 | <computeroutput>-I / --include</computeroutput> option, the directory |
| 747 | and file are both given.</para> |
| 748 | |
| 749 | <para>Each line is annotated with its event counts. Events not |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 750 | applicable for a line are represented by a dot. This is useful |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 751 | for distinguishing between an event which cannot happen, and one |
| 752 | which can but did not.</para> |
| 753 | |
| 754 | <para>Sometimes only a small section of a source file is |
sewardj | 8d9fec5 | 2005-11-15 20:56:23 +0000 | [diff] [blame] | 755 | executed. To minimise uninteresting output, Cachegrind only shows |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 756 | annotated lines and lines within a small distance of annotated |
| 757 | lines. Gaps are marked with the line numbers so you know which |
| 758 | part of a file the shown code comes from, eg:</para> |
| 759 | |
| 760 | <programlisting><![CDATA[ |
| 761 | (figures and code for line 704) |
| 762 | -- line 704 ---------------------------------------- |
| 763 | -- line 878 ---------------------------------------- |
| 764 | (figures and code for line 878)]]></programlisting> |
| 765 | |
| 766 | <para>The amount of context to show around annotated lines is |
| 767 | controlled by the <computeroutput>--context</computeroutput> |
| 768 | option.</para> |
| 769 | |
| 770 | <para>To get automatic annotation, run |
| 771 | <computeroutput>cg_annotate --auto=yes</computeroutput>. |
| 772 | cg_annotate will automatically annotate every source file it can |
| 773 | find that is mentioned in the function-by-function summary. |
| 774 | Therefore, the files chosen for auto-annotation are affected by |
| 775 | the <computeroutput>--sort</computeroutput> and |
| 776 | <computeroutput>--threshold</computeroutput> options. Each |
| 777 | source file is clearly marked (<computeroutput>Auto-annotated |
| 778 | source</computeroutput>) as being chosen automatically. Any |
| 779 | files that could not be found are mentioned at the end of the |
| 780 | output, eg:</para> |
| 781 | |
| 782 | <programlisting><![CDATA[ |
| 783 | ------------------------------------------------------------------ |
| 784 | The following files chosen for auto-annotation could not be found: |
| 785 | ------------------------------------------------------------------ |
| 786 | getc.c |
| 787 | ctype.c |
| 788 | ../sysdeps/generic/lockfile.c]]></programlisting> |
| 789 | |
| 790 | <para>This is quite common for library files, since libraries are |
| 791 | usually compiled with debugging information, but the source files |
| 792 | are often not present on a system. If a file is chosen for |
| 793 | annotation <command>both</command> manually and automatically, it |
| 794 | is marked as <computeroutput>User-annotated |
| 795 | source</computeroutput>. Use the <computeroutput>-I / |
| 796 | --include</computeroutput> option to tell Valgrind where to look |
| 797 | for source files if the filenames found from the debugging |
| 798 | information aren't specific enough.</para> |
| 799 | |
| 800 | <para>Beware that cg_annotate can take some time to digest large |
| 801 | <computeroutput>cachegrind.out.pid</computeroutput> files, |
| 802 | e.g. 30 seconds or more. Also beware that auto-annotation can |
| 803 | produce a lot of output if your program is large!</para> |
| 804 | |
| 805 | </sect2> |
| 806 | |
| 807 | |
| 808 | <sect2 id="cg-manual.assembler" xreflabel="Annotating assembler programs"> |
| 809 | <title>Annotating assembler programs</title> |
| 810 | |
| 811 | <para>Valgrind can annotate assembler programs too, or annotate |
| 812 | the assembler generated for your C program. Sometimes this is |
| 813 | useful for understanding what is really happening when an |
| 814 | interesting line of C code is translated into multiple |
| 815 | instructions.</para> |
| 816 | |
| 817 | <para>To do this, you just need to assemble your |
| 818 | <computeroutput>.s</computeroutput> files with assembler-level |
| 819 | debug information. gcc doesn't do this, but you can use the GNU |
| 820 | assembler with the <computeroutput>--gstabs</computeroutput> |
| 821 | option to generate object files with this information, eg:</para> |
| 822 | |
| 823 | <programlisting><![CDATA[ |
| 824 | as --gstabs foo.s]]></programlisting> |
| 825 | |
| 826 | <para>You can then profile and annotate source files in the same |
| 827 | way as for C/C++ programs.</para> |
| 828 | |
| 829 | </sect2> |
| 830 | |
| 831 | </sect1> |
| 832 | |
| 833 | |
| 834 | <sect1 id="cg-manual.annopts" xreflabel="cg_annotate options"> |
| 835 | <title><computeroutput>cg_annotate</computeroutput> options</title> |
| 836 | |
| 837 | <itemizedlist> |
| 838 | |
de | bc32e82 | 2005-06-25 14:43:05 +0000 | [diff] [blame] | 839 | <listitem id="pid"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 840 | <para><computeroutput>--pid</computeroutput></para> |
sewardj | 8693e01 | 2007-02-08 06:47:19 +0000 | [diff] [blame] | 841 | <para>Indicates that profile data should be read from |
| 842 | the file |
| 843 | <computeroutput>cachegrind.out.pid</computeroutput>. |
| 844 | read. |
| 845 | Note that you must specify either |
| 846 | <computeroutput>--pid</computeroutput> |
| 847 | or <computeroutput>--cachegrind-out-file=filename</computeroutput> |
| 848 | exactly once. |
| 849 | </para> |
| 850 | </listitem> |
| 851 | |
| 852 | <listitem id="cachegrind-out-file"> |
| 853 | <para><computeroutput>--cachegrind-out-file=filename</computeroutput></para> |
| 854 | <para>Indicates that profile data |
| 855 | should be read from <computeroutput>filename</computeroutput>. |
| 856 | Note that you must specify either |
| 857 | <computeroutput>--pid</computeroutput> |
| 858 | or <computeroutput>--cachegrind-out-file=filename</computeroutput> |
| 859 | exactly once. |
| 860 | </para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 861 | </listitem> |
| 862 | |
| 863 | <listitem> |
| 864 | <para><computeroutput>-h, --help</computeroutput></para> |
| 865 | <para><computeroutput>-v, --version</computeroutput></para> |
| 866 | <para>Help and version, as usual.</para> |
| 867 | </listitem> |
| 868 | |
de | bc32e82 | 2005-06-25 14:43:05 +0000 | [diff] [blame] | 869 | <listitem id="sort"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 870 | <para><computeroutput>--sort=A,B,C</computeroutput> [default: |
| 871 | order in |
| 872 | <computeroutput>cachegrind.out.pid</computeroutput>]</para> |
| 873 | <para>Specifies the events upon which the sorting of the |
| 874 | function-by-function entries will be based. Useful if you |
| 875 | want to concentrate on eg. I cache misses |
| 876 | (<computeroutput>--sort=I1mr,I2mr</computeroutput>), or D |
| 877 | cache misses |
| 878 | (<computeroutput>--sort=D1mr,D2mr</computeroutput>), or L2 |
| 879 | misses |
| 880 | (<computeroutput>--sort=D2mr,I2mr</computeroutput>).</para> |
| 881 | </listitem> |
| 882 | |
de | bc32e82 | 2005-06-25 14:43:05 +0000 | [diff] [blame] | 883 | <listitem id="show"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 884 | <para><computeroutput>--show=A,B,C</computeroutput> [default: |
| 885 | all, using order in |
| 886 | <computeroutput>cachegrind.out.pid</computeroutput>]</para> |
| 887 | <para>Specifies which events to show (and the column |
| 888 | order). Default is to use all present in the |
| 889 | <computeroutput>cachegrind.out.pid</computeroutput> file (and |
| 890 | use the order in the file).</para> |
| 891 | </listitem> |
| 892 | |
de | bc32e82 | 2005-06-25 14:43:05 +0000 | [diff] [blame] | 893 | <listitem id="threshold"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 894 | <para><computeroutput>--threshold=X</computeroutput> |
| 895 | [default: 99%]</para> |
| 896 | <para>Sets the threshold for the function-by-function |
| 897 | summary. Functions are shown that account for more than X% |
| 898 | of the primary sort event. If auto-annotating, also affects |
| 899 | which files are annotated.</para> |
| 900 | |
| 901 | <para>Note: thresholds can be set for more than one of the |
| 902 | events by appending any events for the |
| 903 | <computeroutput>--sort</computeroutput> option with a colon |
| 904 | and a number (no spaces, though). E.g. if you want to see |
| 905 | the functions that cover 99% of L2 read misses and 99% of L2 |
| 906 | write misses, use this option:</para> |
| 907 | <para><computeroutput>--sort=D2mr:99,D2mw:99</computeroutput></para> |
| 908 | </listitem> |
| 909 | |
de | bc32e82 | 2005-06-25 14:43:05 +0000 | [diff] [blame] | 910 | <listitem id="auto"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 911 | <para><computeroutput>--auto=no</computeroutput> [default]</para> |
| 912 | <para><computeroutput>--auto=yes</computeroutput></para> |
| 913 | <para>When enabled, automatically annotates every file that |
| 914 | is mentioned in the function-by-function summary that can be |
| 915 | found. Also gives a list of those that couldn't be found.</para> |
| 916 | </listitem> |
| 917 | |
de | bc32e82 | 2005-06-25 14:43:05 +0000 | [diff] [blame] | 918 | <listitem id="context"> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 919 | <para><computeroutput>--context=N</computeroutput> [default: |
| 920 | 8]</para> |
| 921 | <para>Print N lines of context before and after each |
| 922 | annotated line. Avoids printing large sections of source |
| 923 | files that were not executed. Use a large number |
| 924 | (eg. 10,000) to show all source lines.</para> |
| 925 | </listitem> |
| 926 | |
de | bc32e82 | 2005-06-25 14:43:05 +0000 | [diff] [blame] | 927 | <listitem id="include"> |
sewardj | 8d9fec5 | 2005-11-15 20:56:23 +0000 | [diff] [blame] | 928 | <para><computeroutput>-I<dir>, |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 929 | --include=<dir></computeroutput> [default: empty |
| 930 | string]</para> |
| 931 | <para>Adds a directory to the list in which to search for |
| 932 | files. Multiple -I/--include options can be given to add |
| 933 | multiple directories.</para> |
| 934 | </listitem> |
| 935 | |
| 936 | </itemizedlist> |
| 937 | |
| 938 | |
| 939 | |
| 940 | <sect2> |
| 941 | <title>Warnings</title> |
| 942 | |
| 943 | <para>There are a couple of situations in which |
| 944 | <computeroutput>cg_annotate</computeroutput> issues |
| 945 | warnings.</para> |
| 946 | |
| 947 | <itemizedlist> |
| 948 | <listitem> |
| 949 | <para>If a source file is more recent than the |
| 950 | <computeroutput>cachegrind.out.pid</computeroutput> file. |
| 951 | This is because the information in |
| 952 | <computeroutput>cachegrind.out.pid</computeroutput> is only |
| 953 | recorded with line numbers, so if the line numbers change at |
| 954 | all in the source (eg. lines added, deleted, swapped), any |
| 955 | annotations will be incorrect.</para> |
| 956 | </listitem> |
| 957 | <listitem> |
| 958 | <para>If information is recorded about line numbers past the |
| 959 | end of a file. This can be caused by the above problem, |
| 960 | ie. shortening the source file while using an old |
| 961 | <computeroutput>cachegrind.out.pid</computeroutput> file. If |
| 962 | this happens, the figures for the bogus lines are printed |
| 963 | anyway (clearly marked as bogus) in case they are |
| 964 | important.</para> |
| 965 | </listitem> |
| 966 | </itemizedlist> |
| 967 | |
| 968 | </sect2> |
| 969 | |
| 970 | |
| 971 | |
| 972 | <sect2> |
| 973 | <title>Things to watch out for</title> |
| 974 | |
| 975 | <para>Some odd things that can occur during annotation:</para> |
| 976 | |
| 977 | <itemizedlist> |
| 978 | <listitem> |
| 979 | <para>If annotating at the assembler level, you might see |
| 980 | something like this:</para> |
| 981 | <programlisting><![CDATA[ |
| 982 | 1 0 0 . . . . . . leal -12(%ebp),%eax |
| 983 | 1 0 0 . . . 1 0 0 movl %eax,84(%ebx) |
| 984 | 2 0 0 0 0 0 1 0 0 movl $1,-20(%ebp) |
| 985 | . . . . . . . . . .align 4,0x90 |
| 986 | 1 0 0 . . . . . . movl $.LnrB,%eax |
| 987 | 1 0 0 . . . 1 0 0 movl %eax,-16(%ebp)]]></programlisting> |
| 988 | |
| 989 | <para>How can the third instruction be executed twice when |
| 990 | the others are executed only once? As it turns out, it |
| 991 | isn't. Here's a dump of the executable, using |
| 992 | <computeroutput>objdump -d</computeroutput>:</para> |
| 993 | <programlisting><![CDATA[ |
| 994 | 8048f25: 8d 45 f4 lea 0xfffffff4(%ebp),%eax |
| 995 | 8048f28: 89 43 54 mov %eax,0x54(%ebx) |
| 996 | 8048f2b: c7 45 ec 01 00 00 00 movl $0x1,0xffffffec(%ebp) |
| 997 | 8048f32: 89 f6 mov %esi,%esi |
| 998 | 8048f34: b8 08 8b 07 08 mov $0x8078b08,%eax |
| 999 | 8048f39: 89 45 f0 mov %eax,0xfffffff0(%ebp)]]></programlisting> |
| 1000 | |
| 1001 | <para>Notice the extra <computeroutput>mov |
| 1002 | %esi,%esi</computeroutput> instruction. Where did this come |
| 1003 | from? The GNU assembler inserted it to serve as the two |
| 1004 | bytes of padding needed to align the <computeroutput>movl |
| 1005 | $.LnrB,%eax</computeroutput> instruction on a four-byte |
| 1006 | boundary, but pretended it didn't exist when adding debug |
| 1007 | information. Thus when Valgrind reads the debug info it |
| 1008 | thinks that the <computeroutput>movl |
| 1009 | $0x1,0xffffffec(%ebp)</computeroutput> instruction covers the |
| 1010 | address range 0x8048f2b--0x804833 by itself, and attributes |
| 1011 | the counts for the <computeroutput>mov |
| 1012 | %esi,%esi</computeroutput> to it.</para> |
| 1013 | </listitem> |
| 1014 | |
| 1015 | <listitem> |
| 1016 | <para>Inlined functions can cause strange results in the |
| 1017 | function-by-function summary. If a function |
| 1018 | <computeroutput>inline_me()</computeroutput> is defined in |
| 1019 | <filename>foo.h</filename> and inlined in the functions |
| 1020 | <computeroutput>f1()</computeroutput>, |
| 1021 | <computeroutput>f2()</computeroutput> and |
| 1022 | <computeroutput>f3()</computeroutput> in |
| 1023 | <filename>bar.c</filename>, there will not be a |
| 1024 | <computeroutput>foo.h:inline_me()</computeroutput> function |
| 1025 | entry. Instead, there will be separate function entries for |
| 1026 | each inlining site, ie. |
| 1027 | <computeroutput>foo.h:f1()</computeroutput>, |
| 1028 | <computeroutput>foo.h:f2()</computeroutput> and |
| 1029 | <computeroutput>foo.h:f3()</computeroutput>. To find the |
| 1030 | total counts for |
| 1031 | <computeroutput>foo.h:inline_me()</computeroutput>, add up |
| 1032 | the counts from each entry.</para> |
| 1033 | |
| 1034 | <para>The reason for this is that although the debug info |
| 1035 | output by gcc indicates the switch from |
| 1036 | <filename>bar.c</filename> to <filename>foo.h</filename>, it |
| 1037 | doesn't indicate the name of the function in |
| 1038 | <filename>foo.h</filename>, so Valgrind keeps using the old |
| 1039 | one.</para> |
| 1040 | </listitem> |
| 1041 | |
| 1042 | <listitem> |
| 1043 | <para>Sometimes, the same filename might be represented with |
| 1044 | a relative name and with an absolute name in different parts |
| 1045 | of the debug info, eg: |
| 1046 | <filename>/home/user/proj/proj.h</filename> and |
| 1047 | <filename>../proj.h</filename>. In this case, if you use |
| 1048 | auto-annotation, the file will be annotated twice with the |
| 1049 | counts split between the two.</para> |
| 1050 | </listitem> |
| 1051 | |
| 1052 | <listitem> |
| 1053 | <para>Files with more than 65,535 lines cause difficulties |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 1054 | for the Stabs-format debug info reader. This is because the line |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1055 | number in the <computeroutput>struct nlist</computeroutput> |
| 1056 | defined in <filename>a.out.h</filename> under Linux is only a |
| 1057 | 16-bit value. Valgrind can handle some files with more than |
| 1058 | 65,535 lines correctly by making some guesses to identify |
| 1059 | line number overflows. But some cases are beyond it, in |
| 1060 | which case you'll get a warning message explaining that |
| 1061 | annotations for the file might be incorrect.</para> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 1062 | |
| 1063 | <para>If you are using gcc 3.1 or later, this is most likely |
| 1064 | irrelevant, since gcc switched to using the more modern DWARF2 |
| 1065 | format by default at version 3.1. DWARF2 does not have any such |
| 1066 | limitations on line numbers.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1067 | </listitem> |
| 1068 | |
| 1069 | <listitem> |
| 1070 | <para>If you compile some files with |
| 1071 | <computeroutput>-g</computeroutput> and some without, some |
| 1072 | events that take place in a file without debug info could be |
| 1073 | attributed to the last line of a file with debug info |
| 1074 | (whichever one gets placed before the non-debug-info file in |
| 1075 | the executable).</para> |
| 1076 | </listitem> |
| 1077 | |
| 1078 | </itemizedlist> |
| 1079 | |
| 1080 | <para>This list looks long, but these cases should be fairly |
| 1081 | rare.</para> |
| 1082 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1083 | </sect2> |
| 1084 | |
| 1085 | |
| 1086 | |
| 1087 | <sect2> |
| 1088 | <title>Accuracy</title> |
| 1089 | |
| 1090 | <para>Valgrind's cache profiling has a number of |
| 1091 | shortcomings:</para> |
| 1092 | |
| 1093 | <itemizedlist> |
| 1094 | <listitem> |
| 1095 | <para>It doesn't account for kernel activity -- the effect of |
| 1096 | system calls on the cache contents is ignored.</para> |
| 1097 | </listitem> |
| 1098 | |
| 1099 | <listitem> |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 1100 | <para>It doesn't account for other process activity. |
| 1101 | This is probably desirable when considering a single |
| 1102 | program.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1103 | </listitem> |
| 1104 | |
| 1105 | <listitem> |
| 1106 | <para>It doesn't account for virtual-to-physical address |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 1107 | mappings. Hence the simulation is not a true |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1108 | representation of what's happening in the |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 1109 | cache. Most caches are physically indexed, but Cachegrind |
| 1110 | simulates caches using virtual addresses.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1111 | </listitem> |
| 1112 | |
| 1113 | <listitem> |
| 1114 | <para>It doesn't account for cache misses not visible at the |
| 1115 | instruction level, eg. those arising from TLB misses, or |
| 1116 | speculative execution.</para> |
| 1117 | </listitem> |
| 1118 | |
| 1119 | <listitem> |
sewardj | 8d9fec5 | 2005-11-15 20:56:23 +0000 | [diff] [blame] | 1120 | <para>Valgrind will schedule |
| 1121 | threads differently from how they would be when running natively. |
| 1122 | This could warp the results for threaded programs.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1123 | </listitem> |
| 1124 | |
| 1125 | <listitem> |
sewardj | 8d9fec5 | 2005-11-15 20:56:23 +0000 | [diff] [blame] | 1126 | <para>The x86/amd64 instructions <computeroutput>bts</computeroutput>, |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1127 | <computeroutput>btr</computeroutput> and |
| 1128 | <computeroutput>btc</computeroutput> will incorrectly be |
| 1129 | counted as doing a data read if both the arguments are |
| 1130 | registers, eg:</para> |
| 1131 | <programlisting><![CDATA[ |
| 1132 | btsl %eax, %edx]]></programlisting> |
| 1133 | |
| 1134 | <para>This should only happen rarely.</para> |
| 1135 | </listitem> |
| 1136 | |
| 1137 | <listitem> |
sewardj | 8d9fec5 | 2005-11-15 20:56:23 +0000 | [diff] [blame] | 1138 | <para>x86/amd64 FPU instructions with data sizes of 28 and 108 bytes |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1139 | (e.g. <computeroutput>fsave</computeroutput>) are treated as |
| 1140 | though they only access 16 bytes. These instructions seem to |
| 1141 | be rare so hopefully this won't affect accuracy much.</para> |
| 1142 | </listitem> |
| 1143 | |
| 1144 | </itemizedlist> |
| 1145 | |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 1146 | <para>Another thing worth noting is that results are very sensitive. |
| 1147 | Changing the size of the the executable being profiled, or the sizes |
| 1148 | of any of the shared libraries it uses, or even the length of their |
| 1149 | file names, can perturb the results. Variations will be small, but |
| 1150 | don't expect perfectly repeatable results if your program changes at |
| 1151 | all.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1152 | |
sewardj | 08e31e2 | 2007-05-23 21:58:33 +0000 | [diff] [blame] | 1153 | <para>More recent GNU/Linux distributions do address space |
| 1154 | randomisation, in which identical runs of the same program have their |
| 1155 | shared libraries loaded at different locations, as a security measure. |
| 1156 | This also perturbs the results.</para> |
sewardj | 94dc508 | 2007-02-08 11:31:03 +0000 | [diff] [blame] | 1157 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1158 | <para>While these factors mean you shouldn't trust the results to |
| 1159 | be super-accurate, hopefully they should be close enough to be |
| 1160 | useful.</para> |
| 1161 | |
| 1162 | </sect2> |
| 1163 | |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1164 | </sect1> |
| 1165 | |
sewardj | 94dc508 | 2007-02-08 11:31:03 +0000 | [diff] [blame] | 1166 | |
| 1167 | |
| 1168 | <sect1 id="cg-manual.cg_merge" xreflabel="cg_merge"> |
| 1169 | <title>Merging profiles with <computeroutput>cg_merge</computeroutput></title> |
| 1170 | |
| 1171 | <para> |
| 1172 | <computeroutput>cg_merge</computeroutput> is a simple program which |
| 1173 | reads multiple profile files, as created by cachegrind, merges them |
| 1174 | together, and writes the results into another file in the same format. |
| 1175 | You can then examine the merged results using |
| 1176 | <computeroutput>cg_annotate |
| 1177 | --cachegrind-out-file=outputfile</computeroutput>, as |
| 1178 | described above. The merging functionality might be useful if you |
| 1179 | want to aggregate costs over multiple runs of the same program, or |
| 1180 | from a single parallel run with multiple instances of the same |
| 1181 | program.</para> |
| 1182 | |
| 1183 | <para> |
| 1184 | <computeroutput>cg_merge</computeroutput> is invoked as follows: |
| 1185 | </para> |
| 1186 | |
| 1187 | <programlisting><![CDATA[ |
| 1188 | cg_merge -o outputfile file1 file2 file3 ...]]></programlisting> |
| 1189 | |
| 1190 | <para> |
| 1191 | It reads and checks <computeroutput>file1</computeroutput>, then read |
| 1192 | and checks <computeroutput>file2</computeroutput> and merges it into |
| 1193 | the running totals, then the same with |
| 1194 | <computeroutput>file3</computeroutput>, etc. The final results are |
| 1195 | written to <computeroutput>outputfile</computeroutput>, or to standard |
| 1196 | out if no output file is specified.</para> |
| 1197 | |
| 1198 | <para> |
| 1199 | Costs are summed on a per-function, per-line and per-instruction |
| 1200 | basis. Because of this, the order in which the input files does not |
| 1201 | matter, although you should take care to only mention each file once, |
| 1202 | since any file mentioned twice will be added in twice.</para> |
| 1203 | |
| 1204 | <para> |
| 1205 | <computeroutput>cg_merge</computeroutput> does not attempt to check |
| 1206 | that the input files come from runs of the same executable. It will |
| 1207 | happily merge together profile files from completely unrelated |
| 1208 | programs. It does however check that the |
| 1209 | <computeroutput>Events:</computeroutput> lines of all the inputs are |
| 1210 | identical, so as to ensure that the addition of costs makes sense. |
| 1211 | For example, it would be nonsensical for it to add a number indicating |
| 1212 | D1 read references to a number from a different file indicating L2 |
| 1213 | write misses.</para> |
| 1214 | |
| 1215 | <para> |
| 1216 | A number of other syntax and sanity checks are done whilst reading the |
| 1217 | inputs. <computeroutput>cg_merge</computeroutput> will stop and |
| 1218 | attempt to print a helpful error message if any of the input files |
| 1219 | fail these checks.</para> |
| 1220 | |
| 1221 | </sect1> |
| 1222 | |
| 1223 | |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1224 | <sect1> |
| 1225 | <title>Acting on Cachegrind's information</title> |
| 1226 | <para> |
| 1227 | So, you've managed to profile your program with Cachegrind. Now what? |
| 1228 | What's the best way to actually act on the information it provides to speed |
njn | 07f9656 | 2007-09-17 22:28:21 +0000 | [diff] [blame] | 1229 | up your program? Here are some rules of thumb that we have found to be |
| 1230 | useful.</para> |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1231 | |
| 1232 | <para> |
| 1233 | First of all, the global hit/miss rate numbers are not that useful. If you |
| 1234 | have multiple programs or multiple runs of a program, comparing the numbers |
njn | 07f9656 | 2007-09-17 22:28:21 +0000 | [diff] [blame] | 1235 | might identify if any are outliers and worthy of closer investigation. |
| 1236 | Otherwise, they're not enough to act on.</para> |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1237 | |
| 1238 | <para> |
njn | 07f9656 | 2007-09-17 22:28:21 +0000 | [diff] [blame] | 1239 | The line-by-line source code annotations are much more useful. In our |
| 1240 | experience, the best place to start is by looking at the |
| 1241 | <computeroutput>Ir</computeroutput> numbers. They simply measure how many |
| 1242 | instructions were executed for each line, and don't include any cache |
| 1243 | information, but they can still be very useful for identifying |
| 1244 | bottlenecks.</para> |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1245 | |
| 1246 | <para> |
| 1247 | After that, we have found that L2 misses are typically a much bigger source |
| 1248 | of slow-downs than L1 misses. So it's worth looking for any snippets of |
njn | 07f9656 | 2007-09-17 22:28:21 +0000 | [diff] [blame] | 1249 | code that cause a high proportion of the L2 misses. If you find any, it's |
| 1250 | still not always easy to work out how to improve things. You need to have a |
| 1251 | reasonable understanding of how caches work, the principles of locality, and |
| 1252 | your program's data access patterns. Improving things may require |
| 1253 | redesigning a data structure, for example.</para> |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1254 | |
| 1255 | <para> |
| 1256 | In short, Cachegrind can tell you where some of the bottlenecks in your code |
| 1257 | are, but it can't tell you how to fix them. You have to work that out for |
| 1258 | yourself. But at least you have the information! |
| 1259 | </para> |
| 1260 | |
| 1261 | </sect1> |
sewardj | 94dc508 | 2007-02-08 11:31:03 +0000 | [diff] [blame] | 1262 | |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1263 | <sect1> |
| 1264 | <title>Implementation details</title> |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1265 | <para> |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1266 | This section talks about details you don't need to know about in order to |
| 1267 | use Cachegrind, but may be of interest to some people. |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1268 | </para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1269 | |
| 1270 | <sect2> |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1271 | <title>How Cachegrind works</title> |
| 1272 | <para>The best reference for understanding how Cachegrind works is chapter 3 of |
| 1273 | "Dynamic Binary Analysis and Instrumentation", by Nicholas Nethercote. It |
njn | 011215f | 2006-10-21 23:00:59 +0000 | [diff] [blame] | 1274 | is available on the <ulink url="&vg-pubs;">Valgrind publications |
| 1275 | page</ulink>.</para> |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1276 | </sect2> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1277 | |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1278 | <sect2> |
| 1279 | <title>Cachegrind output file format</title> |
| 1280 | <para>The file format is fairly straightforward, basically giving the |
| 1281 | cost centre for every line, grouped by files and |
| 1282 | functions. Total counts (eg. total cache accesses, total L1 |
| 1283 | misses) are calculated when traversing this structure rather than |
| 1284 | during execution, to save time; the cache simulation functions |
| 1285 | are called so often that even one or two extra adds can make a |
| 1286 | sizeable difference.</para> |
| 1287 | |
| 1288 | <para>The file format:</para> |
| 1289 | <programlisting><![CDATA[ |
| 1290 | file ::= desc_line* cmd_line events_line data_line+ summary_line |
| 1291 | desc_line ::= "desc:" ws? non_nl_string |
| 1292 | cmd_line ::= "cmd:" ws? cmd |
| 1293 | events_line ::= "events:" ws? (event ws)+ |
| 1294 | data_line ::= file_line | fn_line | count_line |
| 1295 | file_line ::= "fl=" filename |
| 1296 | fn_line ::= "fn=" fn_name |
| 1297 | count_line ::= line_num ws? (count ws)+ |
| 1298 | summary_line ::= "summary:" ws? (count ws)+ |
| 1299 | count ::= num | "."]]></programlisting> |
| 1300 | |
| 1301 | <para>Where:</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1302 | <itemizedlist> |
| 1303 | <listitem> |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1304 | <para><computeroutput>non_nl_string</computeroutput> is any |
| 1305 | string not containing a newline.</para> |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1306 | </listitem> |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1307 | <listitem> |
| 1308 | <para><computeroutput>cmd</computeroutput> is a string holding the |
| 1309 | command line of the profiled program.</para> |
| 1310 | </listitem> |
| 1311 | <listitem> |
njn | 2624212 | 2007-01-22 03:21:27 +0000 | [diff] [blame] | 1312 | <para><computeroutput>event</computeroutput> is a string containing |
| 1313 | no whitespace.</para> |
| 1314 | </listitem> |
| 1315 | <listitem> |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1316 | <para><computeroutput>filename</computeroutput> and |
| 1317 | <computeroutput>fn_name</computeroutput> are strings.</para> |
| 1318 | </listitem> |
| 1319 | <listitem> |
| 1320 | <para><computeroutput>num</computeroutput> and |
| 1321 | <computeroutput>line_num</computeroutput> are decimal |
| 1322 | numbers.</para> |
| 1323 | </listitem> |
| 1324 | <listitem> |
| 1325 | <para><computeroutput>ws</computeroutput> is whitespace.</para> |
| 1326 | </listitem> |
| 1327 | </itemizedlist> |
| 1328 | |
| 1329 | <para>The contents of the "desc:" lines are printed out at the top |
| 1330 | of the summary. This is a generic way of providing simulation |
| 1331 | specific information, eg. for giving the cache configuration for |
| 1332 | cache simulation.</para> |
| 1333 | |
| 1334 | <para>More than one line of info can be presented for each file/fn/line number. |
| 1335 | In such cases, the counts for the named events will be accumulated.</para> |
| 1336 | |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1337 | <para>Counts can be "." to represent zero. This makes the files easier for |
| 1338 | humans to read.</para> |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1339 | |
| 1340 | <para>The number of counts in each |
| 1341 | <computeroutput>line</computeroutput> and the |
| 1342 | <computeroutput>summary_line</computeroutput> should not exceed |
| 1343 | the number of events in the |
| 1344 | <computeroutput>event_line</computeroutput>. If the number in |
| 1345 | each <computeroutput>line</computeroutput> is less, cg_annotate |
njn | 3a9d5dc | 2007-09-17 22:19:01 +0000 | [diff] [blame] | 1346 | treats those missing as though they were a "." entry. This saves space. |
| 1347 | </para> |
njn | 534f781 | 2006-10-21 22:22:59 +0000 | [diff] [blame] | 1348 | |
| 1349 | <para>A <computeroutput>file_line</computeroutput> changes the |
| 1350 | current file name. A <computeroutput>fn_line</computeroutput> |
| 1351 | changes the current function name. A |
| 1352 | <computeroutput>count_line</computeroutput> contains counts that |
| 1353 | pertain to the current filename/fn_name. A "fn=" |
| 1354 | <computeroutput>file_line</computeroutput> and a |
| 1355 | <computeroutput>fn_line</computeroutput> must appear before any |
| 1356 | <computeroutput>count_line</computeroutput>s to give the context |
| 1357 | of the first <computeroutput>count_line</computeroutput>s.</para> |
| 1358 | |
| 1359 | <para>Each <computeroutput>file_line</computeroutput> will normally be |
| 1360 | immediately followed by a <computeroutput>fn_line</computeroutput>. But it |
| 1361 | doesn't have to be.</para> |
| 1362 | |
njn | 3e986b2 | 2004-11-30 10:43:45 +0000 | [diff] [blame] | 1363 | |
| 1364 | </sect2> |
| 1365 | |
| 1366 | </sect1> |
| 1367 | </chapter> |