Minic is performing quite well at short TC using a 1024Mb TT. For example, better than Igel, Topple or Asymptote, really near Winter and Zurichess.
Minic is using a 2 buckets (always replace, replace by depth) TT.
But in CCRL test, long TC, smaller TT size, Minic is always under Igel, Topple, ...
I think this might be liked with TT policy and thus I'm looking for advice on the subject. Is there a balanced TT policy that works well at short and long TC and with smaller and bigger TT size ? Is there a clear way to think of this issue, without just testing everything ?
Looking for TT policy advice
Moderators: hgm, Rebel, chrisw
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
-
- Posts: 27807
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Looking for TT policy advice
At short TC the entire tree often fits in the TT, so the replacement algorithm does not matter as it is hardly exercised. My exprience is that you only start to notice a slowdown if you shrink the TT size to less than 10% of the node count, even with rather simple replacement schemes.
For running with very much overloaded TT, it is important to make sure intermediate depth are not completely pushed out of the table: what is not deep enough to fight its way into a depth-preferred slot, will end up in the always-replace slot. There the survival time is very short, as these slots are constantly bombarded by a flood of d=0 (or whetever your lowest stored depth is) entries.
One way around that is allowing shallow entries to replace deeper ones when the depth of the latter is overrepresented in the table. (E.g. when there are more of that depth than d=1 entries.) For this you would have too keep a histogram of table depth, however. An alterative is to use under-cut replacement, where you replace a depth-preferred entry by a new entry of a depth that is equal, higher or exactly one lower. This will eventually flush any depth out of the table, so one should view it as a kind of always-replace slot. But it tends to hang on longer to the deeper entries.
My current favorite scheme is to probe only 3 entries in each bucket; the hash key determining which 3: one that keeps track of the highest depth so far (subject to aging uring game play, but not in analysis), one under-cut slot, and one always-replace slot. If the total number of slots in a bucket is not a multiple of 3, some keys can share some of the entries (e.g. only a single always-replace entry per bucket).
For running with very much overloaded TT, it is important to make sure intermediate depth are not completely pushed out of the table: what is not deep enough to fight its way into a depth-preferred slot, will end up in the always-replace slot. There the survival time is very short, as these slots are constantly bombarded by a flood of d=0 (or whetever your lowest stored depth is) entries.
One way around that is allowing shallow entries to replace deeper ones when the depth of the latter is overrepresented in the table. (E.g. when there are more of that depth than d=1 entries.) For this you would have too keep a histogram of table depth, however. An alterative is to use under-cut replacement, where you replace a depth-preferred entry by a new entry of a depth that is equal, higher or exactly one lower. This will eventually flush any depth out of the table, so one should view it as a kind of always-replace slot. But it tends to hang on longer to the deeper entries.
My current favorite scheme is to probe only 3 entries in each bucket; the hash key determining which 3: one that keeps track of the highest depth so far (subject to aging uring game play, but not in analysis), one under-cut slot, and one always-replace slot. If the total number of slots in a bucket is not a multiple of 3, some keys can share some of the entries (e.g. only a single always-replace entry per bucket).
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Looking for TT policy advice
Thanks for the reply.
I read again my TT code and it is buggy in fact ... I'll fix that and try your advice.
I read again my TT code and it is buggy in fact ... I'll fix that and try your advice.
-
- Posts: 288
- Joined: Sat Jun 30, 2018 10:58 pm
- Location: Ukraine
- Full name: Volodymyr Shcherbyna
Re: Looking for TT policy advice
Hello xr_a_y,
P.S. I see there is some kind of a competition among Topple, Minic and Igel in 2019 regarding the elo gain I am worried
Check out latest Igel 1.9.2, I think I fixed a couple of serious bugs and now in short tc it should perform better than Minic.
P.S. I see there is some kind of a competition among Topple, Minic and Igel in 2019 regarding the elo gain I am worried
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Looking for TT policy advice
Hi
I will thanks.
Don't be, it is a "good" competition, something to keep on working
-
- Posts: 288
- Joined: Sat Jun 30, 2018 10:58 pm
- Location: Ukraine
- Full name: Volodymyr Shcherbyna
Re: Looking for TT policy advice
tc=all/10+0.1
hash=256
hash=256
Code: Select all
Score of Igel 1.9.2 64 POPCNT vs Minic 0.99: 76 - 23 - 43 [0.687] 142
Elo difference: 136.26 +/- 50.01
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Looking for TT policy advice
that makes Igel near 3000, congrats !voffka wrote: ↑Sat Oct 05, 2019 2:58 pm tc=all/10+0.1
hash=256Code: Select all
Score of Igel 1.9.2 64 POPCNT vs Minic 0.99: 76 - 23 - 43 [0.687] 142 Elo difference: 136.26 +/- 50.01
-
- Posts: 288
- Joined: Sat Jun 30, 2018 10:58 pm
- Location: Ukraine
- Full name: Volodymyr Shcherbyna
Re: Looking for TT policy advice
Thanks Vivien. But I am trying to be cautiously optimistic here, because usually Igel does well in my testing, but performs poorly in CCRL across a wide range of engines, so it is too early to tell.xr_a_y wrote: ↑Sat Oct 05, 2019 7:03 pmthat makes Igel near 3000, congrats !voffka wrote: ↑Sat Oct 05, 2019 2:58 pm tc=all/10+0.1
hash=256Code: Select all
Score of Igel 1.9.2 64 POPCNT vs Minic 0.99: 76 - 23 - 43 [0.687] 142 Elo difference: 136.26 +/- 50.01
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Looking for TT policy advice
Here is some input, at TC 40/20sec TT=128Mb
Code: Select all
Rank Name Elo +/- Games Score Draws
1 komodo-13-64-ja 108 23 692 65.1% 28.2%
2 rodentIII 97 21 691 63.6% 34.6%
3 Winter0.7 91 23 691 62.8% 27.5%
4 zurichess-neuchatel 41 21 691 55.9% 36.5%
5 Winter0.6 12 22 691 51.7% 30.5%
6 igel-1.9.2 -3 20 692 49.6% 38.2%
7 minic_0.101 -8 20 690 48.8% 40.9%
8 minic_dev -33 20 691 45.3% 38.8%
9 minic_0.99 -40 21 691 44.3% 37.3%
10 Topple_master -52 21 691 42.6% 32.9%
11 asymptote_v0.6 -61 22 692 41.3% 30.2%
12 igel_1.8.3 -155 24 691 29.0% 23.3%
But at this short TC, Igel 1.9.2 is indeed far better than 1.8.3.
-
- Posts: 585
- Joined: Fri Mar 30, 2018 7:20 am
- Full name: Andreas Matthies
Re: Looking for TT policy advice
Is this really Komodo 13? Only 11 Elo better than Rodent?xr_a_y wrote: ↑Sun Oct 06, 2019 8:41 am
Here is some input, at TC 40/20sec TT=128Mb
Igel 1.9.2 and Minic 0.101 (something that will be release soon under the name Minic1.0) are head to head again and "only" 40elo above Minic 0.99.Code: Select all
Rank Name Elo +/- Games Score Draws 1 komodo-13-64-ja 108 23 692 65.1% 28.2% 2 rodentIII 97 21 691 63.6% 34.6% 3 Winter0.7 91 23 691 62.8% 27.5% 4 zurichess-neuchatel 41 21 691 55.9% 36.5% 5 Winter0.6 12 22 691 51.7% 30.5% 6 igel-1.9.2 -3 20 692 49.6% 38.2% 7 minic_0.101 -8 20 690 48.8% 40.9% 8 minic_dev -33 20 691 45.3% 38.8% 9 minic_0.99 -40 21 691 44.3% 37.3% 10 Topple_master -52 21 691 42.6% 32.9% 11 asymptote_v0.6 -61 22 692 41.3% 30.2% 12 igel_1.8.3 -155 24 691 29.0% 23.3%
But at this short TC, Igel 1.9.2 is indeed far better than 1.8.3.