Author: Gian-Carlo Pascutto
Date: 09:17:59 10/21/04
Go up one level in this thread
On October 20, 2004 at 15:53:00, Gerd Isenberg wrote: >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 ;-) Well, you need to get two cachelines instead of one. So it's not so obvious to me that even then it would be better. -- 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.