Author: Tim Foden
Date: 00:08:58 12/06/03
Go up one level in this thread
On December 05, 2003 at 18:24:40, Dieter Buerssner wrote: >On December 05, 2003 at 17:37:50, Tim Foden wrote: > >Thanks for your comments (also those, I snipped) > >>On December 05, 2003 at 14:33:26, Dieter Buerssner wrote: >> > >>>> trans: probes=1282039 hits=229767 (17.92%) draft=163348 (12.74%) >>> >>>Do you probe in qsearch? >> >>No. However, probing in the qsearch is something I will still look at sometime, as I took it out a long time ago, and things may have changed since (new hardware, new ideas). Also, I quite like Gian-Carlos idea of having a separate HT for qsearch. >And later ... > >>>163268370 Nodes, 99.50% Leavenodes, 484273 Nodes/sec >>>[ ^^^^^^ ^^ Grrr ..] >> >>:) In GLC this bit (2.1% / 97.9%) gives the % of normal nodes / % of q-nodes. > >I snipped too much, and now I am too lazy, to write it again. These numbers seem >not to fit. Your search showed about 10 times more nodes than HT probes. Here it >is a factor of 50 between qnodes and "normal" nodes ... Nope. You seem to have read something a bit wrong if you think there was a 10:1 ratio of nodes against HT probes... :) Nodes: 60703106, Probes: 1282039 ==> ratio = 2.111982% (~50:1) >>I've experimented with other ways, but so far this is the best I've found in >>GLC. I still want to experiment with some more though (e.g. what about storing >>best 2 moves??, or 3 hash entries in 32 bytes??). > >Without having tried it, I would suspect that having two scores/bounds is more >promising. Your fail high ratios were not bad - would you really expect to make >this much better by having 2 moves to try? Not by much for sure. But a small percentage in better move ordering would cause an exponenial change to the search efficiency (at least I hope so :). >>I would certainly seem to make sense to have all the records for an index be >>bunched close together (rather than in separate tables) so only one read is >>needed... this is still on my todo list! > >It should not be difficult to change. I had 2 tables for a while (very similar >to what you described). I think it was less than 2 hours of programming to get >the "3-entries-in-one-table" approach to work. Performance hit was not high, >however (I had expected more). But it was also on a slow computer (perhaps K6-2 >233, perhaps even on 486), so on current hardware, it could be more significant. Sure, it won't take too long to try it... maybe I'll give it a try sometime this weekend. 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.