Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Basic questions regarding pawn hash

Author: Robert Hyatt

Date: 20:06:30 06/13/04

Go up one level in this thread


On June 13, 2004 at 22:40:08, Uri Blass wrote:

>On June 13, 2004 at 21:47:15, Robert Hyatt wrote:
>
>>On June 13, 2004 at 16:46:14, Tord Romstad wrote:
>>
>>>On June 13, 2004 at 14:24:57, GeoffW wrote:
>>>
>>>>Hi
>>>>
>>>>I was thinking how I would add pawn hashing to my program. Having read a little
>>>>of the Crafty source I have a rough grasp of the idea, however there are a
>>>>couple of things I am hazy on.
>>>>
>>>>Q1)
>>>>I understand the pawn hash score stored must not contain any piece related
>>>>scoring as that must be factored in later. In my program even the simple choice
>>>>of which pawn position look up table is determined by the phase of the game, i.e
>>>>it will be piece dependent. How would I get over that obstacle ? Score the pawns
>>>>for end game, opening and  middle in the hash, and choose which one to use later
>>>>?
>>>
>>>I don't store any scores at all in the pawn hash table, but just lots of
>>>computations
>>>which is used by the evaluation function.  I store things like the location of
>>>all
>>>passed, isolated, double or backward pawns, pawn chains, number of pawns on
>>>black/white squares for both sides, a classification of the centre (open,
>>>closed,
>>>semi-closed, etc.), and so on.
>>>
>>>>Q2)
>>>>Crafty uses an 8 bit bitmap to store file for passers, this is ok for a bitboard
>>>>program as it is probably trivial to find the exact location later. However for
>>>>a non bitboard program it is non trivial to find the exact locations. Do I have
>>>>any alternative but to store the passer locations in the hash ? That would be 16
>>>>bytes just for the passed pawns for both sides?
>>>
>>>My program also doesn't use bitboards.  I simply store all the exact locations.
>>>This is not a problem, you can afford to use lots of space for your pawn hash
>>>table entries.  My entries are 128 bytes big.  Keep in mind that the number of
>>>pawn structures seen in a single search isn't very big, and that this means that
>>>you don't need to store a big number of entries.  I found that increasing the
>>>pawn hash table size beyond 256 entries gave only a tiny increase in speed
>>>(about 3%, IIRC).
>>>
>>>Tord
>>
>>
>>I don't know what kind of tree you are searching, but my numbers are so far off
>>from yours it is not funny:
>>
>>Crafty with 12K pawn hash, 24 bytes per entry, searching initial position with
>>no book for one minute:
>>
>>              time=1:00  cpu=98%  mat=0  n=13646141  fh=88%  nps=227K
>>              ext-> chk=253094 cap=88326 pp=5587 1rep=12141 mate=22
>>              predicted=0  nodes=13646141  evals=5740196  50move=0
>>              endgame tablebase-> probes=0  hits=0
>>              hashing-> 21%(raw) 20%(depth)  99%(sat)  82%(pawn)
>>              hashing-> 0%(exact)  13%(lower)  0%(upper)
>>
>>82% pawn hits.
>>
>>crafty with default 768K pawn hash:
>>
>>              time=1:00  cpu=99%  mat=0  n=17138483  fh=87%  nps=285K
>>              ext-> chk=333036 cap=108663 pp=6360 1rep=16404 mate=34
>>              predicted=0  nodes=17138483  evals=7193047  50move=0
>>              endgame tablebase-> probes=0  hits=0
>>              hashing-> 20%(raw) 19%(depth)  99%(sat)  91%(pawn)
>>              hashing-> 0%(exact)  13%(lower)  0%(upper)
>>
>>91% pawn hits.
>>
>>Crafty with 12M pawn hash:
>>
>>              time=1:00  cpu=99%  mat=0  n=19443424  fh=88%  nps=324K
>>              ext-> chk=391251 cap=121056 pp=7111 1rep=19336 mate=61
>>              predicted=0  nodes=19443424  evals=8055682  50move=0
>>              endgame tablebase-> probes=0  hits=0
>>              hashing-> 20%(raw) 19%(depth)  99%(sat)  95%(pawn)
>>              hashing-> 0%(exact)  13%(lower)  0%(upper)
>>
>>95% pawn hits.  Notice the NPS.  227K, with small hashp, 285K with default, 324K
>>with 12M.  Here is the time to finish 11 ply on my 750mhz laptop:
>>
>>               11->  34.93   0.14   1. e4 Nc6 2. Nf3 e6 3. Nc3 Nf6 4. e5
>>                                    Ng4 5. d4 Bb4 <HT>
>>               11->  27.41   0.14   1. e4 Nc6 2. Nf3 e6 3. Nc3 Nf6 4. e5
>>                                   Ng4 5. d4 Bb4 <HT>
>>               11->  24.39   0.14   1. e4 Nc6 2. Nf3 e6 3. Nc3 Nf6 4. e5
>>                                    Ng4 5. d4 Bb4 <HT>
>>
>>If you only get 3% better after making yours bigger, somehow you and I are doing
>>something so completely different that it boggles the mind.  I got 10% faster
>>going from 3/4M to 12M in the above.  20% going from 12K to 768K.
>>
>>Those are all current crafty on a Sony VAIO 750mhz laptop.
>
>Opening position is not typical position that you search because you are in book
>in that position.
>
>I remember that Tord calculated his result based on a different position when
>some pawns moved so the number of pawn structures is not so big.
>
>Uri

\
Give me a position.  I just tried two others with similar results.  These were
middlegame positions...




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.