You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(12) |
2
(9) |
|
3
(23) |
4
(24) |
5
(9) |
6
(7) |
7
(5) |
8
(2) |
9
(6) |
|
10
(5) |
11
(3) |
12
(11) |
13
(4) |
14
|
15
(3) |
16
(4) |
|
17
(3) |
18
(6) |
19
|
20
(1) |
21
(9) |
22
(8) |
23
(1) |
|
24
|
25
(2) |
26
(3) |
27
(16) |
28
(17) |
29
(22) |
30
(7) |
|
31
(4) |
|
|
|
|
|
|
|
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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
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: 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: Bart V. A. <bar...@gm...> - 2010-01-12 08:55:38
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-12 02:27:52 EST Ended at 2010-01-12 03:55:22 EST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 449 tests, 43 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
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: Alexander P. <gl...@go...> - 2010-01-12 06:54:20
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2010-01-12 09:06:02 MSK Ended at 2010-01-12 09:24:45 MSK Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2010-01-12 03:49:36
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-01-12 03:05:04 GMT Ended at 2010-01-12 03:49:17 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-01-12 03:35:55
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-01-12 03:10:04 GMT Ended at 2010-01-12 03:35:36 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |