When do you probe the EGTB

[mathmoi]

Hi,

I just implemented Gaviota's EGTB (Thanks Miguel) for MatMoi and now I need to decide when do I probe in the tree.

I suppose it would not be wise to probe at all nodes. I'm thinking maybe I could probe only when the remaining depth is > X. Is this what I should do?

Also, I see there are two kind of probe that can be done, soft and hard. If I understand correctly, the soft one only probe the cache and should be faster, so maybe I should hard probe when depth > X and soft probe when depth > (X + Y), where Y is somthing like 2 or 3.

Any idea?

[michiguel]

Hi,

I just implemented Gaviota's EGTB (Thanks Miguel) for MatMoi and now I need to decide when do I probe in the tree.

I suppose it would not be wise to probe at all nodes. I'm thinking maybe I could probe only when the remaining depth is > X. Is this what I should do?

Also, I see there are two kind of probe that can be done, soft and hard. If I understand correctly, the soft one only probe the cache and should be faster, so maybe I should hard probe when depth > X and soft probe when depth > (X + Y), where Y is somthing like 2 or 3.

Any idea?

I guess this is very dependent on the engine. In gaviota I probe soft everywhere except qsearch, and I probe hard when depth is > 2. In your scheme, y = 0 and x = 2. I do not even know if this is the optimum for gaviota. I think that for a more selective and faster engine, those numbers should be a bit bigger.

Also consider that there will be another two type of ways to probe besides hard and soft.
tb_probe_WDL_hard and tb_probe_WDL_soft. They are like the previous two, but it returns only whether the position is won, draw or loss, not the number of plies to mate.

So, you may want to probe "WDL", and not the normal ones, when alpha and beta are not in the "mate" range. In other words, any info that is won, draw or a loss, will be useul and enough for a cutoff (or to just ignore the result). In those situations, you do not need to know the distance to mate. This is like probing bitbases. The advantage of doing this, is that it is a good hint for the library to economize cache memory behind the curtains (or to have bitbases, who knows!), improving hit rate, and speeding up the TBs. I have not formally announced this two functions in the website, but they are available here:

http://github.com/michiguel/Gaviota-Tablebases

or a direct link
http://github.com/michiguel/Gaviota-Tab ... ves/master

However, those are not implementing any performance improvement yet (they call the normal functions behind the curtains) but they will very soon. In fact, I already implemented a bitbase-like cache that stores bitbase information produced on the fly. The net effect is that the cache memory becomes 8x more effective. I am going to test it a little and then release it. In the meantime, you can start implementing in your program a WDL probe too when it is appropriate.

Miguel

[mathmoi]

Hi Miguel,

Thanks for the info. So I've got the right idea, altough you seem to probe more agressively than I though was possible, I guess I'll have to do some test with differents values for X and Y ans compare the difference "elo-wise".

Thanks,

[michiguel]

Hi Miguel,

Thanks for the info. So I've got the right idea, altough you seem to probe more agressively than I though was possible, I guess I'll have to do some test with differents values for X and Y ans compare the difference "elo-wise".

Thanks,

Maybe a quicker and dirtier approximation will be to choose a bunch of positions with ~9 pieces (including kings), and chose X and Y that gives the shortest time to reach depth N.

Miguel