I wonder how dual bounds can ever be useful. It seems to me the older bound will almost never have sufficient depth to cause a cutoff. (It also seems doubtful to me that many nodes switch types from AND to OR and back.)Evert wrote:I switched to a dual-bound table a while back, but I haven't really noticed a difference in practice.
Size of Transposition Table Entry
Moderators: hgm, Rebel, chrisw
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Size of Transposition Table Entry
-
- Posts: 276
- Joined: Sat Mar 04, 2017 12:24 pm
- Location: Hungary
Re: Size of Transposition Table Entry
Very good news!cdani wrote:I save a second move to the hash sometimes. Was a little win.BeyondCritics wrote:Where does "secondmove" come from? Or is this a trade secret?
The next Andscacs after 0.92 will be open source. The details will be clear then.
-Tamas
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Size of Transposition Table Entry
Yes, less than 5 elo.Houdini wrote: Houdini 3 and 4 also used a second hash move, it gained a couple of Elo (less than 5 Elo).
I just verified it. Of 13147907 operations of saving hash, only 464 had a second move. Is much less than what I supposed!Houdini wrote: Surprisingly few entries actually contained a second move, did you ever verify the statistics on that?
Nice! I bet that is king safety related I thought about it many times, and is in the list of things to try seriously. Sure I will do it And I think I will be able to maintain both informations.Houdini wrote: In Houdini 5 and 6 I've dumped the second move in favor of some evaluation-related information, which proved to be a more profitable usage.
Daniel José - http://www.andscacs.com
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Size of Transposition Table Entry
Well, the idea was that they could be helpful for analysis in "worst case" positions. In practice it doesn't seem to help much (not that it hurts either).syzygy wrote:I wonder how dual bounds can ever be useful. It seems to me the older bound will almost never have sufficient depth to cause a cutoff. (It also seems doubtful to me that many nodes switch types from AND to OR and back.)Evert wrote:I switched to a dual-bound table a while back, but I haven't really noticed a difference in practice.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: Size of Transposition Table Entry
With evaluation-related information perhaps you mean you store the static eval in TT? C'mon don't be shy, you can say it....hey, now that I look better....we also do that:Houdini wrote: In Houdini 5 and 6 I've dumped the second move in favor of some evaluation-related information, which proved to be a more profitable usage.
Code: Select all
/// TTEntry struct is the 10 bytes transposition table entry, defined as below:
///
/// key 16 bit
/// move 16 bit
/// value 16 bit
/// eval value 16 bit
/// generation 6 bit
/// bound type 2 bit
/// depth 8 bit
What a nice surprise! We got the same idea
We store entries in a single cluster aligned and within the cache size:
Code: Select all
struct Cluster {
TTEntry entry[ClusterSize];
char padding[2]; // Align to a divisor of the cache line size
};
static_assert(CacheLineSize % sizeof(Cluster) == 0, "Cluster size incorrect");
-
- Posts: 3232
- Joined: Mon May 31, 2010 1:29 pm
- Full name: lucasart
Re: Size of Transposition Table Entry
Storing the static eval in the TT is not a SF invention, if that's what you're trying to insinuate. It was there in Glaurung. It was there in Fruit long before, and I'm sure it was there in Crafty long before, and others too. It's one of the oldest tricks in the book. And so is cache line alignment.mcostalba wrote:With evaluation-related information perhaps you mean you store the static eval in TT? C'mon don't be shy, you can say it....hey, now that I look better....we also do that:Houdini wrote: In Houdini 5 and 6 I've dumped the second move in favor of some evaluation-related information, which proved to be a more profitable usage.
Code: Select all
/// TTEntry struct is the 10 bytes transposition table entry, defined as below: /// /// key 16 bit /// move 16 bit /// value 16 bit /// eval value 16 bit /// generation 6 bit /// bound type 2 bit /// depth 8 bit
What a nice surprise! We got the same idea
We store entries in a single cluster aligned and within the cache size:
So it is fetched in one go and storing the first bytes in the first word and other pseudo-smart tweaks don't have any advantage apart an obvious slowdown and useless increased complexity (as 99% of all so called optimizations are).Code: Select all
struct Cluster { TTEntry entry[ClusterSize]; char padding[2]; // Align to a divisor of the cache line size }; static_assert(CacheLineSize % sizeof(Cluster) == 0, "Cluster size incorrect");
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Size of Transposition Table Entry
Of course. Robert means something different.lucasart wrote: Storing the static eval in the TT is not a SF invention, if that's what you're trying to insinuate. It was there in Glaurung. It was there in Fruit long before, and I'm sure it was there in Crafty long before, and others too. It's one of the oldest tricks in the book. And so is cache line alignment.
Daniel José - http://www.andscacs.com
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: Size of Transposition Table Entry
Glaurung didn't need to do it becuase it was evaluating only at the leafs. But of course it is not a SF novelity.lucasart wrote:It was there in Glaurung.
-
- Posts: 1471
- Joined: Tue Mar 16, 2010 12:00 am
Re: Size of Transposition Table Entry
Don't be such an ass, please. You can do better than that.mcostalba wrote:With evaluation-related information perhaps you mean you store the static eval in TT? C'mon don't be shy, you can say it....hey, now that I look better....we also do that:
Houdini 5 and 6 store threat-related and king safety info in the hash table.
-
- Posts: 1471
- Joined: Tue Mar 16, 2010 12:00 am
Re: Size of Transposition Table Entry
Surprising, isn't it?cdani wrote:I just verified it. Of 13147907 operations of saving hash, only 464 had a second move. Is much less than what I supposed!
The most astonishing is that even this extremely low fill ratio produces some measurable Elo gain!