What is the reason for not using transposition table in quiesce search? most programs don't use it, but I have seen very few that use it.
thanks.
Fermin
TT question?
Moderators: hgm, Rebel, chrisw
-
- Posts: 620
- Joined: Fri Feb 08, 2008 10:44 am
- Location: Madrid - Spain
-
- Posts: 5647
- Joined: Tue Feb 28, 2012 11:56 pm
Re: TT question?
Probing the transposition table in the quiesce search will hurt nps, but should lower total node count. So it's a trade-off. For engines that don't do it, the effective gain was likely found to be negative.Kempelen wrote:What is the reason for not using transposition table in quiesce search? most programs don't use it, but I have seen very few that use it.
Another reason could be that storing results in the transposition table during the quiesce search will more quickly fill the table thereby preventing more valuable information from being stored. However, that can be remedied by a proper replacement strategy.
-
- Posts: 28123
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: TT question?
I probe TT in QS because it speeds up all my engines (time-to-depth-wise). I guess it would be the same for others that do it, as it is easy enough to not do it.
-
- Posts: 1822
- Joined: Thu Mar 09, 2006 11:54 pm
- Location: The Netherlands
Re: TT question?
Oh dear. 'lowering the total node count' is never the goal. Lowering time is the goal. Especially near the qsearch this is a crucial difference.syzygy wrote:Probing the transposition table in the quiesce search will hurt nps, but should lower total node count. So it's a trade-off. For engines that don't do it, the effective gain was likely found to be negative.Kempelen wrote:What is the reason for not using transposition table in quiesce search? most programs don't use it, but I have seen very few that use it.
Another reason could be that storing results in the transposition table during the quiesce search will more quickly fill the table thereby preventing more valuable information from being stored. However, that can be remedied by a proper replacement strategy.
Let me give a simple example with Diep. Note Diep is using transpositiontables everywhere of course.
Some years ago i did do next statistics. If in Diep i do not use nullmove at depthleft == 1, then total node count decreases nearly 20%.
If in Diep i do use nullmove at depthleft == 1, total nodecount increases nearly 20%, but time to ply reduces by exactly 20%.
So time to ply always is the superior measure here.
-
- Posts: 1822
- Joined: Thu Mar 09, 2006 11:54 pm
- Location: The Netherlands
Re: TT question?
10-20% decrease in time by using transpositiontables in qsearch for Diep.Kempelen wrote:What is the reason for not using transposition table in quiesce search? most programs don't use it, but I have seen very few that use it.
thanks.
Fermin
-
- Posts: 5647
- Joined: Tue Feb 28, 2012 11:56 pm
Re: TT question?
This is why I mentioned the word trade-off. It's a trade-off between lower nps and lower total number of nodes for the same depth. So I was already talking about time-to-ply.diep wrote:Oh dear. 'lowering the total node count' is never the goal. Lowering time is the goal. Especially near the qsearch this is a crucial difference.
Here it is. In general, it is not. Tweaking null-move parameters and other reductions will also affect the quality of a fixed-depth search. In that case, time-to-ply isn't telling you the whole story anymore.So time to ply always is the superior measure here.
-
- Posts: 3238
- Joined: Mon May 31, 2010 1:29 pm
- Full name: lucasart
Re: TT question?
Yes, that's a good summary.syzygy wrote:Probing the transposition table in the quiesce search will hurt nps, but should lower total node count. So it's a trade-off. For engines that don't do it, the effective gain was likely found to be negative.Kempelen wrote:What is the reason for not using transposition table in quiesce search? most programs don't use it, but I have seen very few that use it.
Another reason could be that storing results in the transposition table during the quiesce search will more quickly fill the table thereby preventing more valuable information from being stored. However, that can be remedied by a proper replacement strategy.
Currently I'm probing the TT at every QS node. I've now started an experiment: use TT only at depth 0 (root move of the QS where my QS behaves differently as it generates some quiet checks). It seems to hurt very slightly time to depth wise, but perhaps that would be compensated (especially at long time controls) by the TT getting filled up slower. Although in theory my TT replacement strategy should compensate this.
Well, only testing will tell: running 1000 games at 12"+0.2" with 32 MB Hash.
-
- Posts: 3238
- Joined: Mon May 31, 2010 1:29 pm
- Full name: lucasart
Re: TT question?
Both versions were close, but the test version was slightly weaker (below error bar). So I'd rather keep the original version where I use TT in all QS nodes.lucasart wrote:Yes, that's a good summary.syzygy wrote:Probing the transposition table in the quiesce search will hurt nps, but should lower total node count. So it's a trade-off. For engines that don't do it, the effective gain was likely found to be negative.Kempelen wrote:What is the reason for not using transposition table in quiesce search? most programs don't use it, but I have seen very few that use it.
Another reason could be that storing results in the transposition table during the quiesce search will more quickly fill the table thereby preventing more valuable information from being stored. However, that can be remedied by a proper replacement strategy.
Currently I'm probing the TT at every QS node. I've now started an experiment: use TT only at depth 0 (root move of the QS where my QS behaves differently as it generates some quiet checks). It seems to hurt very slightly time to depth wise, but perhaps that would be compensated (especially at long time controls) by the TT getting filled up slower. Although in theory my TT replacement strategy should compensate this.
Well, only testing will tell: running 1000 games at 12"+0.2" with 32 MB Hash.
-
- Posts: 1334
- Joined: Sun Jul 17, 2011 11:14 am
Re: TT question?
FruitFly probes (doesn't write) the TT, and uses that as a guided stand-pat.
One experiment I did in the abandoned firstchess based magic was giving QS a dedicated TT. I guess that might be something to try again, if only for the move ordering benefits.
Matthew:out
One experiment I did in the abandoned firstchess based magic was giving QS a dedicated TT. I guess that might be something to try again, if only for the move ordering benefits.
Matthew:out
Some believe in the almighty dollar.
I believe in the almighty printf statement.
I believe in the almighty printf statement.
-
- Posts: 454
- Joined: Sat Apr 04, 2009 6:44 pm
- Location: Bulgaria
Re: TT question?
For me in particular, the reason is that I don't see any benefit for using the main transposition table for that purpose elowise. When I refresh my attempts on the subject /which I did extensively in the past/ and came up with an useful implementation, that could change though.Kempelen wrote:What is the reason for not using transposition table in quiesce search? most programs don't use it, but I have seen very few that use it.
thanks.
Fermin