Gosh, I don't give a crap if you're convinced or not. I'm merely reporting what I've done and what I've seen. I never claimed that each half of STM would see absolutely equal use, but in practice they effectively will in any variable depth search.syzygy wrote:So no tests of the effect on playing strength.sje wrote:By activating the various metrics counters for utilization, inserts, probes, matches, etc.syzygy wrote:How did you test?sje wrote:Actually, it is; at least in my tests. And it will be true in any program with a variable depth search regardless of the origin(s) of the variability.syzygy wrote:Pre-determining which half of the hash table will be used for white and which for black will decrease the efficiency of the hash table. "about" the same usage is not enough.sje wrote:Another idea is to split the table into two equal size tables; one for WTM, the other for BTM. I've done this and it has worked well. In a program with a variable search depth, both tables see about the same usage regardless of the root STM.
It is intuitively obvious that splitting the table in two and dedicating one half to white-to-move and the other to black-to-move is suboptimal, because white-to-move hash pressure and black-to-move hash pressure will not always be equal. Testing is not really needed to confirm this. Only if you could get a speed up by splitting the table might it be different, but a speed up you won't get.
Statistics suggesting that things tend to average out somewhat don't really convince me, I'm afraid.
Using side to move as a separate bit in hash key
Moderators: hgm, Rebel, chrisw
-
- Posts: 4675
- Joined: Mon Mar 13, 2006 7:43 pm
Re: Splitting the table
-
- Posts: 5563
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Splitting the table
That's fine with me. But why go through the trouble of posting that info?sje wrote:Gosh, I don't give a crapsyzygy wrote:Statistics suggesting that things tend to average out somewhat don't really convince me, I'm afraid.