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.