From: Nicholas Nethercote Date: Mon, 17 Sep 2007 22:28:21 +0000 (+0000) Subject: Add a section to the cachegrind manual suggesting how to act on the results. X-Git-Tag: svn/VALGRIND_3_3_0~209 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c7a4bb81a51eaa8b45fa0b9a646c12a7415fdfb9;p=thirdparty%2Fvalgrind.git Add a section to the cachegrind manual suggesting how to act on the results. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6853 --- diff --git a/cachegrind/docs/cg-manual.xml b/cachegrind/docs/cg-manual.xml index 60d5622bcb..2a643ecc06 100644 --- a/cachegrind/docs/cg-manual.xml +++ b/cachegrind/docs/cg-manual.xml @@ -1226,28 +1226,31 @@ fail these checks. So, you've managed to profile your program with Cachegrind. Now what? What's the best way to actually act on the information it provides to speed -up your program? +up your program? Here are some rules of thumb that we have found to be +useful. First of all, the global hit/miss rate numbers are not that useful. If you have multiple programs or multiple runs of a program, comparing the numbers -might identify if any are outliers. Otherwise, they're not enough to act -on. +might identify if any are outliers and worthy of closer investigation. +Otherwise, they're not enough to act on. -The source code annotations are much more useful. In our experience, the -best place to start is by looking at the Ir -numbers. They simply measure how many instructions were executed for each -line, and don't include any cache information, but they can still be very -useful for identifying bottlenecks. +The line-by-line source code annotations are much more useful. In our +experience, the best place to start is by looking at the +Ir numbers. They simply measure how many +instructions were executed for each line, and don't include any cache +information, but they can still be very useful for identifying +bottlenecks. After that, we have found that L2 misses are typically a much bigger source of slow-downs than L1 misses. So it's worth looking for any snippets of -code that cause a lot of L2 misses. If you find any, it's still not always -easy to work out how to improve things. You need to have a reasonable -understanding of how caches work, the principles of locality, and your -program's data access patterns. +code that cause a high proportion of the L2 misses. If you find any, it's +still not always easy to work out how to improve things. You need to have a +reasonable understanding of how caches work, the principles of locality, and +your program's data access patterns. Improving things may require +redesigning a data structure, for example. In short, Cachegrind can tell you where some of the bottlenecks in your code