Author: Gerd Isenberg
Date: 10:22:28 10/21/04
Go up one level in this thread
On October 21, 2004 at 12:17:59, Gian-Carlo Pascutto wrote: >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. Yes, but only in main search - in qsearch only the small and local (processor as well as search space) table is used. I mean on a quad opteron NUMA you may have some additional cycles to access memory, allocated by a main thread/process, from the other two near or even one far processors. > >-- >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.