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
|
|
2
|
3
|
4
|
5
(2) |
6
(1) |
7
|
8
|
|
9
(1) |
10
(1) |
11
|
12
|
13
|
14
(3) |
15
(4) |
|
16
(4) |
17
(2) |
18
(18) |
19
|
20
|
21
(7) |
22
|
|
23
(2) |
24
(3) |
25
(1) |
26
(5) |
27
(12) |
28
(1) |
29
(2) |
|
30
(4) |
31
|
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2003-03-21 19:23:54
|
On Tuesday 18 March 2003 12:40 pm, Eyal Lebedinsky wrote: > building from CVS I see that Makefile.am wants version 1.5. I am on > Linux Debian Stable, which has 1.4. I built with it and all looked > just fine. > > Is 1.5 really needed? If not, can we please downgrade to 1.4? Um, influential people are pushing in the opposite direction, suggesting that 1.6 is the minimum that should be supported, and I have to say that sounds better in the long(er) term. J |
|
From: Josef W. <Jos...@gm...> - 2003-03-21 16:47:41
|
On Friday 21 March 2003 17:15, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > > Does it make sense to merge this in some way with the error suppression > > stuff? > > What do you mean by "instrumentation parameters"? Parameters specified by the user at runtime, which influence the instrumentation added to the basic block(s) of a function. E.g. I support command line options "--fn-recursion<no>=<function>", "--dump-before=<function>", "--fn-skip=<function>", allowing to specify an option multiple times for different functions. When entering a function the first time in a program run, the instrumentation is done. Above parameters can influence the instrumentation of the BB. OK, perhaps it's not the right word, as often only the behaviour of some helper function is changed, called by the instrumentation done. Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-03-21 16:28:17
|
On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > Doesn't GCC use it's own inline-version of memcpy when optimization is on? Yes. Not much you can do; the user manual recommends turning off optimisation anyway ;) (Actually, I think it compromises on -O...) > An alternative solution for function wrapping would be not to use the runtime > linker (symbol overwriding, hack with __libc_malloc), but to change > instrumentation of the first BB of the given function, and do a "jmp" into > the valgrind wrapper version if the skin would like to use it. Hey, good idea. I'll have to think about that some more... > In my latest calltree version, I introduced an infrastruction to specify > instrumentation parameters on the basis of a function symbol name. > This would be a good addition to valgrind core, and would come handy > with the above wrapping (wrapper function as parameter dependent on symbol > name). > [...] > Does it make sense to merge this in some way with the error suppression stuff? What do you mean by "instrumentation parameters"? N |
|
From: Josef W. <Jos...@gm...> - 2003-03-21 15:40:52
|
On Friday 21 March 2003 10:42, Nicholas Nethercote wrote:
> I've been thinking about Josef's suggestion about letting the skin decide
> if it wants to use __libc_malloc() or Valgrind's malloc(), and whether to
> wrap them. I think it could be done, although I haven't got around to
> trying it yet. This {mem,str,strn}cpy() checking could be done
> similarly... Memcheck and Addrcheck would use Valgrind's provided
> versions, using a wrapper that checks the args don't overlap, and other
> skins could use the libc versions. Ah, except it seems that glibc doesn't
> define __libc_memcpy the way it does __libc_malloc, which could make
> things tricky.
Hmm...
Doesn't GCC use it's own inline-version of memcpy when optimization is on?
An alternative solution for function wrapping would be not to use the runtime
linker (symbol overwriding, hack with __libc_malloc), but to change
instrumentation of the first BB of the given function, and do a "jmp" into
the valgrind wrapper version if the skin would like to use it.
This avoids the static behaviour of symbol definitions in shared libraries,
and can even be done by valgrind core before calling the instrumentation
function of the skin. Still, in the case of wrapping, the instrumentation
function of the skin should get the replaced jump for further
instrumentation.
> Still, this whole question of "do I use the normal version or Valgrind's
> version of function x()" is worth investigation, and I hope to look into
> it more soon.
In my latest calltree version, I introduced an infrastruction to specify
instrumentation parameters on the basis of a function symbol name.
This would be a good addition to valgrind core, and would come handy
with the above wrapping (wrapper function as parameter dependent on symbol
name).
As the lookup for instrumentation parameters has to be done on instrumentation
of every basic block, this has to be fast. I use a prefix tree for lookup.
This even allows to only specify symbol prefixes, i.e. a star wildcard at the
end.
E.g. say you have set
- parameter A=0 for symbol "foo1",
- parameter A=1 for symbol "foo1bar",
- parameter A=2 for symbol "foo2",
- parameter A=3 for symbol "foo*".
The prefix search tree looks like this:
"foo"
+-- "*": A=3
+-- "1": A=0
+-- "bar": A=1
+-- "2": A=2
e.g. if you have symbol "foobar", it goes down the tree and stops with A=3.
Does it make sense to merge this in some way with the error suppression stuff?
Josef
PS: Nick, could you send me the scripts for the SPEC2000 benchmarks?
I would like to check it with my skin.
>
> N
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-21 10:08:24
|
Hi,
I've been doing some benchmarking, I thought I'd report the results since
AFAIK nobody has done tests this thorough before.
All experiments were performed on an AMD Athlon 1400 MHz with 1GB of RAM
(recent upgrade from 256MB :) running Red Hat Linux 7.1, kernel version
2.4.19. The test programs are a subset of the SPEC2000 suite, basically
those ones I could get to work. All were tested with the ``test''
(smallest) inputs. I didn't test Helgrind because the programs aren't
threaded, so it would have been a bit pointless.
First of all was time performance.
Program Time Nulgrind Memcheck Addrcheck Cachegrind
------------------------------------------------------
bzip2 10.8s 2.5 14.1 10.0 30.9
crafty 3.2s 7.5 55.2 36.5 117.6
gap 0.9s 5.5 35.1 25.9 48.5
gcc 1.5s 8.6 38.9 27.4 70.3
gzip 1.8s 4.4 26.5 20.9 53.3
mcf 0.3s 2.8 12.1 6.3 18.5
parser 3.4s 3.6 21.6 17.0 34.3
twolf 0.2s 5.0 31.1 21.3 50.9
vortex 6.5s 7.7 62.8 52.2 88.1
------------------------------------------------------
ammp 19.3s 2.2 24.1 21.0 46.5
art 26.1s 6.1 14.1 11.4 20.0
equake 2.1s 6.1 30.5 28.3 50.4
mesa 2.7s 4.9 41.5 32.7 63.4
------------------------------------------------------
Column 1 gives the benchmark name, column 2 gives the time taken to run
the benchmark normally, and columns 3--6 gives the slowdown factor for
each skin. Programs above the line are integer programs, those below are
floating point programs.
Second was code expansion.
Program Code size Nulgrind Memcheck Addrcheck Cachegrind
----------------------------------------------------------------
bzip2 32KB 5.1 11.6 6.4 9.1
crafty 153KB 4.4 10.6 5.7 8.1
gap 137KB 5.6 12.4 6.9 9.6
gcc 561KB 5.9 12.8 7.3 9.9
gzip 28KB 5.4 12.1 6.8 9.4
mcf 28KB 5.7 13.0 7.2 9.9
parser 94KB 6.0 13.2 7.4 10.1
twolf 110KB 5.2 11.9 6.7 9.3
vortex 230KB 5.8 12.7 7.6 10.1
----------------------------------------------------------------
ammp 64KB 4.6 11.4 6.8 9.5
art 21KB 5.5 12.5 7.0 9.8
equake 42KB 5.0 11.8 6.7 9.2
mesa 65KB 4.7 10.8 6.4 8.9
----------------------------------------------------------------
Format is the same, except column two shows original code size.
I haven't given averages because (a) I'm never sure which average
(arithmetic, geometric, harmonic, pentatonic, teutonic, moronic, whatever)
to use, and (b) averages encourage people to ignore the actual results.
The most interesting things to me were:
1. Variation in slowdown factor -- the worst slowdown for each skin was
4--6 times worse than the best slowdown.
2. How slow Memcheck is: I was thinking it's 10--20 times slower, but it's
usually worse than that.
3. How slow Addrcheck is: it's certainly not twice as fast as Addrcheck.
Maybe 30% faster.
4. crafty has the worst overall time performance, but the smallest code
expansion. It's a chess puzzle solver that uses 64-bit longs heavily,
which maybe Valgrind doesn't handle so well timewise.
If anyone else who has the SPEC2000 benchmark suite is interested in
running tests on their machine, let me know and I'll send you my test
script and instructions on how to use it.
N
|