You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(9) |
2
(5) |
3
(1) |
4
(4) |
5
|
6
(8) |
7
(12) |
|
8
(6) |
9
(10) |
10
(6) |
11
(8) |
12
(12) |
13
(5) |
14
(1) |
|
15
(1) |
16
(12) |
17
(9) |
18
(4) |
19
(8) |
20
(4) |
21
(1) |
|
22
|
23
(4) |
24
(12) |
25
(13) |
26
(16) |
27
(4) |
28
(2) |
|
29
(1) |
30
(4) |
31
(9) |
|
|
|
|
|
From: Julian S. <js...@ac...> - 2006-01-01 23:12:47
|
Ok, svn update (make sure you get at least r5470) and try again. This time I think it is a proper fix :-) Let me know success/failure. (Gregory: see http://www.valgrind.org/downloads/repository.html for details how to build from svn.) J On Saturday 31 December 2005 12:35, Konstantin 'KCC' Serebryany wrote: > I was able to download current version (5465) from repository, but my > problem still exist. :( > > On 12/30/05, Nicholas Nethercote <nj...@cs...> wrote: > > This is a bug in 3.1.0, I think it has been fixed in the repository. To > > try the repository code, see > > http://www.valgrind.org/downloads/repository.html. > > > > Nick |
|
From: John R.
|
> The real difficulty is to decide where to place the cost/accuracy > tradeoff for very detailed FPU simulation. Sure, it's possible to > do a more accurate simulation, but you pay an ever-larger simulation > overhead for increased accuracy, and it's not clear what is an appropriate > tradeoff. What _is_ clear is that the confusion, finger-pointing and debate will persist until the overhead (actually the difference in simulation overhead between the opcodes chosen by the compiler [80-bit] and the opcodes substituted by memcheck [64-bit]) is measured numerically, analyzed and documented. Then perhaps there can be an option so that informed users can choose. -- |
|
From: Julian S. <js...@ac...> - 2006-01-01 19:13:33
|
> It does mean that we would not be able to reproduce a full simulation > under valgrind (i.e. to understand what went wrong in a special case) as > different numerics would rapidly lead to different numbers of iterations > and (chaotic) trajectories (both meaningful runs, but different). However, > I can imagine that getting the fine details of every fpu right is not > really a priority. The real difficulty is to decide where to place the cost/accuracy tradeoff for very detailed FPU simulation. Sure, it's possible to do a more accurate simulation, but you pay an ever-larger simulation overhead for increased accuracy, and it's not clear what is an appropriate tradeoff. For most of the time, I believe the FP implementation is "accurate enough", although I'd be the first to admit we need more feedback, really. J |
|
From: Joost V. <jv...@he...> - 2006-01-01 18:52:03
|
Tom, Julian, thanks for pointing me to the docs... This is not a problem right now (though I noticed because our regression tester flagged these runs as 'wrong'). It just means that we're effectively running on another architecture. It does mean that we would not be able to reproduce a full simulation under valgrind (i.e. to understand what went wrong in a special case) as different numerics would rapidly lead to different numbers of iterations and (chaotic) trajectories (both meaningful runs, but different). However, I can imagine that getting the fine details of every fpu right is not really a priority. Thanks again, Joost |
|
From: Julian S. <js...@ac...> - 2006-01-01 17:02:47
|
> I'm running our CP2K program under valgrind (memcheck) and I'm finding > that some of the numerical results are slightly different between a normal > run and a run under valgrind. The difference is very minor (e.g. > -0.94268415669060 vs. -0.94268415669059) and could be due to differences > in rounding, but is reproducible (and no errors are generated by > valgrind). I'm a bit surprised. Is this a known issue ? Yes. See here for a discussion of FP limitations in Valgrind: http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits Let us know if these limitations are a problem. J |
|
From: Tom H. <to...@co...> - 2006-01-01 17:01:24
|
In message <Pin...@he...>
Joost VandeVondele <jv...@he...> wrote:
> I'm running our CP2K program under valgrind (memcheck) and I'm finding
> that some of the numerical results are slightly different between a normal
> run and a run under valgrind. The difference is very minor (e.g.
> -0.94268415669060 vs. -0.94268415669059) and could be due to differences
> in rounding, but is reproducible (and no errors are generated by
> valgrind). I'm a bit surprised. Is this a known issue ? This is on opteron
> with valgrind-3.1.0.
My guess would be that you are seeing the difference between the 80 bit
internal precision of the x87 floating point unit and the 64 bit precision
of valgrind's emulation of it. See the documentation at:
http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
Note that although that documentation implies that you have to be using
long doubles to observe the problem I believe that you can see it with
doubles as well if the code keeps values in registers between operations.
Try compiling your code with -mfpmath=sse (and -msse2 if this is a 32 bit
machine) and see if the two sets of results are then consistent.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Joost V. <jv...@he...> - 2006-01-01 16:34:15
|
Hi, I'm running our CP2K program under valgrind (memcheck) and I'm finding that some of the numerical results are slightly different between a normal run and a run under valgrind. The difference is very minor (e.g. -0.94268415669060 vs. -0.94268415669059) and could be due to differences in rounding, but is reproducible (and no errors are generated by valgrind). I'm a bit surprised. Is this a known issue ? This is on opteron with valgrind-3.1.0. If this is 'interesting' I can provide the binary and the input needed to reproduce this. The binary is large (20Mb), but the test runs in just 10min. under valgrind. Thanks, Joost VandeVondele |
|
From: Tom H. <to...@co...> - 2006-01-01 09:27:06
|
In message <E1E...@ma...>
br...@gi... (Bryan Henderson) wrote:
> There is a warning in the README:
>
> Important! Do not move the valgrind installation into a place
> different from that specified by --prefix at build time. This will
> cause things to break in subtle ways, mostly when Valgrind handles
> fork/exec calls.
>
> I generally cannot tolerate this restriction, so I went into the code
> to see what it would take to remove it, and I found the undocumented
> environment variable VALGRIND_LIB (which tells where Valgrind files
> live) and some code to determine at run time from what file the
> program was invoked. I didn't find the name of my "prefix" directory
> used anywhere except where subject to the VALGRIND_LIB environment
> variable. Does this mean the warning from the README is obsolete, or
> is the problem even more subtle?
It's not obsolete because we don't expect people to go round setting
that variable all the time.
Why do you want to be able to move valgrind around anyway?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <br...@gi...> - 2006-01-01 03:44:08
|
There is a warning in the README: Important! Do not move the valgrind installation into a place different from that specified by --prefix at build time. This will cause things to break in subtle ways, mostly when Valgrind handles fork/exec calls. I generally cannot tolerate this restriction, so I went into the code to see what it would take to remove it, and I found the undocumented environment variable VALGRIND_LIB (which tells where Valgrind files live) and some code to determine at run time from what file the program was invoked. I didn't find the name of my "prefix" directory used anywhere except where subject to the VALGRIND_LIB environment variable. Does this mean the warning from the README is obsolete, or is the problem even more subtle? -- Bryan Henderson Phone 408-621-2000 San Jose, California |