|
From: Dallman, J. <joh...@si...> - 2014-02-12 13:53:21
|
I'm looking at using callgrind to replace an expensive Windows coverage tool, and for some other work where the ideas are only part-formed. The default callgrind run and callgrind_annonate display shows Ir events, but I only need to count function entries. Is there a way to only collect those and have callgrind run faster?? callgrind_annotate has the --show option to only show specific events, but I can't find a list of event names to feed it. Where should I be looking? To explain a bit, the reason I only need function entries is that we collect coverage data on a per-function basis, for all our test cases, and then use that to discover which test cases we need to run for changes to a given set of functions. The other task consists of trying to find the most-called functions, because on a different platform, I am having to use a compiler option that adds a small constant overhead to some, but not all, functions. If I can discover the most-called functions, I can then find out if they are having the overhead added by the compiler, and then try to revise them so that the compiler no longer needs to do that. thanks, -- John Dallman ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. |
|
From: Julian S. <js...@ac...> - 2014-02-12 16:56:22
|
(guessing at both questions; JosefW would know for definite) > The default callgrind run and callgrind_annonate display shows Ir events, but > I only need to count function entries. Is there a way to only collect those > and have callgrind run faster?? I suspect not. In any case counting insns is not terribly expensive, so the gain you'd get would be modest. > callgrind_annotate has the --show option to only show specific events, but I > can't find a list of event names to feed it. Where should I be looking? I suspect the names are present in the callgrind.out file, and so callgrind_annotate just slices out those that you list. It doesn't itself know the names. But what part of the .c files of callgrind generates the names, I have no idea. J |
|
From: Dallman, J. <joh...@si...> - 2014-02-12 17:00:47
|
Julian Seward wrote: > I suspect not. In any case counting insns is not terribly expensive, > so the gain you'd get would be modest. OK. > I suspect the names are present in the callgrind.out file, and so > callgrind_annotate just slices out those that you list. It doesn't > itself know the names. But what part of the .c files of callgrind > generates the names, I have no idea. The only usage of the word "event" in the callgrind.out file, apart from the names of functions that happen to include "event", is in the header: $ more callgrind.out.xyz version: 1 creator: callgrind-3.8.1 pid: 7926 cmd: xxxx.xxx part: 1 desc: I1 cache: desc: D1 cache: desc: LL cache: desc: Timerange: Basic block 0 - 699103124 desc: Trigger: Program termination positions: line events: Ir summary: 4496324814 ob=(2) ??? fl=(2) ??? fn=(302) 0x00000000053fecd8 0 2 cob=(8) /lib64/libdl-2.11.1.so cfi=(8) ??? cfn=(304) 0x0000000000000df0 calls=1 0 ... That doesn't look as if there are any other events present, unless they're called something different. I realise I've jumped to the conclusion that calls are events, and this might not be true. I guess I can write something to digest the .out file and produce call counts from it. thanks, -- John Dallman ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. |
|
From: Philippe W. <phi...@sk...> - 2014-02-12 18:03:13
|
On Wed, 2014-02-12 at 17:00 +0000, Dallman, John wrote: > That doesn't look as if there are any other events present, unless > they're > called something different. I realise I've jumped to the conclusion > that > calls are events, and this might not be true. > > I guess I can write something to digest the .out file and produce call > counts from it. Starting callgrind with default options, and then using kcachegrind on the resulting callgrind.out file, kcachegrind shows the nr of calls to the functions. callgrind_annotate --tree=both seems also to give the nr of calls. Philippe |
|
From: Josef W. <Jos...@gm...> - 2014-02-12 19:46:07
|
Am 12.02.2014 14:52, schrieb Dallman, John: > I'm looking at using callgrind to replace an expensive Windows coverage tool, > and for some other work where the ideas are only part-formed. > > The default callgrind run and callgrind_annonate display shows Ir events, but > I only need to count function entries. Is there a way to only collect those > and have callgrind run faster?? As Julian said, it does not get faster by not collecting Ir events, as without cache simulation, callgrind only counts how often basic blocks where executed. The important task of callgrind is to increment counters for (caller site/called function) tuples, to build the call graph. This often involves hash table lookups. If you are only interested in call counts of functions, a specific tool for that may be a lot faster: just increment a counter whenever a basic block is executed that represents a function entry. > callgrind_annotate has the --show option to only show specific events, but I > can't find a list of event names to feed it. Where should I be looking? Julian is right: callgrind_annotate just takes it from the callgrind output. Events for "--show" are events that always can be related to some code. In contrast to that, call counts relate to (from,to) tuples of code positions, and are handled special: they have no specific name. E.g. do a grep for "Ir" in the callgrind directory, and you will see the string "Ir" in sim.c. Depending on the mode callgrind is running in, different sets of event names are registered. Josef > To explain a bit, the reason I only need function entries is that we collect > coverage data on a per-function basis, for all our test cases, and then use > that to discover which test cases we need to run for changes to a given set > of functions. > > The other task consists of trying to find the most-called functions, because > on a different platform, I am having to use a compiler option that adds a > small constant overhead to some, but not all, functions. If I can discover > the most-called functions, I can then find out if they are having the overhead > added by the compiler, and then try to revise them so that the compiler no > longer needs to do that. > > thanks, > > -- > John Dallman > > ----------------- > Siemens Industry Software Limited is a limited company registered in England and Wales. > Registered number: 3476850. > Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Josef W. <Jos...@gm...> - 2014-02-12 20:00:24
|
Am 12.02.2014 19:03, schrieb Philippe Waroquiers: > On Wed, 2014-02-12 at 17:00 +0000, Dallman, John wrote: >> That doesn't look as if there are any other events present, unless >> they're >> called something different. I realise I've jumped to the conclusion >> that >> calls are events, and this might not be true. Yes. Call counts are special. All "regular" events are listed after "events:" in the header of callgrind.out. >> I guess I can write something to digest the .out file and produce call >> counts from it. > Starting callgrind with default options, > and then using kcachegrind on the resulting callgrind.out file, > kcachegrind shows the nr of calls to the functions. > > callgrind_annotate --tree=both > seems also to give the nr of calls. --tree=caller shows the callers of each function, with the call count in parenthesis. Hmm. It should be easy to show the summed up call count for each function also without callers/callee display. Josef > > Philippe > > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Dallman, J. <joh...@si...> - 2014-02-13 09:18:13
|
Philippe Waroquiers <phi...@sk...> wrote: > Starting callgrind with default options, and then using > kcachegrind on the resulting callgrind.out file, kcachegrind > shows the nr of calls to the functions. I'm trying to avoid using kcachegrind, because I need to automate this process. We have tens of thousands of test cases we'll want to feed through this and requiring human interaction is thus bad. Josef Weidendorfer [mailto:Jos...@gm...] wrote: > Yes. Call counts are special. Aha. > --tree=caller shows the callers of each function, with the call > count in parenthesis. Yup, and that output looks a lot easier to parse than the full callgrind output. I have something odd in the output, though: I have a lot of calls to functions with names that I recognise, but which have a '2 appended to their names. These don't exist in the source: any idea what they signify? 8,658,501 < ???:read__list'2 (5826x) [kid.out] 128,976,260 < ???:read_sub_list'2 (158404x) [kid.out] 2,107 < ???:relax'2 (43x) [kid.out] 2,416,508 < ???:REL_gen_external'2 (437x) [kid.out] > Hmm. It should be easy to show the summed up call count for each > function also without callers/callee display. That would be nice if it could be added easily. thanks, everyone, -- John Dallman ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. |
|
From: Dallman, J. <joh...@si...> - 2014-02-13 10:39:35
|
> I have a lot of calls to functions with names that I recognise, > but which have a '2 appended to their names. These don't exist > in the source: any idea what they signify? They're in the callgrind documentation; they're about recursion, and I clearly need to accumulate their call counts into those for the basic function. Thanks, Julian. -- John Dallman ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. |