For or against the transposition table probe in quiet search?

[AndrewGrant]

I am for probing, not storing, but only after extensive testing at various time controls and degrees of hash pressure.

[RubiChess]

I'm doing both probing and storing. Probably not tested as much as you did.

[Joost Buijs]

It depends upon how fast your evaluation function is. If it's very fast and simple probing in quiescence is counter productive, with a slow evaluation function like NNUE it certainly helps. I always found probing (and storing) in quiescence to be better, even with my HCE.

I never tested it with more than 32 threads though.

[jstanback]

I store and probe at depth == 0. I only store positions where a move gave a cutoff. This seemed a bit better, but I didn't do much testing with lots of threads or with limited HT size.

John

[abulmo2]

My two related chess engines have a divergent opinion about this:

• Amoeba: for
• Dumb: against

The difference between Amoeba and Dumb is the speed of the evaluation function, fast for Dumb, and slow for Amoeba. So, for Amoeba, it is worth caching all these slow computations through a transposition table, but not for Dumb.

[Desperado]

For or against the transposition table probe in quiet search?

Well, there is not only black and white. Beside technical implementation details like HGM described you can check for some conditions
before probing the TT. Like with other techniques (e.g. quiet checks in qs) you can limit lookups depth dependent for example
or any other restriction which might be useful in your opinion. Using TT logic when entering qs (depth == 0) seems pretty normal today.

Beside the speed efford, the replacement scheme might be very important in this context.
From my point of view, more valuable nodes can be overwritten with entries from the quiescent search very often.

All in all, TT speed, TT information and the criteria when to use it make it work or not.

With information i mean for example:
Maybe it is important how much the effect of move ordering will have, so how important it is that there is a move in TT.
Many engines keep a bestmove that was best at some other point in the search, instead of overwriting it with an empty slot.

Today i use a mix of always replace / depth scheme. (basic,simple and requires aging).
I only use TT when entering the quiescence and i keep best moves before writing an empty slot (upperbound node).

On the other hand, i never got it to work in my old engine.

If you get it to work you might achieve 10 or 20 elo (i guess).

[MartinBryant]

Over the years the TT has been in and out of the QS in Colossus.
It's currently in.
The last time I tested taking it out (about 2 years ago) it was a noticeable ELO loss (but admittedly on a rather short test run).
On my test set of positions it saves about 9% of the node count.
About 23% of the QS nodes get succesfully returned by the TT value.
I've just started another test going... I'll report back tomorrow.

Also, FWIW, Stockfish appears to use TT in the QS.

[lucasart]

For or against the transposition table probe in quiet search?

For.

It's not even close. Testing shows a clear regression if you remove HT from QS.

[MartinBryant]

Ok... so I played a match between Colossus with the TT in the QS vs without.
Result was +44 ELO after 1280 games (+/-19 ELO @ 99% confidence, LOS 100%)
So clearly a benefit to Colossus which is currently using a very simple PST eval during this new development phase.