Looking for TT policy advice

[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?

[xr_a_y]

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.

[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).

[xr_a_y]

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.

[voffka]

xr_a_y ,

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

[xr_a_y]

xr_a_y ,

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.

[xr_a_y]

xr_a_y ,

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.

[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.

[xr_a_y]

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