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
|
|
3
|
4
|
5
(2) |
6
(3) |
7
|
8
(2) |
9
(3) |
|
10
(3) |
11
(5) |
12
(1) |
13
|
14
(21) |
15
(6) |
16
(4) |
|
17
(9) |
18
(13) |
19
(15) |
20
(15) |
21
(11) |
22
(16) |
23
(4) |
|
24
|
25
(8) |
26
(4) |
27
(3) |
28
(1) |
29
|
30
(2) |
|
From: Nicholas N. <nj...@ca...> - 2002-11-27 15:43:19
|
On Wed, 27 Nov 2002, Julian Seward wrote: > Good news. I've just got a variant of forget-all running -- the variant > I mentioned in this thread yesterday, I think. It divides the TC into four > chunks, each of size 4M (for a total TC of 16M, so as to be fair to the > previous measurements). When TC gets full, we throw away the oldest > chunk and start filling that up. This is a crude approximation to FIFO. Nice one. Is the splitting into 4 hard-coded -- have you tried eg. 8? Might make a slight improvement... N |
|
From: Jeremy F. <je...@go...> - 2002-11-27 07:39:48
|
On Tue, 2002-11-26 at 17:09, Julian Seward wrote:
> Good news. I've just got a variant of forget-all running -- the variant
> I mentioned in this thread yesterday, I think. It divides the TC into four
> chunks, each of size 4M (for a total TC of 16M, so as to be fair to the
> previous measurements). When TC gets full, we throw away the oldest
> chunk and start filling that up. This is a crude approximation to FIFO.
Close enough.
> This means FIFO can happen without actually moving any translations
> around. It also means we can dynamically allocate the chunks, so that
> small programs do not suffer the space overhead of allocating the entire
> TC when they will most likely never use it. This is a Good Thing.
Yep (though allocated unused memory just costs page table mappings
rather than real memory).
> (1) we no longer need to mark the current epoch on each TT entry each time
> it is used, saving 2 insns/bb and some mem traffic in the dispatch loop.
> [this is of course the whole point of this exercise, so that t-chaining
> is properly supported]
> (2) I took the opportunity to word-align the starts of the translations,
> which they weren't before. (!)
Yes, that's a good idea. It may be even better to align to a cache line
boundary (worth measuring, anyway).
> (3) the TT entries have shrunk from 16 bytes to 8, reducing Dcache
> thrashing.
Well, the t-chaining patch adds 4 shorts to each TTE, to keep track of
where the jump sites are.
At least as significant as all of these is the horrible cache effects of
moving code around. Reading the instruction stream is moderately bad
(because you end up with aliasing between I & D caches), and writing
into the instruction stream is really nasty.
J
|
|
From: Julian S. <js...@ac...> - 2002-11-27 01:02:29
|
Good news. I've just got a variant of forget-all running -- the variant I mentioned in this thread yesterday, I think. It divides the TC into four chunks, each of size 4M (for a total TC of 16M, so as to be fair to the previous measurements). When TC gets full, we throw away the oldest chunk and start filling that up. This is a crude approximation to FIFO. This means FIFO can happen without actually moving any translations around. It also means we can dynamically allocate the chunks, so that small programs do not suffer the space overhead of allocating the entire TC when they will most likely never use it. This is a Good Thing. Anyway, the good news is > With a 16 MB cache (the default size is 32 M), running kate (69.7 M bbs) > I get (running memcheck) > > LRU 124469 total translations (1.98 M -> 25.2 M), 46.91 seconds > forget-all 144095 total translations (2.31 M -> 29.4 M), 48.40 seconds forget-all 128513 total translations (2.05 M -> 27.3 M), 44.74 seconds in quarters So in terms of translations inadvertantly dumped, this is nearly as good as LRU, and a significant improvement on the utterly braindead algorithm. In speed terms, it's even better. That's probably due to three reasons: (1) we no longer need to mark the current epoch on each TT entry each time it is used, saving 2 insns/bb and some mem traffic in the dispatch loop. [this is of course the whole point of this exercise, so that t-chaining is properly supported] (2) I took the opportunity to word-align the starts of the translations, which they weren't before. (!) (3) the TT entries have shrunk from 16 bytes to 8, reducing Dcache thrashing. And it's all a great deal simpler than it was before. I'm pleased. I'll clean it up and commit it, and then merge in the t-chaining stuff. Then the fast-jcc stuff (another clear win). Then look at SYNCEIP. J |