Author: Chris Whittington
Date: 02:05:38 10/08/97
Go up one level in this thread
On October 08, 1997 at 03:06:49, Ed Schröder wrote: > >With Rebel9 Power Analyse I have tested both 36.Qb6 and 36.axb5 till >iteration 17. Results: > >17.00 1.20 Qb6 Rd8 Be4 Qe7 axb5 Rd6 Qa5 >17.00 0.62 axb5 axb5 Qb6 Rxa2 Rxa2 Bc7 Qe6+ > >Both analysis stopped at ply 17 after about 3 hours. > >Does this help you? > >Perhaps you can (again) explain your point of view as I didn't get it. > >What I see is a remarkable score difference of 0.58 which in comparison >with Deep Blue can have many reasons. Please pick a few... > >1.. Perhaps Deep Blue has seen more? >2.. Perhaps Deep Blue evaluation versus Rebel differs a lot? >3.. Perhaps Deep Blue evaluation sucks here? >4.. Perhaps Rebel9 evaluation sucks here? >5.. Perhaps there was a bug? (It wouldn't be the first time) >6.. Perhaps hash collisions? > >My personal opinion... >1. 60% >2. 25% >3. 0% >4. 0% >5. 5% >6. 10% > >Too many explanations to call move 36 fishy :)) > >To point 6 the following... >I always wondered how DB handles hash collisions as with 200,000,000 NPS >you can bet on it that this subject need VERY special attention in my >opinion and is very hard to judge if things are programmed well. > >Rebel on a fast Pc does 100,000 NPS and I sometimes really wonder if >the hash table operates in an acceptable way with 100,000 NPS. After >all with hashing we try to put 64 bytes (the board) into 6-8 bytes (the >hash key). > >As a result (I have tested it) you get many hash collisions even if I >extend the hash key to 8 bytes. This all is with 100,000 NPS. Sure I >have built-in some checks, but is it sufficient to catch them all? > >Now DB is advertised as a 200,000,000 NPS machine. >So 2000 x faster than 100,000 NPS. >So also 2000 times more hash collisions? Its worse than this, no ? Suppose you do P hash indexes per second (P is going to be related to the node rate P, by N=P/4 approx) EACH of these hash indexes has a finite chance of colliding with any other of the hash indexes. For EACH hash index the chance of collision per second will be proportional to P. So for P hash indexes generated per second the chance of any one colliding with any other will be proportional to P^2. So hash collision chances increase with the SQUARE of the node rate. >And is it all handled well? > >And how to judge if hash collisions are handled well? > >In the past I have made a special version to test the hash table which >ALSO stores the whole board in the hash table. Every transposition was >carefully checked with the current board. Problem, a speed decrease of >factor 20-30 or so. Also a very limited hash table size because of the >64 extra bytes for every hash entry. > >Open question: Does our hash table software needs to be polished again >because of todays faster Pc's and bigger Ram? Yes please ...... :) Chris > >- Ed -
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.