Author: Robert Hyatt
Date: 13:13:39 03/03/06
Go up one level in this thread
On March 03, 2006 at 13:22:53, Uri Blass wrote: >On March 03, 2006 at 13:05:18, Tord Romstad wrote: > >>On March 03, 2006 at 12:20:43, Tony Werten wrote: >> >>>On March 03, 2006 at 09:46:12, Tord Romstad wrote: >>> >>>>What's the problem with a shared history table? >>> >>>Problem is a big word, it probably isn't that bad. >>> >>>Suppose thread 1 want to add 1 to the counter: >>>1) load memory into register >>>2) add 1 to register >>>3) move register to memory >>> >>>If the thread is interrupted between 1 and 3 and thread 2 adds to the same >>>entry, you have lost 1 add. >> >>Yes, this can happen, of course, but it doesn't bother me at all. >>Who cares if the history counters are only approximately correct? >>The deviations will be really tiny, and I would be very suprised if >>they have any measurable impact on move ordering at all. I really >>don't understand why anybody would want to copy the entire history >>table to each thread at all split points, instead of just sharing it. >> >>Tord > >I see a clear advantage of deterministic search relative to non deterministic >search. > >The advantage is in debugging because there are no mistakes that you cannot >reproduce. > >I wonder if somebody try to have version that is deterministic even with more >than one processor. You can do this, but performance will be horrible. I used to have such an option in Cray Blitz, where the same processor always searched the same branch, and the hash table was completely disabled to avoid the usual race conditions that introduce high levels of non-determinism. But I only used this for debugging, it was hopeless for anything real... > >Of course it is obvious that you will get less speed improvement relative to non >deterministic search but the question is how much less speed improvement. > >Uri
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.