Page 1 of 1

Enhanced Transposition Cutoff

Posted: Tue Apr 10, 2007 2:54 pm
by kongsian
Hi. I've just added ETC to my engine. However my gains are very minor; about 1% less nodes and a fraction faster on a set of mate-in-4 problems.

So naturally I would like to know what kind of improvement other authors are seeing by implementing ETC.

Also which free source engines have implemented ETC?

Thanks.
Kong Sian

Re: Enhanced Transposition Cutoff

Posted: Tue Apr 10, 2007 5:21 pm
by Steve Maughan
ETC works best when there are many possible transpositions e.g. pawn endings. In the middle game you're not going to see much of an improvement. I think your stats are to be expected for middlegame positions.

Fruit is a good source of an ETC implementation, although IIRC v 1.0 has a bug in the ETC section.

Best regards,

Steve

Re: Enhanced Transposition Cutoff

Posted: Tue Apr 10, 2007 5:35 pm
by Michael Sherwin
My investigation of ETC has led me to the belief (could be a falicious one) that the slower the engine is the more it can benifit from ETC. My program RomiChess is hurt by ETC because, its node rate is high due to the fact that the endleaf eval is 95% pawn structure code and is terse and the pawn code is hashed.

Any paper I have read on ETC has called it a minor improvement, so it would be expected that the gains if any would be minor.

Re: Enhanced Transposition Cutoff

Posted: Tue Apr 10, 2007 8:24 pm
by bob
kongsian wrote:Hi. I've just added ETC to my engine. However my gains are very minor; about 1% less nodes and a fraction faster on a set of mate-in-4 problems.

So naturally I would like to know what kind of improvement other authors are seeing by implementing ETC.

Also which free source engines have implemented ETC?

Thanks.
Kong Sian
I had poor results as well. It made the tree slightly smaller, but the speed went down also as I had to take the entire move list, and compute an updated hash signature and do those extra table probes to check for a hit. Bottom line was that it was slightly slower overall and I discarded it. Note that was several years ago, so re-running the experiment might be worthwhile, but I have not done so.

Re: Enhanced Transposition Cutoff

Posted: Fri Apr 13, 2007 3:21 pm
by smcracraft
kongsian wrote:Hi. I've just added ETC to my engine. However my gains are very minor; about 1% less nodes and a fraction faster on a set of mate-in-4 problems.

So naturally I would like to know what kind of improvement other authors are seeing by implementing ETC.

Also which free source engines have implemented ETC?

Thanks.
Kong Sian
I am not impressed with ETC.

Much ado about nothing.

Full of sound and fury.

Signifying nothing.

Re: Enhanced Transposition Cutoff

Posted: Sat Apr 14, 2007 10:01 am
by pijl
kongsian wrote:Hi. I've just added ETC to my engine. However my gains are very minor; about 1% less nodes and a fraction faster on a set of mate-in-4 problems.

So naturally I would like to know what kind of improvement other authors are seeing by implementing ETC.
The Baron is using ETC and gets a minor improvement (similar to the one you found). I do restrict ETC and only apply it when there is potentially something significant to gain, otherwise it is too expensive. So depth left is by default set to 4 ply and I only attempt it at expected cut nodes.
There are some situations where ETC helps significantly and that is basically why I keep it in. I also believe (did not measure it) that my SMP with shared hashtable benefits from it.
Richard.

Re: Enhanced Transposition Cutoff

Posted: Sat Apr 14, 2007 11:38 am
by hgm
All my engines use IID, and I guess that this is automatically upward compatible with ETC: as in any node the search (after static move ordering) starts at d=1 (i.e. the replies to all moves are searched to QS level), it probes the hash in the daughter nodes for any position that can be reached. If the probe misses, it generates the entry by doing a QS.

So after the first IID pass, all hash entries of the daughter nodes have been probed. Unless a cutoff occurs earlier, of course.