|
From: Josef W. <Jos...@gm...> - 2009-08-07 09:53:13
|
On Friday 07 August 2009, Nicholas Nethercote wrote: > On Fri, Aug 7, 2009 at 4:13 AM, <sv...@va...> wrote: > > Author: weidendo > > Date: 2009-08-06 19:13:17 +0100 (Thu, 06 Aug 2009) > > New Revision: 10729 > > > > Log: > > Added some text for --simulate-wb/--cacheuse options of Callgrind. > > > > For cacheuse, it actually got quite large... > > Hmm, interesting option. So the documentation seems to be understandable ;-) > Have you found it to be useful in practice? From an academic point of view, the results are very interesting. In practice, the values are very difficult to interprete. This is because of the (1) current problem of bogus - and therefore suppressed - inclusive costs, (2) potentially misleading current relation to the code position of the first cache line access only (relation to data structures would be way better), and (3) it is difficult to estimate the potential performance improvement you can get by getting rid of a problem pointed at by the cache use metrics. So yes, it is useful for more detailed analysis, especially if you want to check for the best layout of heavily used data structures. However, if you just run the cacheuse option on a regular huge program startup, you usually see all the hash accesses in the runtime linker because of symbol resolution. This is a little bit misleading, and is an effect of the above mentioned issues. BTW, (1) is an effect of the current determination of inclusive costs in Callgrind. For a function, it is given by the difference of global cost counters at leaving the function minus the (stored) counters at entering. However, cacheuse metrics are determined for a cache line at eviction time, and related to counters of a code position which was executed in the past. This simply is incompatible with the globally advancing counter idea for inclusive costs. > (Actually, I could ask the same question for a lot of Callgrind's > options :) Yeah, a lot of options grow out of the interest of how useful the option is in practice. Perhaps it would be a good idea to have a generic --exp=yes switch supported by Valgrind core and hide more esoteric options by default, similar to the exp- prefix of the experimental tools. Josef > > Nick > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |