|
From: Milind <km...@gm...> - 2010-01-12 08:01:45
|
Hello VG developers, I have started exploring valgrind recently. I wanted to know if valgrind core keeps track of the CPU clock ticks. I want to record memory access pattern of my program. In that context, I wanted to record the CPU clock tick value at the time of memory access. I want to feed output of valgrind to DRAMsim which needs memory addr that is being accessed, access type (read, write, etc) and the cpu clock time value when the access is being done. Any pointers/links will help. Thanks, - Milind |
|
From: Milind <km...@gm...> - 2010-01-12 13:55:08
|
Thanks Josef for the reply. I am referring to CPU clock ticks and not the wall clock. Couple of responses that I received also indicate that there is no real CPU clock tick simulation. Let me see if I can cover my requirement with the cachegrind output. I am sure I wont need full-system simulators yet. Thanks, - Milind On Tue, Jan 12, 2010 at 6:45 PM, Josef Weidendorfer < Jos...@gm...> wrote: > Hi, > > On Tuesday 12 January 2010, Milind wrote: > > I have started exploring valgrind recently. I wanted to know if valgrind > > core keeps track of the CPU clock ticks. > > Which ticks do you mean? Wall clock time makes not much sense, as this > would > include all housekeeping tasks Valgrind is doing, such as instrumentation > of > client code. So, there really is no "CPU clock tick" to keep track of. > You have to maintain your own tick counter if you want something like this. > > And how you want this counter to advance is totally up to you and depends > on > the type of processor model you envision. E.g. you could include a cache > model, > a branch predictor, latency/troughput parameters for different instruction > types and so on, and advance the clock tick counter accordingly. > Just a note: it probably gets arbitrarily complex to approximate the tick > counter > of a real processor; and this only will work for the user-level side with > one > process. > > Perhaps it is better for you to look at cycle-accurate full-system > simulators? > > Josef > > > I want to record memory access > > pattern of my program. In that context, I wanted to record the CPU clock > > tick value at the time of memory access. I want to feed output of > valgrind > > to DRAMsim which needs memory addr that is being accessed, access type > > (read, write, etc) and the cpu clock time value when the access is being > > done. Any pointers/links will help. > > > > Thanks, > > - Milind > > > > > |
|
From: Milind <km...@gm...> - 2010-01-12 14:37:46
|
Hi Josef, On Tue, Jan 12, 2010 at 7:47 PM, Josef Weidendorfer < Jos...@gm...> wrote: > Hi Milind, > > On Tuesday 12 January 2010, Milind wrote: > > Thanks Josef for the reply. I am referring to CPU clock ticks and not the > > wall clock. > > with "wall clock", I actually meant any time source derived from real time > (including CPU clock ticks of the Valgrind process). > > > Couple of responses that I received also indicate that there is > > no real CPU clock tick simulation. > > How could there be? Valgrind does not enforce any performance model with > given time characteristics on you, and such a thing is not needed by > any Valgrind tool. So, how should it be able to provide you with a > clock tick simulation? > [milind] Ok. Got this now. > > > Let me see if I can cover my requirement > > with the cachegrind output. > > By multiplying the event counts from cachegrind output with penalties for > the > different event types, you can come up with clock tick estimations, yes. > [milind] can you elaborate little more ? :) Thanks, - Milind > > Josef > > > I am sure I wont need full-system simulators > > yet. > > > > Thanks, > > - Milind > > > > On Tue, Jan 12, 2010 at 6:45 PM, Josef Weidendorfer < > > Jos...@gm...> wrote: > > > > > Hi, > > > > > > On Tuesday 12 January 2010, Milind wrote: > > > > I have started exploring valgrind recently. I wanted to know if > valgrind > > > > core keeps track of the CPU clock ticks. > > > > > > Which ticks do you mean? Wall clock time makes not much sense, as this > > > would > > > include all housekeeping tasks Valgrind is doing, such as > instrumentation > > > of > > > client code. So, there really is no "CPU clock tick" to keep track of. > > > You have to maintain your own tick counter if you want something like > this. > > > > > > And how you want this counter to advance is totally up to you and > depends > > > on > > > the type of processor model you envision. E.g. you could include a > cache > > > model, > > > a branch predictor, latency/troughput parameters for different > instruction > > > types and so on, and advance the clock tick counter accordingly. > > > Just a note: it probably gets arbitrarily complex to approximate the > tick > > > counter > > > of a real processor; and this only will work for the user-level side > with > > > one > > > process. > > > > > > Perhaps it is better for you to look at cycle-accurate full-system > > > simulators? > > > > > > Josef > > > > > > > I want to record memory access > > > > pattern of my program. In that context, I wanted to record the CPU > clock > > > > tick value at the time of memory access. I want to feed output of > > > valgrind > > > > to DRAMsim which needs memory addr that is being accessed, access > type > > > > (read, write, etc) and the cpu clock time value when the access is > being > > > > done. Any pointers/links will help. > > > > > > > > Thanks, > > > > - Milind > > > > > > > > > > > > > > > > > > |
|
From: Danny R. <dr...@cs...> - 2010-01-13 00:59:23
|
On Tue, 12 Jan 2010 13:31:37 +0530 Milind <km...@gm...> wrote: > I have started exploring valgrind recently. I wanted to know if > valgrind core keeps track of the CPU clock ticks. I want to record > memory access pattern of my program. It might help to know more about what you want to accomplish at the end of the day. Do you want to identify regions of suboptimal code, quantify the runtime of some application, experiment with different system parameters? > In that context, I wanted to record the CPU clock tick value at the > time of memory access. I want to feed output of valgrind to DRAMsim > which needs memory addr that is being accessed, access type (read, > write, etc) and the cpu clock time value when the access is being > done. I would be a little concerned about feeding approximate processor timing values into what I believe is a reasonable precise DRAM timing model. If you are interested in this level of precision it may be more appropriate to look at PTLsim[1], which uses a 'cycle-accurate' processing timing model. [1] http://www.ptlsim.org/ -- Danny |
|
From: Vince W. <vi...@cs...> - 2010-01-13 02:12:52
|
On Wed, 13 Jan 2010, Danny Robson wrote: > I would be a little concerned about feeding approximate processor > timing values into what I believe is a reasonable precise DRAM timing > model. This is actually the topic of my PhD thesis (defended last month, am finishing up the thesis right now). I look at using DBI tools like Valgrind and Qemu to do architectural simulations, in an attempt to get results faster than "cycle-accurate" simulation with good enough accuracy. It turns out that for a RISC chip, such as MIPS, you can get very good cycle estimations based solely on cache and branch predictor results (even on an out-of-order processor). Unfortunately the results are not as good for x86, and it's even trickier if you are trying to do multi-core. > If you are interested in this level of precision it may be more > appropriate to look at PTLsim[1], which uses a 'cycle-accurate' > processing timing model. It's also at least two orders of magnitude slower, which is why alternate options are usually explored. Vince |