Author: Jonas Cohonas
Date: 22:05:49 06/16/01
Go up one level in this thread
On June 16, 2001 at 22:59:06, Vincent Diepeveen wrote: >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 Where can i download this modified Crafty? Regards Jonas
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.