|
From: Milind <km...@gm...> - 2010-01-12 15:44:58
|
On Tue, Jan 12, 2010 at 8:58 PM, Josef Weidendorfer < Jos...@gm...> wrote: > On Tuesday 12 January 2010, Milind wrote: > > > 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 ? :) > > Cachegrind output is aggregated, as it is about profiling. You can get > aggregated figures for estimated time spent in given functions, e.g. by > using > a time penalty of 1 cycle for every executed instruction (this can be done > by > using the Ir event count), e.g. 10 cycles for L1 misses (using I1mr, D1mr, > and D1mw > events), e.g. 200 cycles for L2 misses (using I2mr, D2mr, and D2mw), and so > on > (KCachegrind allows to directly enter custom formulas). > [milind] Correct. I came till this point. I know exactly how many L1 cache misses, L2 cache misses (these are nothing but main memory accesses), number of instructions etc. > > However, the aggregated numbers probably won't help you much. I would > suggest to > [milind] This is true. These are aggregated numbers and are not helping completely. modify cachegrinds source to give you an trace of events, and from this you > can > reconstruct a simulated CPU clock tick counter, by advancing it according > to > events happening. > [milind] Well said again. This is where I am right now. I will have to explore the cachegrind code. May be Lackey may also be of help to some extent. But I doubt if Lackey takes cache hits into account. > > However, this will only work for sequential code. For multithreaded code, > Valgrind serializes threads by executing a fixed number of blocks for > each thread, and then allows for thread switching, leaving the actual > scheduling decision to the OS (I hope I got this right). > [milind] Yes, multithreaded code wont help much. For now I am confining myself to single thread. Really appreciate your thoughts and help. - Milind > > Josef > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |