|
From: Frank C. <fra...@gm...> - 2011-05-25 19:02:12
|
Good afternoon, We are currently using callgrind on Centos Linux 5.5
x86_32 to profile an entire program using the
command:/home/frankc/DQTTest2/valgrind-3.6.1/coregrind/valgrind
--tool=callgrind --dump-instr=yes --simulate-cache=yes
--collect-jumps=yes ./MatchUpAccurate.exe
We were wondering whether Is it possible for callgrind to
selectively profile certain periods of our program's execution? We
understand there is callgrind tool : 1. callgrind_control -i on 2.
callgrind_control -i off that may allow us to profile certain periods
of a program's execution.
However, we uncertain which callgrind options we should use to
accomplish this requirement . So far we think we need to use:
:/home/frankc/DQTTest2/valgrind-3.6.1/coregrind/valgrind
--tool=callgrind -instr-atstart=no ????. Could any valgrind users or
engineers tell us how to use the --instr-atstart=no option with our
program ./MatchUpAccurate.exe? Thank you.
|
|
From: Josef W. <Jos...@gm...> - 2011-05-25 20:15:12
|
Hi, On Wednesday 25 May 2011, Frank Chang wrote: > Good afternoon, We are currently using callgrind on Centos Linux 5.5 > x86_32 to profile an entire program using the > command:/home/frankc/DQTTest2/valgrind-3.6.1/coregrind/valgrind > --tool=callgrind --dump-instr=yes --simulate-cache=yes > --collect-jumps=yes ./MatchUpAccurate.exe > We were wondering whether Is it possible for callgrind to > selectively profile certain periods of our program's execution? > We > understand there is callgrind tool : 1. callgrind_control -i on 2. > callgrind_control -i off that may allow us to profile certain periods > of a program's execution. > However, we uncertain which callgrind options we should use to > accomplish this requirement . So far we think we need to use: > :/home/frankc/DQTTest2/valgrind-3.6.1/coregrind/valgrind > --tool=callgrind -instr-atstart=no ????. Could any valgrind users or > engineers tell us how to use the --instr-atstart=no option with our > program ./MatchUpAccurate.exe? Thank you. If you want seperate profiling information for "certain periods" in your program, you should ask Callgrind to write seperate profile files for every period you are interested in. Changing the "instrumentation state", with the options you mention above, is only needed if you want to speed up Callgrind for periods you are not interested in. But if you do not worry about simulation time, no need to use these options. At the beginning of a program period you want to profile, set the counters to zero (either callgrind_control -z, or add "CALLGRIND_ZERO_STATS;" into your source), and at the end, dump the profile to a file (using callgrind_control -d, or "CALLGRIND_DUMP_STATS;"). Everytime you trigger a dump, a new file will be generated. If the start/end of the period you want to profile is at a function boundary, you can also use the options --zero-before=<name of function when entered starts the period> and --dump-after=<name of function when left ends the period> Josef > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Frank C. <fra...@gm...> - 2011-05-25 21:03:13
|
Josef Weidendorder, Thank you for for your answer . Could you please tell us how to use valgrind --tool=callgrind -instr-atstart=no ....... along with callgrind_control -z and callgrind_control -d? We want to follow you recommendation shown below. Thank you for your help/ > At the beginning of a program period you want to profile, set the counters > to zero (either callgrind_control -z, or add "CALLGRIND_ZERO_STATS;" > into your source), and at the end, dump the profile to a file (using > callgrind_control -d, or "CALLGRIND_DUMP_STATS;"). On Wed, May 25, 2011 at 4:15 PM, Josef Weidendorfer <Jos...@gm...> wrote: > Hi, > > On Wednesday 25 May 2011, Frank Chang wrote: >> Good afternoon, We are currently using callgrind on Centos Linux 5.5 >> x86_32 to profile an entire program using the >> command:/home/frankc/DQTTest2/valgrind-3.6.1/coregrind/valgrind >> --tool=callgrind --dump-instr=yes --simulate-cache=yes >> --collect-jumps=yes ./MatchUpAccurate.exe >> We were wondering whether Is it possible for callgrind to >> selectively profile certain periods of our program's execution? >> We >> understand there is callgrind tool : 1. callgrind_control -i on 2. >> callgrind_control -i off that may allow us to profile certain periods >> of a program's execution. >> However, we uncertain which callgrind options we should use to >> accomplish this requirement . So far we think we need to use: >> :/home/frankc/DQTTest2/valgrind-3.6.1/coregrind/valgrind >> --tool=callgrind -instr-atstart=no ????. Could any valgrind users or >> engineers tell us how to use the --instr-atstart=no option with our >> program ./MatchUpAccurate.exe? Thank you. > > If you want seperate profiling information for "certain periods" in > your program, you should ask Callgrind to write seperate profile files > for every period you are interested in. > > Changing the "instrumentation state", with the options you mention above, > is only needed if you want to speed up Callgrind for periods you are > not interested in. But if you do not worry about simulation time, no > need to use these options. > > At the beginning of a program period you want to profile, set the counters > to zero (either callgrind_control -z, or add "CALLGRIND_ZERO_STATS;" > into your source), and at the end, dump the profile to a file (using > callgrind_control -d, or "CALLGRIND_DUMP_STATS;"). > > Everytime you trigger a dump, a new file will be generated. > > If the start/end of the period you want to profile is at a function boundary, > you can also use the options > --zero-before=<name of function when entered starts the period> > and > --dump-after=<name of function when left ends the period> > > Josef > > > >> >> ------------------------------------------------------------------------------ >> vRanger cuts backup time in half-while increasing security. >> With the market-leading solution for virtual backup and recovery, >> you get blazing-fast, flexible, and affordable data protection. >> Download your free trial now. >> http://p.sf.net/sfu/quest-d2dcopy1 >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > > |
|
From: Josef W. <Jos...@gm...> - 2011-05-26 07:31:57
|
On Wednesday 25 May 2011, Frank Chang wrote: > tell us how to use valgrind --tool=callgrind -instr-atstart=no > ....... along with callgrind_control -z and callgrind_control -d? We > want to follow you recommendation shown below. Thank you for your > help/ No need to use "--instr-atstart=no". You obviously found out yourself. May I ask why the manual is not helpful for you? I hope I can improve it after this discussion. Josef |
|
From: Frank C. <fra...@gm...> - 2011-05-26 12:03:29
|
Josef Weidendorfer, I looked at your callgrind manual and it very helpful to me. It took me some time to find the manuall using Google search, The two suggestion I have is: 1. could you tell us how to find a manual that describes how to interpret the auto-annonated source code results produced by callgrind_annotate callgrind.out.xxxx --auto =yes. For example, where can we find explanations of the IR, DR, DW, LLMR, D1MR, D1MW, ILMR, DLMR,DLmw results. Thank you, 2. My suggestion is sometimes I notice that if we run a program that is a target for callgrind it runs completely to the end with no segmentation faults,etc. Then when we run valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jump=yes XXX.exe, we get a core dump vgcore.xxx. When we use gdb .\XXX.exe vgcore.XXXX, and enter bt, we get back a backtrace filled with ???? and no complete source filename - line number backtrace. We are sure we compiled our program with the -g compiler flag. Would your manual be able to describe why that problem happens and how we can fix the segmentation fault encountered while running valgrind -tool=callgrind XXXX= yes XXX=Yes X==Yes XXX=Yes YYY.exe? Thank you for all of your help. On Thu, May 26, 2011 at 12:31 AM, Josef Weidendorfer <Jos...@gm...> wrote: > On Wednesday 25 May 2011, Frank Chang wrote: >> tell us how to use valgrind --tool=callgrind -instr-atstart=no >> ....... along with callgrind_control -z and callgrind_control -d? We >> want to follow you recommendation shown below. Thank you for your >> help/ > > No need to use "--instr-atstart=no". You obviously found out yourself. > > May I ask why the manual is not helpful for you? I hope I can > improve it after this discussion. > > Josef > |