Author: Gerd Isenberg
Date: 12:53:00 10/20/04
Go up one level in this thread
On October 20, 2004 at 03:39:31, Gian-Carlo Pascutto wrote: >On October 20, 2004 at 02:27:19, martin fierz wrote: > >>so i want to store the move itself in the hashtable instead of the moveindex >>now, as probably everybody is doing. > >Naah. > >>the question i have is this: should i stick >>with two separate tables for QS and main search? or should i just use a single >>big table (seems more sensible to me). or should i do no hashing at all in QS? >>any opinions on this? > >One table vs two tables seems like a clear case for one table to me (what would >two tables gain, except less efficiency?). hmm... probably reducing latency and/or tlb-misses. I guess that is specially an issue with a shared table in a multi-threaded environment. Remember Vincent's huge "latencies" with huge tables >= 512MByte. If you use that only in main search > 0, it doesn't matter so much. For qsearch a small (a few 100K) thread-local allways replace table may have some advantages - at least in my dumb program ;-) Gerd > >To hash or not to hash, that must be *tested*. > >-- >GCP
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.