Author: Tim Foden
Date: 00:57:23 07/12/03
Go up one level in this thread
On July 11, 2003 at 09:02:03, Grzegorz Sidorowicz wrote: >[d]8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - Ealier versions of GLC also had a problem with this position. For instance, GLC 2.18 only found the solution at 25 ply after over 3 minutes on an AXP 1.47GHz. I'm still not entirely sure what was wrong, but it was solved when I made changes to the hash table lookup. I have been using a dual-table approach (primary depth based, secondary always replace) for a long time now, but only recently did I realise that I was using the information in the hash table less than optimally. I was looking for a hash-key match, first in the primary table, and then in the secondary table. If a found a match, I returned the record straight away. The major change I made recently, was that if a primary table match didn't cause a cut-off, I also probed the secondary table, to see if it's record could cause a cut-off. GLC 3.00 now solves this in 0.04 seconds at 22 ply (same hardware). That said, if you aren't seeing the solution by 26 ply, then you quite likely have some other problem than just hashing. Cheers, Tim.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.