Author: Jonas Cohonas
Date: 23:11:02 06/16/01
Go up one level in this thread
On June 17, 2001 at 02:06:48, mike schoonover wrote: >On June 17, 2001 at 01:05:49, Jonas Cohonas wrote: > >>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 > > > >buy a book.download a web page.get a JOB. >toodles >mike >:) Well thank you mike for the insightful reply that must have taken a lot of brainpower to come up with such genius, oh i do have a JOB so now i only need to buy a book and download a webpage hmmmm 1 out of 3 ain't bad. 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.