TT question?
Posted: Sat May 19, 2012 12:54 pm
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
thanks.
Fermin
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.
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.
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
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.
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.
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.
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