Author: mike schoonover
Date: 23:06:48 06/16/01
Go up one level in this thread
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 :)
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.