Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Let's analyze move 36

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, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.