Computer Chess Club Archives


Search

Terms

Messages

Subject: Crafty modified to Deep Blue - Crafty needs testers to produce outputs

Author: Vincent Diepeveen

Date: 19:59:06 06/16/01


Hello,

From Gian-Carlo i received tonight a cool version of crafty 18.10,
namely a modified version of crafty. The modification was that it
is using a small sense of Singular extensions, using a 'moreland'
implementation.

Not tested for parallel search though,
you might want to check whether it's safe to use his implementation
in such a way that it can be used for SMP usage.

So in short all modifications i did were done on the single cpu
search (search.c).

What i further modified
  - each PV it prints the total number of nodes needed
  - modified tree->searched_nodes to 64 bits number instead of
    a 32 bits number (otherwise it can count only up to 4 billion nodes)
  - i turned off nullmove
  - i turned off hashtable last 6 ply
  - modified all extensions to extend 1 ply (recapture extensions
    being most important, also one reply bla bla i modified etc).
  - to my amazement crafty gets at my PIII800 already around half
    a million nodes a second.

What i didn't do yet is
  - modifying the futility margin in the qsearch, which is
    set at 1 pawn. This means that any move tried in the qsearch
    will only be tried if
      evaluation + expected_move_score + 1 pawn > alpha
    I'm pretty sure that most commercials use around 3 pawns here,
    and several like me simply don't use any futility margin at all.
    Just the thought of it makes me sick in advance. It means that
    you basically say that your evaluation function cannot deliver more
    change in score as 1 pawn, EVEN FROM A CAPTURE MOVE, A CHECKING MOVE,
    OR WHATEVER MOVE. Note that crafty isn't doing checks in qsearch as
    far as i know.
  - undoing possible changes from Gian-Carlo which he forgot
    (i already undid razoring)
  - modifying windowed PVS to normal alfabeta. Though Bob claims this is only
    a 10% loss, that's simply not true for fullwidth search. It's way bigger
    as that. Might be up to 600% (that's it for diep at least).

At this mailing list posting the source + wcrafty.exe is not possible
as the list doesn't accept file transfers. However those who want it
can email me and i'll email it to them.

Note i didn't check so far whether i succeeded in completely turning off
hashtable last 6 plies and/or nullmove search.

Would be appreciated if that gets checked.

Right now for example crafty prints the entire PV and stores it in
arrays, which directly gives it the next recursion an excellent bound.

There are more things which do not compare to hardware, like it can
keep its killermoves, and in hardware you lose all your killermoves of
course each new search on a hardware processor.

I'm running nolot #9 Bxh7 at deep blue crafty now.

Here what diep needs in its default settings (with nullmove
and with SE and with threats and with recaptures
turned on by the way, especially the last probably exploding
the number of nodes here):

150mb hash 2 processors SE enzo. met recaptures
  Proces 1 starting initialisation!
  Proces 1 starting SearchSMP!
Took 0.07 seconds to start all 1 other processes
Process 1: engineflags=0 msk=1
process 0: engineflags = 0 denktime=10000000 maxtime=10000000
00:00 0 0 4 (0) 1 -3.430 Bf6xg7
++ d3-h7
00:00 0 0 12 (0) 1 -1.789 Bd3xh7 Kg8xh7
00:00 0 0 13 (0) 1 0.184 Bf6-d4
00:00 0 0 156 (0) 2 -0.025 Bf6-d4 e6-e5
++ g4-h5
00:00 0 0 349 (0) 2 0.001 Qg4-h5 h7-h6
++ c2-c4
00:00 0 0 457 (0) 2 0.021 c2-c4 e6-e5
00:00 0 0 903 (0) 3 0.302 c2-c4 e6-e5 Bd3-f5
++ g4-h5
00:00 0 0 1154 (0) 3 0.309 Qg4-h5 g7-g6 Qh5-g5
00:00 0 0 3346 (68) 4 0.001 Qg4-h5 h7-h6 Qh5-g4 a7-a5
++ c2-c4
00:00 0 0 6071 (509) 4 0.133 c2-c4 Ra8-c8 Qg4-h5 h7-h6
00:00 0 0 18698 (4612) 5 0.353 c2-c4 Qc7-a5 Bf6-d4 e6-e5 Bd4-e3
00:01 0 0 76226 (30816) 6 0.185 c2-c4 b7-b6 Rd1-e1 Qc7-d6 Bd3-e4 h7-h5
00:05 0 0 309308 (106317) 7 0.379 c2-c4 Qc7-a5 Bd3-c2 e6-e5 Qg4-f5 g7-g6 Qf5-g5
00:09 0 0 616871 (134052) 8 0.247 c2-c4 Qc7-a5 a2-a3 Qa5-c7 Bd3-c2 e6-e5 Bc2-f5
b7-b5
00:46 0 0 3346545 (562046) 9 0.361 c2-c4 e6-e5 Bd3-f5 g7-g6 Bf5-e4 Bf8-c5 Rd1-d2
Qc7-b6 Bf6-g5
01:10 0 0 5268292 (750151) 10 0.194 c2-c4 e6-e5 Bd3-f5 g7-g6 Qg4-h4 Bf8-g7
Bf6xg7 Kg8xg7 Bf5-e4 Ra8-d8
++ d1-e1
05:40 0 0 24878052 (7756367) 10 0.210 Rd1-e1 Qc7-d6 Bf6-e5 Qd6-e7 Be5-d4 g7-g6
c2-c4 Bf8-g7 Bd4xg7 Kg8xg7
09:37 0 0 41922569 (8521909) 11 0.270 Rd1-e1 Qc7-d6 Qg4-h4 h7-h6 Bf6-e5 Qd6-d5
Qh4-e4 Qd5xe4 Bd3xe4 Ra8-d8 Be4xc6
16:26 0 0 71713414 (22314376) 12 0.176 Rd1-e1 Qc7-d6 Ra1-d1 Qd6-a3 Re1-e2 a7-a5
c2-c4 a5-a4 Bf6-b2 Qa3-c5 Bd3-e4 f7-f5
++ c2-c4
25:14 0 0 110060709 (35478661) 12 0.209 c2-c4 e6-e5 Bd3-f5 g7-g6 Bf5-e4 Bf8-c5
Be4xc6 Qc7xc6 Qg4-h4 Bc5-d4 Ra1-c1
59:07 0 0 258829298 (51387644) 13 0.186 c2-c4 e6-e5 Qg4-g3 g7-g6 Bd3-e2 Bf8-g7
Bf6-g5 f7-f6 Bg5-e3 f6-f5 Qg3-g5
++ d3-h7
01:20:25 0 0 352406189 (56809295) 13 1.019 Bd3xh7 Kg8xh7 Qg4-h5 Kh7-g8 Rd1-d4
g7xf6 Rd4-g4 Bf8-g7 Qh5-h6 Kg8-f8 Rg4xg7 Re8-c8 Ra1-d1
01:22:12 0 0 361073942 (57179473) 14 1.019 Bd3xh7 Kg8xh7 Qg4-h5 Kh7-g8 Rd1-d4
g7xf6 Rd4-g4 Bf8-g7 Qh5-h6 Kg8-f8 Rg4xg7 Re8-c8 Ra1-d1

for crafty hash set to 96mb and hashp to 20mb. ponder off. log on.
my estimate is it needs to run with half a million nodes a second here
to get to 40M nodes a second (which is 20% efficiency at 200M nodes a second)
a factor of 80 longer. that's 80 x 3 minutes = 240 minutes = 4 hours.

That's then of course way more efficient nodes in a way more efficient program
as DB ever got.

Black(1): setboard r3rbk1/ppq2ppp/2b1pB2/8/6Q1/1P1B3P/P1P2PP1/R2R2K1 w - - bm B
White(1): d

       +---+---+---+---+---+---+---+---+
    8  | *R|   |   |   | *R| *B| *K|   |
       +---+---+---+---+---+---+---+---+
    7  | *P| *P| *Q|   |   | *P| *P| *P|
       +---+---+---+---+---+---+---+---+
    6  |   |   | *B|   | *P| B |   |   |
       +---+---+---+---+---+---+---+---+
    5  |   |   |   |   |   |   |   |   |
       +---+---+---+---+---+---+---+---+
    4  |   |   |   |   |   |   | Q |   |
       +---+---+---+---+---+---+---+---+
    3  |   | P |   | B |   |   |   | P |
       +---+---+---+---+---+---+---+---+
    2  | P |   | P |   |   | P | P |   |
       +---+---+---+---+---+---+---+---+
    1  | R |   |   | R |   |   | K |   |
       +---+---+---+---+---+---+---+---+
         a   b   c   d   e   f   g   h

White(1): an
Analyze Mode: type "exit" to terminate.
              clearing hash tables
              time surplus   0.00  time limit 30.00 (3:30)
         nss  depth   time  score   variation (1)
    194663      5     0.42   0.90   1. a3 g6 2. Be4 Be7 3. Bxc6 Bxf6 4.
                                    Bxe8 Bxa1
    253580      5     0.56   1.10   1. Re1 Rac8 2. Rad1 h6 3. Bc4
    424722      5->   0.90   1.10   1. Re1 Rac8 2. Rad1 h6 3. Bc4
    799001      6     1.71   0.96   1. Re1 b5 2. c4 h5 3. Qg5 a6 4. cxb5
                                    axb5
   2324186      6->   4.54   0.96   1. Re1 b5 2. c4 h5 3. Qg5 a6 4. cxb5
                                    axb5
   5367226      7    10.35   0.74   1. Re1 g6 2. Rad1 Bg7 3. Bxg7 Kxg7
                                    4. Be4 Rad8
   9282661      7    17.50   0.79   1. Rd2 g6 2. Be4 Bg7 3. Bxc6 Bxf6 4.
                                    Bxe8 Bxa1
  15670914      7->  28.87   0.79   1. Rd2 g6 2. Be4 Bg7 3. Bxc6 Bxf6 4.
                                    Bxe8 Bxa1
  19643474      8    36.84   0.71   1. Rd2 g6 2. Re1 Bh6 3. Rdd1 Qf4 4.
                                    Be5 Qxg4 5. hxg4
  32724304      8     1:02   0.82   1. Re1 g6 2. Rad1 Bg7 3. Bxg7 Kxg7
                                    4. c3 Rad8 5. a3
  69747616      8->   2:10   0.82   1. Re1 g6 2. Rad1 Bg7 3. Bxg7 Kxg7
                                    4. c3 Rad8 5. a3
  92868323      9     2:59   0.70   1. Re1 g6 2. Qd4 Qd6 3. Qc3 Rac8 4.
                                    Bc4 Be7 5. Rad1 Bxf6 6. Qxf6
 243532689      9     7:41   0.77   1. b4 g6 2. b5 Bd7 3. Qc4 Qxc4 4. Bxc4
                                    Bc8 5. Be5 b6
 386315244      9->  11:35   0.77   1. b4 g6 2. b5 Bd7 3. Qc4 Qxc4 4. Bxc4
                                    Bc8 5. Be5 b6
 792312122     10    24:24   0.78   1. b4 e5 2. b5 e4 3. Be2 Re6 4. Bg5
                                    Be8 5. Rac1 Bc5
               10    30:45   2/52?  1. Bxh7+

Of course singular extensions are only done at depths above 6 ply.
Also i do not know whether DB did SE in the root. I guess GCP didn't
implement it like that for crafty. Shouldn't do it either, but at
only above 10 ply depths that means that you have some plydepth
left to trigger loads of expensive researches and extensions.

The first 7 to 9 ply this definitely hardly hurts yet. Of course
the first 7 to 9 ply a big difference with DB is usually that it can profit
from its hashtable and that slowly more processors join in into the
search, where crafty is everywhere very efficiently searching
single cpu.

I doubt for example that DB hardware processors
did researches to get a better first move
to try at a search of a depth 6, 5 etc.
I assume it just searched that 6 ply in hardware (with a
cleaned killermove list etc) and that's it. No
search of 4,5 ply first. Simply that's it. I can't imagine someone
making something tough like this in hardware (tough in hardware)!

Now all we need to do is let crafty search a bunch of positions.
Report the output which it gave after an hour or 4 and then
draw some obvious conclusions about DBs inefficiency.

Best regards,
Vincent





This page took 0.03 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.