Page 3 of 3

Re: Looking for TT policy advice

Posted: Fri Oct 11, 2019 6:56 pm
by voffka
Vivien,

Have you considered that the problem with long TC is not related to hash usage but rather to prunning conditions that are triggered differently in longer controls?

Re: Looking for TT policy advice

Posted: Fri Oct 11, 2019 7:51 pm
by xr_a_y
voffka wrote:
Fri Oct 11, 2019 6:56 pm
Vivien,

Have you considered that the problem with long TC is not related to hash usage but rather to prunning conditions that are triggered differently in longer controls?
I cannot really answer yes to that question ... It may indeed be the case. Are you thinking of a particular parameter ?

I thought TT was a good candidate because with the used replacement scheme.

Re: Looking for TT policy advice

Posted: Fri Oct 11, 2019 10:36 pm
by hgm
Why would you want to store the score part? A hash move should always be searched first. An age field would be useless on an always-replace (or an under-cut) slot. And two bits would probably be large enough for it, so it could be easily packed with the bound-type flag, (whick also only needs 2 bits).

Re: Looking for TT policy advice

Posted: Sat Oct 12, 2019 6:05 am
by xr_a_y
hgm wrote:
Fri Oct 11, 2019 10:36 pm
Why would you want to store the score part? A hash move should always be searched first. An age field would be useless on an always-replace (or an under-cut) slot. And two bits would probably be large enough for it, so it could be easily packed with the bound-type flag, (whick also only needs 2 bits).
You are right, I was too lazy and use the main move packing also inside TT. Test in progress now with a smaller entry size.

Re: Looking for TT policy advice

Posted: Wed Oct 16, 2019 3:29 pm
by voffka
xr_a_y ,
xr_a_y wrote:
Fri Oct 11, 2019 7:51 pm
I cannot really answer yes to that question ... It may indeed be the case. Are you thinking of a particular parameter ?
I thought TT was a good candidate because with the used replacement scheme.
I think instead of spending significant time on some idea it may be worth rechecking it: if you think Topple and Igel are better in longer tc and the suspect is use of hash, re-compile them both without hash (and some other engines) and run tests in faster time control without hash (Minic, Topple, Igel, some other engines?): this will at least give you a hint if you are going a right direction.

My intiution tells me that after you run the preliminary tests you will discover that hash usage is not a culprit. When I solved that Igel problem at short time control, it was an eval problem related to stupid me doing popcount on an uninitialized variable :)

Re: Looking for TT policy advice

Posted: Wed Oct 16, 2019 5:19 pm
by xr_a_y
voffka wrote:
Wed Oct 16, 2019 3:29 pm
xr_a_y ,
xr_a_y wrote:
Fri Oct 11, 2019 7:51 pm
I cannot really answer yes to that question ... It may indeed be the case. Are you thinking of a particular parameter ?
I thought TT was a good candidate because with the used replacement scheme.
I think instead of spending significant time on some idea it may be worth rechecking it: if you think Topple and Igel are better in longer tc and the suspect is use of hash, re-compile them both without hash (and some other engines) and run tests in faster time control without hash (Minic, Topple, Igel, some other engines?): this will at least give you a hint if you are going a right direction.

My intiution tells me that after you run the preliminary tests you will discover that hash usage is not a culprit. When I solved that Igel problem at short time control, it was an eval problem related to stupid me doing popcount on an uninitialized variable :)
Thanks for the advice, i'll run no-TT little tourney.

Re: Looking for TT policy advice

Posted: Thu Oct 17, 2019 5:55 am
by xr_a_y
xr_a_y wrote:
Wed Oct 16, 2019 5:19 pm
voffka wrote:
Wed Oct 16, 2019 3:29 pm
xr_a_y ,
xr_a_y wrote:
Fri Oct 11, 2019 7:51 pm
I cannot really answer yes to that question ... It may indeed be the case. Are you thinking of a particular parameter ?
I thought TT was a good candidate because with the used replacement scheme.
I think instead of spending significant time on some idea it may be worth rechecking it: if you think Topple and Igel are better in longer tc and the suspect is use of hash, re-compile them both without hash (and some other engines) and run tests in faster time control without hash (Minic, Topple, Igel, some other engines?): this will at least give you a hint if you are going a right direction.

My intiution tells me that after you run the preliminary tests you will discover that hash usage is not a culprit. When I solved that Igel problem at short time control, it was an eval problem related to stupid me doing popcount on an uninitialized variable :)
Thanks for the advice, i'll run no-TT little tourney.
So a first test, with only 1Mb TT for everybody gave very poor results for Minic (at least -150elo very others usually at same level). So not having a big enough TT is very bad for Minic. I'll check without TT code next.

Re: Looking for TT policy advice

Posted: Sun Oct 20, 2019 5:44 pm
by voffka
150 elo diff sounds like an engine playing without any TT at all. I remember measuring the impact of tt in Igel since I completely re-written it since the fork from Greko.

Re: Looking for TT policy advice

Posted: Sun Oct 20, 2019 6:12 pm
by xr_a_y
voffka wrote:
Sun Oct 20, 2019 5:44 pm
150 elo diff sounds like an engine playing without any TT at all. I remember measuring the impact of tt in Igel since I completely re-written it since the fork from Greko.
Everybody had a 1Mb TT during this test. So there are two possibilities :
- either Minic TT policy is stupid for small TT
- or Minic has a serious bug that is mostly hidden by big TT