-邮件原件-
发件人: Josef Weidendorfer [mailto:josef.weidendor...@gmx.de]
发送时间: 2017年5月20日 6:24
收件人: valgrind-users@lists.sourceforge.net
主题: Re: [Valgrind-users] hello there is a question about callgrind on the arm64.
Hi Owen,
callgrind currently is somewhat broken on ARM, as the tracking of
Hi Owen,
callgrind currently is somewhat broken on ARM, as the
tracking of entering/leaving functions is unreliable.
Callgrind heavily uses the stack pointer for that.
On x86, this works fine, as every call/return changes
the SP, but on ARM, this is not the case.
There are ideas and at some poin
easy to accomplish what you want.
Cheers,
Josef
commit c491556702cc3e6f6ebf34c838ce44c91ef9c259
Author: Josef Weidendorfer
Date: Thu Jun 11 16:13:36 2009 +0200
Parameter sensitive profiling
This works by creating a new fn_node with a name specifying the
parameter condit
Am 07.07.2016 um 14:59 schrieb E. G. Patrick Bos:
> I'm using callgrind to analyse a c++ program (roofit) which builds a
> large tree of many interdependent objects of a few classes. Ideally, I
> would like to track not only the function calls, but also from (and to)
> which object they are called,
Am 08.07.2016 um 01:03 schrieb Stepan Zakharov:
> Hello,
> If I remember correct, callgrind takes x30 overhead in general (when I
> was running it). Usually , I had to run it on small tasks that won't
> take more then a few minutes, so this was not a bother to me.
>
> But right now I am wonering if
Am 05.07.2016 um 03:22 schrieb Yang Liu:
> I'm trying to get a call graph where the edge weights are call times
> rather than instruction counts. I didn't find a clear documentation
> though. The closest I got is some mentioning of event type. But I don't
> see the event name for call times.
Call
Am 27.06.2016 um 18:08 schrieb Ana Rey:
> Is there a tool (like cg-merge) which can merge multiple callgrind
> output files into one
For {k,q}cachegrind, it's enough to 'cat' them together.
For the callgrind_annotate script, this unfortunately
does not work (the total sum calculation gets wrong).
Hi,
If you see a XXX'N in callgrind's output, this means that this is the
profile for all invocations of function XXX at recursion level N. For
level 1, suffix '1 is omitted. And there is one caveat: if you ask
callgrind to only distinguish n levels, XXX'n will include all
XXX'm with m > n.
If yo
gt; ==3047== D1 miss rate: 2.0% ( 2.4% +0.9% )
> ==3047== LLd miss rate: 1.8% ( 2.2% +0.8% )
> ==3047==
> ==3047== LL refs: 1,761 ( 1,616 rd +145 wr)
> ==3047== LL misses: 1,663 ( 1,528 rd +135 wr)
> ==3047== LL miss rate:
Am 15.02.2016 um 11:25 schrieb Mandy Martino:
> why
>
> I1 misses increase, LLi misses increase, LL misses increase, D1 misses
> increase
> though miss rate decrease at this row 0.1% + 0.0% ?
>
> which indicator show the correct number that can show the improvement
> after optimization
Am 18.12.2015 um 14:50 schrieb Rohit Takhar:
> Suppose I have a class |TEST| and there is a function |func()|. How can
> I restrict callgrind to get information about this function only. I know
> how to do it in C++, but it is not working in python.
> I tried following
> methods: |--toggle-collect=
Am 27.09.2015 um 20:02 schrieb Milian Wolff:
> On Freitag, 25. September 2015 20:27:45 CEST martin wrote:
>> Hello,
>>
>> I'm new to Cachegrind (and cache simulation in general).
>>
>> I'm trying to do a memory trace of my application, but only for
>> operations that go to DRAM, that is, only if th
Am 25.09.2015 um 22:27 schrieb martin:
> I'm trying to do a memory trace of my application, but only for
> operations that go to DRAM, that is, only if there was a LLC miss
> should I care. Is it possible to achieve that with Cachegrind? AFAICS,
> it only counts the number of events (and wher
Am 31.08.2015 um 17:10 schrieb Florian Krohm:
> On 28.08.2015 09:03, Josef Weidendorfer wrote:
>
>> This suggests we should document the difference between
>> START/STOP_INSTRUMENTAITON
>> and TOGGLE_COLLECT better.
>
> Hmm, yes :) Any chance you can write somethi
Am 27.08.2015 um 22:53 schrieb Philippe Waroquiers:
> E.g. I think that stop instrumentation implies to flush the translation
> cache. But the currently executed block will not be really flushed till
> the block is exited.
To my understanding, every client request forces a block to end. It is fine
Hi Geoff,
Am 27.08.2015 um 08:42 schrieb galexand...@nc.rr.com:
> I would like to count instructions for a specific part of my code.
> ...
This suggests we should document the difference between
START/STOP_INSTRUMENTAITON
and TOGGLE_COLLECT better. Anyway.
> for (int i = 1; i <= 1000; ++i)
here, if you can.
>
> Yours,
> Kay Hayen
>
>
> --
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
Dr. Josef Weidendorfer, Informatik, Technische Universität München
TUM I-
Am 29.05.2015 um 19:14 schrieb Dan Liew:
> There's [1]. It's not complete though,
It should be complete now in SVN :-)
Josef
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based networ
Am 29.05.2015 um 18:50 schrieb Rocky Bernstein:
> I'm looking into adding into the GNU make fork remake
> (http://bashdb.sf.net/remake) profiling using a callgrind file format.
Not sure I get the idea. Do you want to generate a callgrind file
for dependencies in Makefiles?
> Is there something th
Am 21.04.2015 um 11:35 schrieb rajsing mohapatro:
> This mail is to check if currently Valgrind provides any tool/option
> which can be utilized to do profiling of a running process to know what
> % of memory allocation made by the process is NUMA optimized.
Not that I know of.
However, physical
Whether such a thing can be supported by a tool of course depends on the
tool.
For memcheck, this obviously makes no sense. But yes, it could become a
VG core
feature and tools enable it if they can cope with.
E.g. for lackey, it also would work.
To not forget about it, can you add it as "wishlist
Am 18.02.2015 um 12:23 schrieb Azat Khuzhin:
> On Wed, Feb 18, 2015 at 11:56:51AM +0100, Josef Weidendorfer wrote:
>> Am 18.02.2015 um 11:02 schrieb Azat Khuzhin:
>>>> Does it work if you remove "-static"? I have no idea if Ubuntu provides
>>>> debug inf
Am 18.02.2015 um 11:02 schrieb Azat Khuzhin:
>> Does it work if you remove "-static"? I have no idea if Ubuntu provides
>> debug info for libc.a ...
>
> Debian do provides, so I guess that ubuntu too:
> libc6-dev: /usr/lib/x86_64-linux-gnu/libc.a
That file on Ubuntu 14.10 (I am running this here)
Am 17.02.2015 um 21:22 schrieb Raul Garcia:
> I am a new user, I am doing a "hello world" test of Valgrind but i keep
> hitting this error:
> ...
> 2,709 *???*:getenv [/home/otro/arm_emulator/hello_x86]
The "???" are not really any errors, but a sign that for these functions,
valgrind could not lo
d?
>
> Cheers,
> Raul.
>
> ____
> From: Josef Weidendorfer [josef.weidendor...@gmx.de]
> Sent: Tuesday, February 17, 2015 9:40 AM
> To: Raul Garcia; valgrind-users@lists.sourceforge.net
> Subject: Re: [Valgrind-users] Dump of opcode/mnemonic per code line
>
> Am 16.02.2
Am 16.02.2015 um 22:29 schrieb Raul Garcia:
> |That information is great, but is it possible to get the exact instructions
> (mnemonics) that where utilized/executed
> per each line like in the example below? This information would be really
> valuable to me.
In the instrument function you have
Am 02.02.2015 um 12:49 schrieb Christian Priebe:
> The same line repeats until I shutdown vgdb. Ok, running "vgdb --pid=XXX
> v.wait 500" without any tool (i.e. "valgrind bin/mysqld")
Without a tool specified, the default is memcheck.
> So, apparently this has nothing to do with callgrind but wit
Am 02.02.2015 um 00:00 schrieb Christian Priebe:
> I'm back to the previous issue that callgrind_control or more
> specifically vgdb hangs. This is the output I get when running vgdb -d
> ...
Hmm. Then it looks like a hang in the vgdb handler in callgrind, but I
have no idea why.
Can you first ch
Hi Steve,
> I'm looking for a way to answer the question 'how much of a cache line did I
> use before discarding it?'.
>
> ...
>
> g++ matrix.cpp -O0 -g
For performance analysis, you always should work with optimized code,
ie. "-O2 -g"
(actually, that doesn't change the data layout, so AcCost
Am 31.01.2015 um 14:49 schrieb Christian Priebe:
> Apparently callgrind_control hangs on a read system call waiting for
> some output from vgdb.
Since Valgrind 3.9 or 3.10, callgrind_control is just a wrapper around vgdb.
When mysql is running under callgrind, just call "vgdb -l" (sudo as needed).
Hi,
You found a very old version of KCachegrind web pages.
>From where did you get this URL? Via Google?
I need to remove them. Anyway, if you use
http://kcachegrind.sourceforge.net
the pages are quite up-to-date.
And as Milian said, of course you also can either use a distribution
package or
report.
"Wish list item" :-)
Josef
>
> Krzysztof
>
>
> On Mon, Nov 3, 2014 at 8:38 PM, Josef Weidendorfer
> mailto:josef.weidendor...@gmx.de>> wrote:
>
> Am 31.10.2014 um 16:46 schrieb Krzysztof Czarnowski:
> > Cachegrind's cache mode
Am 31.10.2014 um 16:46 schrieb Krzysztof Czarnowski:
> Cachegrind's cache mode is not very general and I wonder if it makes
> sense to use it on Quark to get at least approximate results on an
> application's cache performance. The Quark's cache is integrated (both
> instruction and data) single le
Am 26.09.2014 um 04:35 schrieb John Carter:
> I would assume then that
> followed_count <= total_count
> would always be true.
>
> This one liner
>
> find -name '*.callgrind' | xargs grep jcnd | ruby -nle 'p [$1, $2,$_] if
> ($_ =~ /jcnd=([0-9]+)\/([0-9]+)/) && ($1.to_i > $2.to_i)'
>
> .
Am 23.08.2014 um 14:56 schrieb Dan Liew:
>> The instruction address you specify below is always the same as the line
>> number. That makes not much sense. The instruction address is needed
>> for KCachegrind to show annotated machine code, using "objdump ",
>> but your example does not specify a bi
Am 22.08.2014 um 19:48 schrieb Dan Liew:
> The documentation [1] doesn't define these very clearly. The grammar
> for ``JumpSpecification`` doesn't seem to be specified properly.
Oops, indeed.
Thanks for the notification.
> * jump=count target position [Callgrind]
>
> Unconditional jump, execut
er/architecture is this?
Josef
>
> Olaf
>
>
> 2014-07-22 10:25 GMT+02:00 Josef Weidendorfer <mailto:josef.weidendor...@gmx.de>>:
>
> Hi Olaf,
>
> Am 21.07.2014 14 :48, schrieb Olaf Lenz:
> > Hi everybody!
> >
>
Hi Olaf,
Am 21.07.2014 14:48, schrieb Olaf Lenz:
> Hi everybody!
>
> I am trying to use callgrind (3.8.0) to profile our simulation software
> ESPResSo (http://espressomd.org) on Linux.
>
> Unfortunately, callgrind seems to loose the information on where to find
> the source files when running t
Am 07.07.2014 01:28, schrieb Jerry Scharf:
> Hi again,
>
> This is just such an awful thing to be doing but such are the cards I get
> handed.
>
> The program I am trying to measure the cache performance on is actually a
> win32 progran that I am running under wine on redhat linux. I thought fo
Am 04.07.2014 10:00, schrieb Josef Weidendorfer:
> However, if you have multithreaded code: cachegrind currently does not
> simulate shared L3 for multithreaded
> code, but expects the full hierarchy to be private for each thread.
Sorry, that's wrong.
Cachegrind only maintains one
Am 03.07.2014 19:22, schrieb Jerry Scharf:
> Tom and Josef,
>
> Thank you for your speedy responses.
>
> Is cachegrind an instrumentation of the real system or a simulation of the
> processor cache based on the code executed? From your responses, it sounds
> like the later.
Yes.
For the first
Am 03.07.2014 09:32, schrieb Tom Hughes:
> On 03/07/14 07:06, Jerry Scharf wrote:
>
>> Why is it insisting that the numbers be powers of 2? If I use --LL with the
>> real numbers it refuses to start. If I round these down to the next lower
>> power of 2 (16M and 16 associations) it doesn't compl
Hi Jin,
thanks, I can reproduce it.
This is a bug in KCachegrind, and not in callgrind itself.
For some reason, the caller/callee view does not correctly
recognize this as recursive function call. It simply should
leave the cost column empty.
Simple workaround: just ignore.
Josef
Am 11.05.20
Am 13.04.2014 13:37, schrieb Philippe Waroquiers:
> On Sun, 2014-04-06 at 19:29 -0700, janjust wrote:
>> Hi,
>>I'm trying to profile valgrind using perftools-lite and when compiling
>> the tools I get an undefined reference error.
>> VEX and coregrind build, but during linking it errs (error is
Am 12.02.2014 19:03, schrieb Philippe Waroquiers:
> On Wed, 2014-02-12 at 17:00 +, 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 m
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 funct
Am 19.01.2014 15:34, schrieb Philippe Waroquiers:
> On Sat, 2014-01-18 at 10:11 +0100, David Faure wrote:
>> On Friday 17 January 2014 12:36:32 Raghu Reddy wrote:
>>> My question is, how do I find the variable located at the address 0x420A080?
>>> The code was ready compiled with -g option, so I wa
Am 29.10.2013 03:27, schrieb Loi Luu:
> supports many useful tools. I'm thinking to use *Callgrind *to solve my
> problem, but I'm not sure whether its a right choice.
Callgrind does observe branch behavior, and counts how often
instructions from various branches are executed.
The source annotati
Am 04.10.2013 21:47, schrieb Sonny Tavernier:
> Hi,
>
> I have an unexpected behavior with a basic tool.
> For each Put statement of a basic block, I register a dirty helper using
> unsafeIRDirty_0_N.
> The problem is that the dirty helper is called more times than expected,
> e.g. there are 5
Am 24.04.2013 05:44, schrieb Liu James:
> Dear all,
>
> I used Valgrind(callgrind) to profile database cache performance, and
> the host machine is a VM guest with XEON CPU.
>
> Without instrumentation, the performance of dbms with cache-on is 20%
> higher
What do you mean by higher? Better or w
Am 23.04.2013 09:35, schrieb Mark Wielaard:
> On Tue, Apr 23, 2013 at 01:22:31PM +0800, Ice Frog wrote:
>> I use oprofile for performance profiling. I noticed that kcachegrind(more
>> specifically, op2callgrind or kcachegrind-converters) is able to analyze
>> information generated by oprofile.
>>
>
Am 19.04.2013 06:52, schrieb Mahmood Naderan:
> It seems that callgrind can not instrument a program that runs on top of
> another program.
This is not specific to callgrind.
By default, child processes of a process controlled by Valgrind will
not be run within Valgrind themself. If you want that
Am 18.04.2013 19:15, schrieb Mahmood Naderan:
> the -valgrind option will set
> valgrind --tool=callgrind --tool=memcheck -v --trace-children=yes
> in the command line.
The 2nd --tool option overrides the first, as you can not run multiple
tools at once.
Josef
Hi,
Am 26.03.2013 13:54, schrieb Farah Saab Gmail:
> I am using callgrind tool of valgrind to profile my running code.
> Then I am using kcachegrind to view the output. The problem is that my
> native code is already slow as it is. So running it through valgrind is
> making it even more slow. Acco
Am 13.03.2013 16:58, schrieb Farah Saab Gmail:
> Hello,
>
> How do I get the number of loops in a function shown in Kcachegrind?
> Is it enough to press the button "Cycle Detection"?
No, that is something totally different (it's about correct
calculation of inclusive costs, and that needs detectio
Am 11.03.2013 11:27, schrieb Farah Saab Gmail:
> I am new to valgrind. I need your advice on something. I ran my c++
> project using valgrind (cachegrind tool). I got an output file of the
> following format cachegrind.out.x
> Then I used the kcachegrind tool to read this file.
> I got the list of
Am 16.02.2013 14:11, schrieb Milian Wolff:
> On Saturday 16 February 2013 09:24:51 Ice Frog wrote:
>> Hi all,
>>
>> The website of kcachegrind http://kcachegrind.sourceforge.net/ is
>> inaccessible. How can I get the source code of kcachegrind (from
>> somewhere else)? thanks.
>
> Use svn://ano
Am 06.02.2013 10:21, schrieb Ice Frog:
> Hi folks,
>
> I have a simple question. I'm using Valgrind for database profiling. The
> db server is a daemon program, and it seems I can only do profiling by
> attaching Valgrind to the daemon.
Valgrind does not allow attaching to a running process.
With
Am 22.01.2013 12:46, schrieb Steph:
>> root@bt:~# ==1975==
>> ==1975== Error: can not open cache simulation output file
>> `/root/callgrind.out.1975'
>
> I also tried to do same thing under regular user from home directory and
> got the same result
You mean you get:
==1975== Error: can not open c
Am 15.01.2013 07:36, schrieb Steph:
> Hello everyone!
> Got strange problem while tracing nginx using callgrind.
>
> I'm running trace with next command:
>
> valgrind --trace-children=yes --tool=callgrind /usr/local/nginx/sbin/nginx
>
> And as result got
>
>
> root@bt:~# ==1975==
> ==1975== Error:
any I1 misses, you at least know that the "active code part" fits into
32kB, and there is nothing to improve in that regard.
Best,
Josef
>
> Thanks,
>
> Jason
>
> On Fri, Dec 7, 2012 at 3:06 PM, Josef Weidendorfer
> wrote:
>> Am 07.12.2012 20:46, schrieb Jason Pal
Am 07.12.2012 20:46, schrieb Jason Palaszewski:
> Hi, I'm trying to compare the number of cache misses (D1, I1, and LL)
> between what Perf gives me (on the hardware itself) vs. what
> Cachegrind thinks the number of misses should be. The server machine
> has two Sandy Bridge Intel Xeon E5-2430 CPU
Hi,
Am 03.12.2012 00:28, schrieb Siddharth Nilakantan:
> Curious question. How much is the slowdown of Callgrind over
> Cachegrind?
Callgrind unfortunately is quite a bit slower than cachegrind.
Reasons for this:
(1) for dynamic call-graph collection, every basic block (BB) first
calls into a C
Am 27.11.2012 08:48, schrieb Geoff Alexander:
> Josef Weidendorfer wrote on 11/19/2012
> > I just fixed that bug in SVN trunk.
>
> I tested with both Valgrind 3.8.1 and Valgrind SVN-13143 as well as
> retesting with the Valgrind 3.6.1 that comes with openSUSE 12.1. The
> S
Am 19.11.2012 11:38, schrieb Josef Weidendorfer:
> Hmm. I think I just found a bug here :(
I just fixed that bug in SVN trunk.
So if that was the issue you observed, can you
check current SVN?
Josef
--
Monitor y
Am 18.11.2012 06:40, schrieb Geoff Alexander:
> I've recently been looking at Callgrind and Cachegrind output. I've
> found that both tools generate an Ir count. From what I've found in the
> Valgrind documentation and on the Web, the Ir count is the number of
> instructions executed (instruction
Am 05.11.2012 01:49, schrieb Wonjoon Song:
> Hello all,
>
> In the lackey example, there is instrument function like
>
> static VG_REGPARM(2) void trace_load(Addr addr, SizeT size).
>
> Instead of calling this precompiled function, will I get performance gain if
> I directly generate VEX code?
Yo
Am 01.10.2012 23:47, schrieb Wonjoon Song:
> In the example lackey, there is
>
> static VG_REGPARM(2) void trace_load(Addr addr, SizeT size);
>
> I saw a pdf http://valgrind.org/docs/iiswc2006.pdf that VG_REGPARM
> passes arguments using registers instead of stack. Is this inlining?
No.
VG_REGPA
Am 23.07.2012 19:08, schrieb Mikael Jansson:
> + VG_(printf)("S %p\n", ist->Store.addr)
> ...
> Have I misunderstood how ist->Store.addr is supposed to be used,
Yes. IRStmt.Store.addr is of type IRExpr*. You are printing out
the address of a structure used for the VEX IR while instrumentation
of a
Am 27.06.2012 17:25, schrieb Christoph Bartoschek:
> Hi,
>
> the manual does not explain all interactions between data collection and
> instrumentation.
>
> I start with --instr-atstart=no
>
> When I then enable instrumentation with
>
> CALLGRIND_START_INSTRUMENTATION
>
> is collection activated?
Hi,
Am 14.06.2012 01:41, schrieb kapil anand:
> I am using valgrind with callgrind tool under wine but facing a few
> problems. I am using following command to run valgrind
>
> valgrind --tool=callgrind --trace-children=yes --dump-instr=yes
> --trace-jump=yes --separate-threads=yes wine
>
> S
Am 17.03.2012 03:22, schrieb Ferosh Jacob:
> Hi all
>
> I have an OpenMP program written in C and OpenMP, the program runs fine
> for some sizes of data,
> For bigger sizes it is throwing a segmentation fault, I tried setting
> the ulimit -s 1, unlimited, G/K/O, MP_STACKSIZE, variables but all
On 07.01.2012 22:59, John Reiser wrote:
>> However, after using callgrind_annotate --auto=yes, there is no information
>> for a particular function, say, "foo". The name of "foo" in the assembly is
>> "_Z10foo". I checked and evidence show that this function, which is the core
>> computational
On 15.10.2011 01:52, Igor Galić wrote:
>
> With a lot of patience and help form #perl on FreeNode, I have
> managed to put together a script which does indeed reduce the
> calls as I wanted to.
>
> While the output is still 2.4 MiB, this is a great improvement
> over the 3.6 MiB from before.
While
On 14.10.2011 17:42, Igor Galić wrote:
> To summarize: I'm trying to get a call-graph for Apache Traffic Server
> for documentation purposes. In this sense I don't care about how long
> a function call takes. If it's part of our source base, it's relevant
> to me. Thus, I would like to filter out a
On Monday 19 September 2011, zap foster wrote:
> How can the results be virtually identical? I would have thought the "false
> sharing" version would be significantly higher than the other, but they are
> nearly identical.
>
> Is there something I am doing wrong with the tool?
No.
You did not
On Saturday 10 September 2011, Emilio Coppa wrote:
> > a()
> > PLT()
> > > b()
>
> But if you print:
> > a ()
> > > b()
>
> So you can think (erroneously) that b() is called from a().
You are completely right. The calls into PLT are printed if
"--skip-plt=no" is specified. Then, the results shou
On Thursday 25 August 2011, Emilio Coppa wrote:
> > Hmm... strlen shouldn't need to call calloc, so your output seems to be
> > sane.
...
> > Can you locate the relevant output of "valgrind --tool=callgrind
> > --ct-verbose=2 ..."?
Thanks! There are a lot of strlen called here, but all end with r
Just some followup...
On Tuesday 30 August 2011, Christoph Schwarz wrote:
> On 30/08/2011 3:50 AM, WAROQUIERS Philippe wrote:
> >> However, the cost seems to include overhead from valgrind itself, such
> >> as malloc& other hooks.
...
> > Are you sure these hooks are from valgrind ?
...
> Probabl
On Wednesday 24 August 2011, Emilio Coppa wrote:
> >. > strlen(0x40183b6, 0xbe918faa, ...) [ld-2.13.so / 0x16c20]
> >. > calloc(0x2e9, 0x1, ...) [ld-2.13.so / 0x14dd0]
> >. > 0x000174ab(0xbe918194, 0x401cff4, ...) [ld-2.13.so / 0x174ab]
> >. .> malloc(0x2e9, 0x401cff4, ...) [ld
On Wednesday 24 August 2011, Emilio Coppa wrote:
> Hi
>
> I am trying to write a new tool. For my purpose i need to track function
> entry/exit, I read tracking-fn-entry-exit.txt and see some code of callgrind
> (it's not easy to isolate the code that i need), but I am not so good and so
> I have
On Friday 19 August 2011, Asra Baig wrote:
> What is the unit of measurement of absolute cost values? Is it microsecs?
The unit depends on the event type selected to be shown by KCachegrind.
E.g. Callgrind has a cache simulator, so event types are for example
"instructions executed" or "cache miss
On Monday 18 July 2011, David Granchinho wrote:
> Hi! I'm using a modified version of lackey so that I print the access
> made by superblocks in a specific way. I'm tracking the function calls
> to a specific group of functions but I can't do it if the level of
> function calls gets too deep. I've
e associated with each superblock.
As superblocks can have multiple exits, there is not really a good way
to predefine a cost per block.
Josef
> Is there any way to get
> the cost of each block? (maybe in terms of instructions executed?)
>
> 2011/7/14 Josef Weidendorfer :
> > On
On Wednesday 13 July 2011, David Granchinho wrote:
> Hi! I couldn't find anywhere in the documentation what is the meaning
> of the cost of a basic block: bb->cost_count. It measures the cost of
> the execution of this block in terms of what?
This is the number of 64bit counters that have to be al
On Tuesday 12 July 2011, David Granchinho wrote:
> Hi! I'm currently trying to develop a simple profiling tool on top of
> callgrind. I've created a structure that contains information about
> every executed block and its memory accesses. To do that, every time
> the function callgrind/bbcc.c/CLG_(
On Monday 11 July 2011, John Reiser wrote:
> >> It is better to think of this as a _continuation_, for which
> >> some programmers might use the idea of "return+call" as a crutch
> >> until they become familiar with continuations. In many cases
> >> it is important to realize that a principle side
On Monday 11 July 2011, John Reiser wrote:
> ...
> >> Adopting the "subroutine outlook" also favors a loop over recursion.
> >> The "subroutine outlook" knows only what is [scheduled] to be done
> >> in the future; what has happened in the past is not relevant and
> >> cannot be known. Thus the cu
On Thursday 07 July 2011, Josef Weidendorfer wrote:
> valgrind --tool=callgrind --ct-verbose=1 ...
By the way: please only look at the sequence of function calls printed
out. The rest probably is completely misleading (esp. the stuff that
looks like parameters of the called functions).
The opt
On Friday 08 July 2011, John Reiser wrote:
> What I see is an instance of EPIC FAIL for Usability.
Thanks for the detailed reply. I really appreciate it.
The first thing I must note here is that "callgrind_annotate" is meant
as fallback solution for people who can/do not want to use a GUI.
KCach
On Friday 08 July 2011, pankaj pawan wrote:
> I know the arguments and their types.
> I can get the stackpointer during
> runtime but how do I read the stack after that.
> Can I read memory just by dereferencing the stack pointer?
VEX of course can read from memory, see IRExpr_Load.
Or if you ins
On Thursday 07 July 2011, pankaj pawan wrote:
> Hi Josef,
>
> Thanks for your reply. I did run valgrind with
> guest_chase_thresh = 0 and was able to do capture the calls.
>
> But my doubt was that I can't see the jump statement(is it that
> unconditional jumps are not displayed in IR)
> Sorry
On Thursday 07 July 2011, John Reiser wrote:
> > valgrind --tool=callgrind --ct-verbose=1 ...
>
> When I run callgrind and callgrind_annotate, then I don't understand
> the output. For instance, the connection between "73" and the number
> of actual dynamic calls to exit() is mysterious to me:
>
On Thursday 07 July 2011, pankaj pawan wrote:
> Hi all,
>
> I had doubt regarding the flattened IR for a call instruction. When I try
> and print the IR statements for call instructions, i can see the return
> instruction being written on the stack but i am unable to see how the
> branching is bei
On Thursday 07 July 2011, John Reiser wrote:
> > I have a binary file what i compile it with -g.So i need to perform a
> > set of action in my computer and see behavior of my file, This mean , i
> > need to see functions of run when i perform those set of actions,
>
> This sounds like some kind of
On Saturday 04 June 2011, Frank Chang wrote:
> Josef Weidenorfer, Thank you for your reply, When we to ftp mirror
> ftp://ftp.gtlib.cc.gatech.edu/pub/kde/snapshots, we cannot find
> kdemodule-svn.tar.bz2. We thought this is the module that contains the
> latest version of cgview.
ftp://ftp.gtlib.c
On Friday 03 June 2011, Frank Chang wrote:
> Good morning , We can't find the cgview source code,
See
http://websvn.kde.org/trunk/KDE/kdesdk/kcachegrind
See "Obtaining The Source Code" at
http://techbase.kde.org/Getting_Started/Sources
You need cmake to compile.
Warning: cgview is not release
On Friday 03 June 2011, Frank Chang wrote:
> At the beginning of a program period you want to profile, set the counters
> to zero (add "CALLGRIND_ZERO_STATS;"
> into your source), and at the end, dump the profile to a file (add
> "CALLGRIND_DUMP_STATS;" into your source code).
>
>
> However, we f
On Wednesday 01 June 2011, Julian Seward wrote:
> > I want to keep short prefixes. 2 or 3 letters is fine; DRD uses
> > 'drd' in a lot of places. I want to keep "cg" for Cachegrind, so
> > "clg" for Callgrind is fine; "cl" would be fine too, probably better
> > in fact. I don't want to change a
Hi,
this really sounds like a discussion on the color of the bike shed.
Anyway...
On Saturday 28 May 2011, WAROQUIERS Philippe wrote:
> >> Is there a need for vgdb to stick with 2 letters? I much would prefer "clg"
> >> instead. Since years I use the alias clg='valgrind --tool=callgrind', and
>
1 - 100 of 191 matches
Mail list logo
