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
(7) |
2
(7) |
3
(11) |
4
(3) |
5
(6) |
|
6
(14) |
7
(25) |
8
(14) |
9
(21) |
10
(16) |
11
(3) |
12
(12) |
|
13
|
14
(5) |
15
(11) |
16
(4) |
17
(18) |
18
(15) |
19
|
|
20
(1) |
21
(14) |
22
(7) |
23
(14) |
24
(9) |
25
(14) |
26
(5) |
|
27
(12) |
28
(1) |
29
(5) |
30
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2011-11-22 20:16:01
|
> Together (with the macro removal patch), this gives me I obtain the below improvements on ppc64. Philippe perl perf/vg_perf --reps=10 --tools=cachegrind perf --vg=../trunk_untouched --vg=../jw_patch 2>&1 | tee perf_3patch.out -- Running tests in perf ---------------------------------------------- -- bigcode1 -- bigcode1 trunk_untouched:0.22s ca: 9.4s (42.8x, -----) bigcode1 jw_patch :0.22s ca: 7.2s (32.8x, 23.4%) -- bigcode2 -- bigcode2 trunk_untouched:0.22s ca: 9.4s (42.9x, -----) bigcode2 jw_patch :0.22s ca: 7.2s (32.7x, 23.8%) -- bz2 -- bz2 trunk_untouched:0.86s ca:30.4s (35.4x, -----) bz2 jw_patch :0.86s ca:26.1s (30.4x, 14.1%) -- fbench -- fbench trunk_untouched:0.37s ca: 9.4s (25.5x, -----) fbench jw_patch :0.37s ca: 8.1s (21.9x, 14.2%) -- ffbench -- ffbench trunk_untouched:0.43s ca: 8.4s (19.6x, -----) ffbench jw_patch :0.43s ca: 7.3s (17.0x, 13.3%) -- heap -- heap trunk_untouched:0.39s ca:14.5s (37.3x, -----) heap jw_patch :0.39s ca:12.6s (32.3x, 13.5%) -- sarp -- sarp trunk_untouched:0.03s ca: 2.0s (67.3x, -----) sarp jw_patch :0.03s ca: 1.8s (59.3x, 11.9%) -- tinycc -- tinycc trunk_untouched:0.28s ca:18.4s (65.7x, -----) tinycc jw_patch :0.28s ca:16.4s (58.7x, 10.5%) -- Finished tests in perf ---------------------------------------------- == 8 programs, 16 timings ================= |
|
From: John R. <jr...@bi...> - 2011-11-22 16:25:48
|
> I'm currently recompiling a linux distribution for an embedded device
> with a Geode LX processor which can't handle all i686 instructions.
> Now, everything seems to work ok, but there's this nagging feeling
> there could still be binaries with i686 instructions in the result,
> making my fine product go "Illegal instruction" and crash.
Why isn't it enough to do:
objdump --disassemble-all ./my_app | grep -e <<patterns>>
[Hint: all SSE instructions start with 'p' (except a couple MOV*.)]
If the app does Just-In-Time compilation, then of course you must
tell the JIT compiler, too.
--
|
|
From: Torsten L. <ml-...@en...> - 2011-11-22 15:19:52
|
Hello valgrind developers, my apologies in advance about this slightly off-topic post. I'm currently recompiling a linux distribution for an embedded device with a Geode LX processor which can't handle all i686 instructions. Now, everything seems to work ok, but there's this nagging feeling there could still be binaries with i686 instructions in the result, making my fine product go "Illegal instruction" and crash. Since valgrind "parses" binaries while instrumenting them, I figured you had perhaps some ideas how I could find out if there are such time bombs in my final tree. Any help would be greatly appreciated. Regards, Torsten |
|
From: <sv...@va...> - 2011-11-22 14:46:14
|
Author: bart
Date: 2011-11-22 14:41:31 +0000 (Tue, 22 Nov 2011)
New Revision: 12274
Log:
configure: Fix compiler version check. Closes #286384.
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2011-11-20 09:35:51 UTC (rev 12273)
+++ trunk/configure.in 2011-11-22 14:41:31 UTC (rev 12274)
@@ -98,18 +98,21 @@
# We don't want gcc < 3.0
AC_MSG_CHECKING([for a supported version of gcc])
-# Try to get the gcc version, sed-ing out some unexpected stuff
-# that appears with the default gcc on OSX 10.6 and 10.7 respectively.
-# Without this, the version number comes out as 686, 10 or 11 :-(
+# Obtain the compiler version.
#
-# i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
-# i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
+# A few examples of how the ${CC} --version output looks like:
#
+# Arch Linux: i686-pc-linux-gnu-gcc (GCC) 4.6.2
+# Debian Linux: gcc (Debian 4.3.2-1.1) 4.3.2
+# openSUSE: gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
+# Exherbo Linux: x86_64-pc-linux-gnu-gcc (Exherbo gcc-4.6.2) 4.6.2
+# OS/X 10.6: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
+# OS/X 10.7: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
+# Clang: clang version 2.9 (tags/RELEASE_29/final)
+#
[gcc_version=`${CC} --version \
- | head -n 1 \
- | $SED 's/i686-apple-darwin10//' \
- | $SED 's/i686-apple-darwin11//' \
- | $SED 's/^[^0-9]*\([0-9.]*\).*$/\1/'`]
+ | $SED -n -e 's/[^ ]*gcc[^ ]* ([^)]*) \([0-9.]*\).*$/\1/p' \
+ -e 's/[^ ]*clang version \([0-9.]*\).*$/\1/p'`]
is_clang="notclang"
if test "x`${CC} --version | head -n 1 | $SED 's/\(clang\) version.*/\1/'`" = "xclang" ; then
|
|
From: Josef W. <Jos...@gm...> - 2011-11-22 11:34:47
|
On 22.11.2011 06:50, John Reiser wrote: >> Another candidat seems to be the access counters incrementing all the time >> (and the indirection to get to the counters). It should be possible to do one >> counter per side exit, and add up the final counters at the end. > Unfortunately in general Kirchhoff's law does _NOT_ apply to software > because of things like setjmp/longjmp, getcontext/setcontext, exit(), > debuggers, etc. If you want to know how many times something is executed, > then you must count that directly. Hmm. You are right, one has to be careful. For setjmp/longjmp, getcontext/setcontext, and exit(), they are guest instructions doing a control flow change, so they should result in regular (side) exits of a superblock. For these, I do not see a problem. Signals are delivered between execution of superblocks, so these should be fine as well. The problematic case for above strategy are exceptions/traps. In that case, we would not count the executions in a block up to the exception. Hmm.. Cachegrind/Callgrind/Lackey all are buggy in that regard, as they delay the handling of memory accesses by instrumenting callbacks directly before side exits. This not only saves time because of getting rid of saves/restores of registers around each callback (there is nothing to save/restore between multiple callbacks in a row), but more importantly allows merging the events to reduce the number of callbacks. So by incrementing a counter before side exits should give the same result as currently: we already miss simulator calls on exceptions raised in the middle of a block :-( It seems that a tool can catch exceptions. There, it should be able to write compensation code. But to call the missed simulator calls, I am not sure how to get at the arguments saved in temporary registers in the instrumented block ... Josef > |
|
From: John R. <jr...@bi...> - 2011-11-22 05:50:08
|
> Another candidat seems to be the access counters incrementing all the time > (and the indirection to get to the counters). It should be possible to do one > counter per side exit, and add up the final counters at the end. Unfortunately in general Kirchhoff's law does _NOT_ apply to software because of things like setjmp/longjmp, getcontext/setcontext, exit(), debuggers, etc. If you want to know how many times something is executed, then you must count that directly. -- |
|
From: Josef W. <Jos...@gm...> - 2011-11-22 00:41:49
|
On 21.11.2011 21:52, Philippe Waroquiers wrote: >>> So, patch looks good for performance on these systems. >> I did not expect much change at all, so that's good. > I re-runned on ppc64, with --reps=10. This confirms the patch is positive (all the > tests are faster with --reps=10, including ffbench). Good to know. >> It probably makes only sense to apply this patch if I can come up with >> some real optimization. > I understand the code with the patch is nicer (no "huge ugly macro" anymore) > and it is faster. > So, even if you cannot make it even faster, this looks a good thing to apply in any case. Attached two other patches, on top of the previous one: (1) cg-tune.patch: add LIKELY into simulator where it makes sense, and use block numbers as tags (this is always possible) (2) IrX.patch: regular Ir events will never cross cache lines, which allows faster simulation. Use IrX as generic case (rarely). Together (with the macro removal patch), this gives me perl valgrind/perf/vg_perf --vg=valgrind --vg=vg-cgopt --reps=2 --tools=cachegrind valgrind/perf -- Running tests in valgrind/perf ------------------------------------- -- bigcode1 -- bigcode1 valgrind :0.13s ca: 6.9s (53.4x, -----) bigcode1 vg-cgopt :0.13s ca: 5.7s (43.7x, 18.2%) -- bigcode2 -- bigcode2 valgrind :0.14s ca:10.8s (76.9x, -----) bigcode2 vg-cgopt :0.14s ca: 9.7s (69.1x, 10.1%) -- bz2 -- bz2 valgrind :0.66s ca:19.0s (28.8x, -----) bz2 vg-cgopt :0.66s ca:14.7s (22.3x, 22.6%) -- fbench -- fbench valgrind :0.28s ca: 5.4s (19.4x, -----) fbench vg-cgopt :0.28s ca: 4.3s (15.4x, 20.6%) -- ffbench -- ffbench valgrind :0.25s ca: 6.2s (24.8x, -----) ffbench vg-cgopt :0.25s ca: 5.0s (20.0x, 19.5%) -- heap -- heap valgrind :0.10s ca: 5.7s (57.1x, -----) heap vg-cgopt :0.10s ca: 4.2s (41.9x, 26.6%) -- sarp -- sarp valgrind :0.03s ca: 1.4s (47.3x, -----) sarp vg-cgopt :0.03s ca: 1.1s (36.0x, 23.9%) -- tinycc -- tinycc valgrind :0.20s ca:13.1s (65.5x, -----) tinycc vg-cgopt :0.20s ca:11.4s (56.8x, 13.3%) The IrX.patch above is an example of making use of information we know at instrumentation time: that the guest instruction address and length. While data addresses are variable, the length still is fixed, and it could help to instrument a quick check for not crossing cache lines... Another candidat seems to be the access counters incrementing all the time (and the indirection to get to the counters). It should be possible to do one counter per side exit, and add up the final counters at the end. Josef |