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.02 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.