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
(1) |
2
(8) |
3
(7) |
4
(16) |
5
|
|
6
(3) |
7
(4) |
8
(1) |
9
(1) |
10
(4) |
11
(5) |
12
(1) |
|
13
|
14
(4) |
15
(2) |
16
|
17
(2) |
18
(9) |
19
(5) |
|
20
(9) |
21
(7) |
22
(9) |
23
(5) |
24
|
25
(1) |
26
|
|
27
|
28
(1) |
29
(11) |
30
(6) |
31
|
|
|
|
From: Jeremy F. <je...@go...> - 2002-10-14 22:53:33
|
Here's a patch which allows a skin to ask for data symbols to be preserved. It does 3 things: - it adds a new data_syms flag to VG_(needs), so that only skins which want them get them. - it adds some new logic to vg_read_lib_symbols, which 1. only expects to see segments with a 0 file offset 2. traverses the ELF Phdrs, and includes all the mapped segments into the SegInfo's address range - by happy convenience, this also completely cleans up the si->offset mess; there is no longer any dependence on knowing where the executables are loaded; it can be derived from the ELF file itself. The value of si->offset = si->start - phdr->p_vaddr. J |
|
From: Jeremy F. <je...@go...> - 2002-10-14 16:17:05
|
On Mon, 2002-10-14 at 04:15, Josef Weidendorfer wrote:
Hi Jeremy,
I just looked over your vgprof skin: Seems quite cool :-)
The client side requests (e.g. VALGRIND_DUMP_PROFILE) are quite
useful. But they need changing source and recompilation. Did you
already thought about alternate solutions?
I have the "--dumpat=" command line option (should be renamed to
--dump-at-entering=" and adding "--dump-at-leaving=").
The main reason I added them was for doing profiling of an interactive
application. I actually bound them to keystrokes so I can do things
like:
1. zero stats
2. move around the UI
3. grab profile
Static profile snapshots at particular function entry/exits wouldn't
have been that useful.
Additionally I allow interactive controlling a cachegrind run by creating
"cachegrind.cmd" files. At the moment, simply a dump is made when
detecting this file. But I want to add commands for cachegrind to read and
execute them, e.g. "DUMP NOW" or "DUMP AT ENTERING xxx" or
"DELETE DUMP AT ENTERING xxx".
It would be cool if we could come up with some kind of "standard" for this.
Especially as I would like to add a (v)gprof import filter for KCachegrind,
and you create trace parts, too: KCachegrind has a toolbar button "force
dump", creating a "cachegrind.cmd" file (This should be renamed to
"valgrind.cmd").
Well, it seems that there's some plan to add a mechanism so that
valgrind can report its results via a socket rather than simply writing
out to stderr. Such a socket seems like a better way of communicating
with a skin than polling on a file.
For actual configuration-type information, I was thinking of
implementing some suppression file keywords, so that I can include or
exclude particular parts of the program. It would make sense to add a
suppression keyword to trigger a profile dump as well.
The idea of different "weights" for different instructions seems to be
quite useful to add to cachegrind (as new event type).
How did you get your weights?
They can be quite different for every different processor (AMD/Intel).
And the best thing would be to get the values by measuring online,
with an additional tool to put measured weights into a config file (like
calibrator for the cache latencies).
That's all a complete hack at the moment. It doesn't even measure the
right thing; it adds weights based on the UInstrs, but doesn't take into
account the original x86 instruction's performance characteristics. The
alternative, which is to simply count x86 instructions, gives somewhat
misleading results because it assumes that all instructions take the
same amount of time to run.
As I understand, you have a new gmon format version. I would suggest
the following for the new format:
For each header, add a section length field to allow skipping this
section if the reader doesn't know about the section type (You once said that
this is a shortcoming of the current format yourself).
Yes, that's a problem with using gmon.out, but the main reason for using
it was to reuse the gprof code base, and with luck be able to get the
changes merged into the binutils mainline. It isn't a very nice format
on the whole, so it certainly isn't hard to come up with something
improved, but I don't think its worth the effort to completely change
the gmon.out format.
Multiple history sections seem to be supported in the format. Can (v)gprof
handle these, e.g. choosing them per option? Or does the gprof output have
different columns for each event type?
The gprof program can only really deal with one unit at a time. And I
haven't really looked into recording other units yet, though elapsed
time and CPU-time seem like the most useful.
I would like to add an gprof import filter to KCachegrind: Supporting an
extensionable format would be good for this. I suppose I will have to copy
all the symbol reading stuff from binutils. The nice thing of the cachegrind
format is that you already have symbol names...
Yes, or the stuff from valgrind itself. As far as I can tell, libbfd is
pretty inefficient at doing the things that gprof needs done (in
particular, mapping code addresses to file:lines). The advantage is
that it supports lots of different file formats.
If I understand correctly, you associate the weights of a BB to the start
address of this BB. Is this granularity enough for annotated source output of
your vgprof?
I haven't used annotated source, because gprof is too inefficient at
reading lots of line-level symbol tables. But yes, I think accumulating
the BB's instructions to the first address doesn't upset things too much
(at the source level, you may see something later in a BB supposedly
taking no time, but it wouldn't be that hard to work out what's going
on).
J
|
|
From: Josef W. <Jos...@gm...> - 2002-10-14 11:15:27
|
Hi Jeremy, I just looked over your vgprof skin: Seems quite cool :-) The client side requests (e.g. VALGRIND_DUMP_PROFILE) are quite useful. But they need changing source and recompilation. Did you already thought about alternate solutions? I have the "--dumpat=3D" command line option (should be renamed to=20 --dump-at-entering=3D" and adding "--dump-at-leaving=3D"). Additionally I allow interactive controlling a cachegrind run by creating "cachegrind.cmd" files. At the moment, simply a dump is made when detecting this file. But I want to add commands for cachegrind to read an= d execute them, e.g. "DUMP NOW" or "DUMP AT ENTERING xxx" or "DELETE DUMP AT ENTERING xxx". It would be cool if we could come up with some kind of "standard" for thi= s. Especially as I would like to add a (v)gprof import filter for KCachegrin= d,=20 and you create trace parts, too: KCachegrind has a toolbar button "force=20 dump", creating a "cachegrind.cmd" file (This should be renamed to=20 "valgrind.cmd"). The idea of different "weights" for different instructions seems to be quite useful to add to cachegrind (as new event type). How did you get your weights? They can be quite different for every different processor (AMD/Intel). And the best thing would be to get the values by measuring online, with an additional tool to put measured weights into a config file (like=20 calibrator for the cache latencies). As I understand, you have a new gmon format version. I would suggest the following for the new format: For each header, add a section length field to allow skipping this section if the reader doesn't know about the section type (You once said = that=20 this is a shortcoming of the current format yourself). Multiple history sections seem to be supported in the format. Can (v)gpro= f=20 handle these, e.g. choosing them per option? Or does the gprof output hav= e=20 different columns for each event type? I would like to add an gprof import filter to KCachegrind: Supporting an=20 extensionable format would be good for this. I suppose I will have to cop= y=20 all the symbol reading stuff from binutils. The nice thing of the cachegr= ind=20 format is that you already have symbol names... If I understand correctly, you associate the weights of a BB to the start= =20 address of this BB. Is this granularity enough for annotated source outpu= t of=20 your vgprof? I suppose if you have a series of non-branching statements on a few sourc= e=20 lines, the annotation would put all the weights to the source line of the= =20 first statement... On Monday 14 October 2002 07:53, Jeremy Fitzhardinge wrote: > Here's a series of my patches against the current Valgrind CVS head. > They are: > [...] > 12-vgprof > A skin which generates gprof-style profiling output files. This al= lows > profiling of multithreaded programs using shared libraries. Requir= es a > patched version of gprof to interpret the output files. |
|
From: Jeremy F. <je...@go...> - 2002-10-14 05:53:55
|
Here's a series of my patches against the current Valgrind CVS head.
They are:
00-lazy-fp
This patch implements lazy FPU state save and restore, which improves
the performance of FPU-intensive code by a factor of 15 or so.
01-partial-mul
This creates a new UInstr for multiply. This is mainly so that memcheck
can treat it like add and generate partially-defined results of multiply
with partially defined arguments.
02-sysv-msg
Support for threaded programs using msgsnd/msgrcv.
03-poll-select
Bind poll and select properly to catch all references.
04-lax-ioctls
Adds new "lax-ioctls" weird hack to make checking on ioctl arguments
very weak (assume all inputs are defined and all outputs become defined).
05-skin-clo-ordering
Reorder the baseBlock init with respect to calling the skin post_clo
routine. Some skins can't register their baseblock helpers until
after CLO parsing, so the skin's post_clo function must be called
before BaseBlock init.
06-memops
Implement memcpy/memset.
07-seginfo
API for skins to extract from information about mapped segments.
08-skin-clientreq
Introduce a systematic way for skins to distinguish each other's
client requests. Uses the de-facto standard two-letter identifiers in
the top two bytes of the client request code. Also changes the
interface to SK_(handle_client_request) so that a skin can say whether
or not it handled the request, which allows correct setting of the
default return value if the request was not handled.
09-rdtsc-calibration
Spin rather than sleep during rtdsc calibration, in order to
compensate for power-management modes where the TSC does not advance
while the CPU is idle. Of course this makes the TSC generally
unreliable as a timing mechanism, but at least it doesn't trigger an
assert.
12-vgprof
A skin which generates gprof-style profiling output files. This allows
profiling of multithreaded programs using shared libraries. Requires a
patched version of gprof to interpret the output files.
(The missing patches are local ones which aren't generally useful.)
Rather than attaching them all, they're available separately at
http://www.goop.org/~jeremy/valgrind/ and rolled together at
http://www.goop.org/~jeremy/valgrind/patches.tar.gz.
More detail on vgprof is available at
http:://www.goop.org/~jeremy/valgrind/vgprof.html.
J
|