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
(5) |
2
(3) |
3
(1) |
4
(4) |
5
(1) |
6
(11) |
7
(5) |
|
8
|
9
(6) |
10
(2) |
11
(10) |
12
|
13
|
14
(4) |
|
15
(7) |
16
(1) |
17
(3) |
18
|
19
|
20
|
21
(1) |
|
22
(1) |
23
|
24
|
25
|
26
|
27
|
28
(4) |
|
29
|
30
|
31
|
|
|
|
|
|
From: Josef W. <Jos...@gm...> - 2002-12-02 22:10:48
|
Hi, recently I checked cachegrind in CVS HEAD. It gives out its information on BB level. E.g. for function foobar(), it gives cost values for foobar, foobar+20, foobar+50. I don't think this is intended, because the results look strange together with the usage of source line granularity. And it skrews up efficiency in the used hashes (35 BBs per source file ??). Its because get_debug_info does a call to the V core which gives back function names with offset. Should I come up with a patch for this? Josef |
|
From: Jeremy F. <je...@go...> - 2002-12-02 10:02:18
|
On Mon, 2002-12-02 at 01:14, Julian Seward wrote:
> Wow, you have a train commute in which you can actually sit down so as
> to use the laptop. Cor. All the folks who commute here <-> London
> (55 miles each way) by train would be jealous. Fortunately not me.
I'm in California. I'm the only person in the state to use public
transport.
> One way to assess this is to run something like the simple loop prog
> I sent in earlier mail, and/or bzip2, which compute for a long time
> without generating any/many translations. If it's only TC flushes
> that hammer us on P4, then the ratios for those progs should match
> more closely the PIII ratios. I might look at this when I get a mo.
Well, I was trying it with a 50 second gcc run (4 seconds native). I
don't know how the working set changed during that run, so maybe it
isn't a good test.
> > I have a partial patch to do something like this. I hijacked VG_(new_emit)
> > by adding the args (Bool emu_flags, FlagSet uses, FlagSet sets). emu_args
> > [...]
> > selectively load and save flags. I haven't got very far with this yet.
>
> Perhaps hang fire on this a couple of days. Last night I started a scheme
> similar to your FPU-liveness thing for eflags, and it got as far as
> delivering me a constant stream of segfaults before I had to give up and
> sleep. I'll try and get it working tonight.
OK. I'll think about MMX some more.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-02 09:06:48
|
[replying to 2 messages at once here] > My desktop machine is a 1.8GHz P4, but its running 2.5, so some things > don't work. Not sure that oprofile is set up, but it shouldn't be hard > to do. > > The machine I do most development on is a 600MHz P3 laptop (mostly > because I seem to do a lot of it on the train). Wow, you have a train commute in which you can actually sit down so as to use the laptop. Cor. All the folks who commute here <-> London (55 miles each way) by train would be jealous. Fortunately not me. > I also followed up your mention of writing within 1k (or 2k) of code in > the trace cache, and it does seem pretty dire. It looks like writing to > memory within a 1k sector of something in the trace cache can cause the > whole trace cache to be dumped. [...] That would also mean that P4 does poorly when running all sort of other dynamic code generation systems (java jits etc) and so if that's the case, which it could well be, there may be stuff out on the web which documents it. I'll have a look. One way to assess this is to run something like the simple loop prog I sent in earlier mail, and/or bzip2, which compute for a long time without generating any/many translations. If it's only TC flushes that hammer us on P4, then the ratios for those progs should match more closely the PIII ratios. I might look at this when I get a mo. > > You'll see I just committed a simple hack which seems to substantially > > mitigate the INCEIP thing; it's a combination of your partial-write idea > > and my always-write-never-add idea. > > So you found that doing the SYNCEIP only-update-when-someone-needs-EIP > wasn't worthwhile? It hardly seemed to make any difference, over several runs of several programs. What is committed now just does one write per INCEIP. I also experimented with a version which did analysis to skip redundant INCEIPs -- in which case the results would have been very similar to your SYNCEIP scheme -- and it made only minor improvements compared with the improvement had from turning read-modify-write (INCEIP) into write (SETEIP, in effect). > I have a partial patch to do something like this. I hijacked VG_(new_emit) > by adding the args (Bool emu_flags, FlagSet uses, FlagSet sets). emu_args > [...] > selectively load and save flags. I haven't got very far with this yet. Perhaps hang fire on this a couple of days. Last night I started a scheme similar to your FPU-liveness thing for eflags, and it got as far as delivering me a constant stream of segfaults before I had to give up and sleep. I'll try and get it working tonight. J |