Author: Vincent Diepeveen
Date: 15:19:56 03/13/03
from the engine message list: I showed crafty 18.15 SMP had at several positions a 1.0 speedup at 2 processors when using no asymmetric king safety at a bunch of positional LCTII positions. But later experiments revealed that speedup was 1.4 when i redid experiments with the asymetric king safety at the SAME positions with the same version in fact. Same *.exe actually. This was *both* done at the same dual K7. Same hardware. You didn't deny back then that that difference was there, instead YOU SAID ALL MY EXPERIMENTS WERE NOT VALID BECAUSE I RAN AT INFERIOR DUAL AMD K7 HARDWARE instead of the outdated quad xeon you had back then, which i do not own of course. So you have to show the opposite at the same number of positions (i tested LCTII middlegame positions), to proof the opposite for the current crafty 19.3 versions. Until then your claim is proved by testing 30 game positions, you write just words here. As usual nothing is scientific proven with you. Your data in ICCA journal clearly showing that you invent the numbers yourself. So no one can believe your words at all. Of course you will have to use middlegame positions where clearly the king safety is an important influence. If you take first 10 positions from BS2830 that's fine with me too. BUT DO THE EXPERIMENT WITH THE CURRENT VERSION NOT with a 'temporarily new' VERSION WHERE ASYMETRIC KING SAFETY IS REDEFINED AS BEING THE SAME AS THE NORMAL KING SAFETY. Below the middlegame positions in LCTII. I removed the *FIN positions which is endgame positions where king safety is less relevant. r3kb1r/3n1pp1/p6p/2pPp2q/Pp2N3/3B2PP/1PQ2P2/R3K2R w KQkq solution d6 LCTPOS01 d5d6 1k1r3r/pp2qpp1/3b1n1p/3pNQ2/2pP1P2/2N1P3/PP4PP/1K1RR3 b LCTPOS02 (...Bb4!) d6b4 r6k/pp4p1/2p1b3/3pP3/7q/P2B3r/1PP2Q1P/2K1R1R1 w LCTPOS03 (Qc5!) f2c5 1nr5/2rbkppp/p3p3/Np6/2PRPP2/8/PKP1B1PP/3R4 b LCTPOS04 (....e5!) e6e5 2r2rk1/1p1bq3/p3p2p/3pPpp1/1P1Q4/P7/2P2PPP/2R1RBK1 b LCTPOS05 (...Bb5!) d7b5 3r1bk1/p4ppp/Qp2p3/8/1P1B4/Pq2P1P1/2r2P1P/R3R1K1 b LCTPOS06 (...e5!) e6e5 r1b2r1k/pp2q1pp/2p2p2/2p1n2N/4P3/1PNP2QP/1PP2RP1/5RK1 w LCTPOS07 (Nd1!) c3d1 r2qrnk1/pp3ppb/3b1n1p/1Pp1p3/2P1P2N/P5P1/1B1NQPBP/R4RK1 w LCTPOS08 (Bh3!) g2h3 5nk1/Q4bpp/5p2/8/P1n1PN2/q4P2/6PP/1R4K1 w LCTPOS09 (Qd4!) a7d4 r3k2r/3bbp1p/p1nppp2/5P2/1p1NP3/5NP1/PPPK3P/3R1B1R b kq LCTPOS10 (...Bf8!) e7f8 bn6/1q4n1/1p1p1kp1/2pPp1pp/1PP1P1P1/3N1P1P/4B1K1/2Q2N2 w LCTPOS11 (h4!) h3h4 3r2k1/pp2npp1/2rqp2p/8/3PQ3/1BR3P1/PP3P1P/3R2K1 b LCTPOS12 (...Rb6!) c6b6 1r2r1k1/4ppbp/B5p1/3P4/pp1qPB2/2n2Q1P/P4PP1/4RRK1 b LCTPOS13 (...Nxa2!) c3a2 r2qkb1r/1b3ppp/p3pn2/1p6/1n1P4/1BN2N2/PP2QPPP/R1BR2K1 w kq LCTPOS14 (d5!) a2a4 1r4k1/1q2bp2/3p2p1/2pP4/p1N4R/2P2QP1/1P3PK1/8 w LCTCMB01 (Nxd6!) c4d6 rn3rk1/pbppq1pp/1p2pb2/4N2Q/3PN3/3B4/PPP2PPP/R3K2R w KQ LCTCMB02 (Qxh7!) h5h7 4r1k1/3b1p2/5qp1/1BPpn2p/7n/r3P1N1/2Q1RPPP/1R3NK1 b LCTCMB03 (...Qf3!) f6f3 2k2b1r/1pq3p1/2p1pp2/p1n1PnNp/2P2B2/2N4P/PP2QPP1/3R2K1 w LCTCMB04 (exf6!) e5f6 2r2r2/3qbpkp/p3n1p1/2ppP3/6Q1/1P1B3R/PBP3PP/5R1K w LCTCMB05 (Rxh7!) h3h7 2r1k2r/2pn1pp1/1p3n1p/p3PP2/4q2B/P1P5/2Q1N1PP/R4RK1 w k LCTCMB06 (exf6!) e5f6 2rr2k1/1b3ppp/pb2p3/1p2P3/1P2BPnq/P1N3P1/1B2Q2P/R4R1K b LCTCMB07 (...Rxc3!) c8c3 2b1r1k1/r4ppp/p7/2pNP3/4Q3/q6P/2P2PP1/3RR1K1 w LCTCMB08 (Nf6!) d5f6 6k1/5p2/3P2p1/7n/3QPP2/7q/r2N3P/6RK b LCTCMB09 (...Rxd2!) a2d2 rq2rbk1/6p1/p2p2Pp/1p1Rn3/4PB2/6Q1/PPP1B3/2K3R1 w LCTCMB10 (Bxh6!) f4h6 rnbq2k1/p1r2p1p/1p1p1Pp1/1BpPn1N1/P7/2P5/6PP/R1B1QRK1 w LCTCMB11 (Nxh7!) #25 g5h7 r2qrb1k/1p1b2p1/p2ppn1p/8/3NP3/1BN5/PPP3QP/1K3RR1 w LCTCMB12 (e5!) e4e5 If you do not like the outcome of the speedup results, but say 'this is because of the positions being too easy to solve' then also try the bs2830 testset, you will see speedup there will be more horrible for crafty: 4r1k1/p1pb1ppp/Qbp1r3/8/1P6/2Pq1B2/R2P1PPP/2B2RK1 b - - 0 2 Qxf3 1 d3f3 7r/2qpkp2/p3p3/6P1/1p2b2r/7P/PPP2QP1/R2N1RK1 b - - 0 2 f5 2 f7f5 r1bq1rk1/pp4bp/2np4/2p1p1p1/P1N1P3/1P1P1NP1/1BP1QPKP/1R3R2 b - - 0 2 Bh3+ or Bg4+ 3 c8h3 8/2kPR3/5q2/5N2/8/1p1P4/1p6/1K6 w - - 0 2 Nd4 4 f5d4 2r1r3/p3bk1p/1pnqpppB/3n4/3P2Q1/PB3N2/1P3PPP/3RR1K1 w - - 0 2 Rxe6 5 e1e6 8/2p5/7p/pP2k1pP/5pP1/8/1P2PPK1/8 w - - 0 2 f3 6 f2f3 8/5p1p/1p2pPk1/p1p1P3/P1P1K2b/4B3/1P5P/8 w - - 0 2 b4 7 b2b4 rn2r1k1/pp3ppp/8/1qNp4/3BnQb1/5N2/PPP2PPP/2KR3R b - - 0 2 Bh5 8 g4h5 r3kb1r/1p1b1p2/p1nppp2/7p/4PP2/qNN5/P1PQB1PP/R4R1K w kq - 0 2 Nb1 9 c3b1 r3r1k1/pp1bp2p/1n2q1P1/6b1/1B2B3/5Q2/5PPP/1R3RK1 w - - 0 2 Bd2 10 b4d2 r3k2r/pb3pp1/2p1qnnp/1pp1P3/Q1N4B/2PB1P2/P5PP/R4RK1 w kq - 0 2 exf6 11 e5f6 r1b1r1k1/ppp2ppp/2nb1q2/8/2B5/1P1Q1N2/P1PP1PPP/R1B2RK1 w - - 0 2 Bb2 12 c1b2 rnb1kb1r/1p3ppp/p5q1/4p3/3N4/4BB2/PPPQ1P1P/R3K2R w KQkq - 0 2 O-O-O 13 e1c1 r1bqr1k1/pp1n1ppp/5b2/4N1B1/3p3P/8/PPPQ1PP1/2K1RB1R w - - 0 2 Nxf7 14 e5f7 2r2rk1/1bpR1p2/1pq1pQp1/p3P2p/P1PR3P/5N2/2P2PPK/8 w - - 0 2 Kg3 15 h2g3 8/pR4pk/1b6/2p5/N1p5/8/PP1r2PP/6K1 b - - 0 2 Rxb2 16 d2b2 r1b1qrk1/ppBnppb1/2n4p/1NN1P1p1/3p4/8/PPP1BPPP/R2Q1R1K w - - 0 2 Ne6 17 c5e6 8/8/4b1p1/2Bp3p/5P1P/1pK1Pk2/8/8 b - - 0 2 g5 18 g6g5 r3k2r/pp1n1ppp/1qpnp3/3bN1PP/3P2Q1/2B1R3/PPP2P2/2KR1B2 w kq - 0 2 Be1 19 c3e1 r1bqk2r/pppp1Npp/8/2bnP3/8/6K1/PB4PP/RN1Q3R b kq - 0 2 O-O 20 e8g8 r4r1k/pbnq1ppp/np3b2/3p1N2/5B2/2N3PB/PP3P1P/R2QR1K1 w - - 0 2 Ne4 21 c3e4 r2qr2k/pbp3pp/1p2Bb2/2p5/2P2P2/3R2P1/PP2Q1NP/5RK1 b - - 0 2 Qxd3 22 d8d3 5r2/1p4r1/3kp1b1/1Pp1p2p/2PpP3/q2B1PP1/3Q2K1/1R5R b - - 0 2 Rxf3 23 f8f3 8/7p/8/7P/1p6/1p5P/1P2Q1pk/1K6 w - - 0 2 Ka1 24 b1a1 r5k1/p4n1p/6p1/2qPp3/2p1P1Q1/8/1rB3PP/R4R1K b - - 0 2 Rf8 25 a8f8 1r4k1/1q2pN1p/3pPnp1/8/2pQ4/P5PP/5P2/3R2K1 b - - 0 2 Qd5 26 b7d5 2rq1rk1/pb3ppp/1p2pn2/4N3/1b1PPB2/4R1P1/P4PBP/R2Q2K1 w - - 0 2 d5 27 d4d5 At 08:41 AM 3/13/2003 -0600, Robert M. Hyatt wrote: >On Thu, 13 Mar 2003, Vincent Diepeveen wrote: > >> >> cache line length at DDR ram is 64 bytes. So that's exactly 4 probes of 16 >> bytes. >> then simply pick entry with smallest count (where count is defined for >> example like: "number of plies played in game + depthleft). Overwrite that >> one. >> Always overwrite. >\ > >DDRAM doesn't have a "cache line size". The cache line size is >dictated by the _processor_. In the case of the pentium IV it is >64 bytes and 128 bytes for L1 and L2. That is regardless of >whether the processor has DDR ram, RDRAM, or whatever you care to >stick on it. The cache is _inside_ the microprocessor chip, not >inside the memory stuff... > > > >> >> You can give it less nice names too, but then i would get back 10 replies >> of Hyatt to this posting which isn't the intention. > > >Actually you wouldn't. I think most everyone can now recognize >nonsense without my pointing it out. > > >> >> Anyway we talk about nonsense anyway, easiest way to search deep is a very >> simplistic evaluation which always gives a cutoff (like crafty). If you >> make eval very elementary like always returning 0, then see what search >> depth you get then. > >That is simply disinformation. Try searching with an evaluation that >is _very_ simple, based only on material. You will _not_ search deeper. >In the case of Crafty, it would be about 2x _faster_ which would make >the search go a bit deeper, but _not_ for the nonsensical reason you >are giving. > >BTW I play sometimes without the asymmetric king safety and it does >_not_ change the parallel search performance. Sometimes I wonder if >you and I live in the same universe as your physical laws seem >different than those _I_ have to deal with. > > > > > >> >> try openings position and select always pawn a2 - a3 and then b2-b3 etc. >> >> 30 ply? >> >> 40 ply? > >No and No. > > >> >> as long as it researches the same search space, that's what matters. >> so hashtable+nullmove do the job there. >> >> R=2 or R=3 is no big deal then. >> >> When you add mobility to your eval, then move ordering gets more difficult. >> >> As you do not always get a cutoff just like that. More difficult evaluation >> means more problems ordering moves. You gotta do effort for move ordering >> then. And a good qsearch is required anyway. >> >> here is what diep needs. With singular extensions. with R=3 and with a huge >> qsearch: >> >> let's select some position in a middlegame where things aren't very clear >> yet and failing high to mate some opponent is not going to happen. Of >> course you only must take care to test positions where your engine sucks. >> If you have positions where it plays brilliant, no need to search >> efficiently there! >> >> Here diep sucks cuz it wants to play cxd5? and castle long directly after >> that. >> >> Therefore i took this position also. Best move is e3 >> >> diep - fritz (ipccc 2003) : >> >> after 1.d4,nf6 2.c4,e6 3.Nc3,Bb4 4.Qc2,O-O 5.a3,Bxc3+ 6.Qxc3,b6 7.Bg5,Bb7 >> 8.f3,h6 9.Bh4,d5: >> >> Took 0.11 seconds to start all 1 other processes out of 2 >> 00:00 43 0k 0 0 43 (2) 2 (0,0) -0.455 c4xd5 Bb7xd5 >> ++ e1-c1 procnr=0 terug=-409 org=[-455;-454] newwindow=[-455;520000] >> 00:00 115 0k 0 0 115 (2) 2 (0,0) -0.409 O-O-O Nb8-c6 >> 00:00 774 1k 0 0 774 (2) 3 (0,2) -0.239 O-O-O d5xc4 e2-e3 >> ++ e2-e3 procnr=1 terug=-183 org=[-239;-238] newwindow=[-239;520000] >> 00:00 186200 186k 0 0 1862 (2) 3 (1,5) 0.024 e2-e3 d5xc4 Bf1xc4 >> 00:00 94966 95k 0 0 2849 (2) 4 (1,8) -0.339 e2-e3 d5xc4 O-O-O g7-g5 >> 00:00 89273 89k 0 0 13391 (2) 5 (5,51) -0.089 e2-e3 c7-c5 O-O-O Nb8-c6 >> d4xc5 b >> 6xc5 c4xd5 Nf6xd5 Bh4xd8 Nd5xc3 >> 00:00 104275 104k 0 0 29197 (2) 6 (8,75) -0.171 e2-e3 c7-c5 O-O-O Nb8-d7 >> Ng1-h3 >> Qd8-c7 >> 00:00 117555 118k 0 0 111678 (2) 7 (13,150) -0.064 e2-e3 c7-c5 d4xc5 b6xc5 >> Bh4xf >> 6 Qd8xf6 Qc3xf6 g7xf6 c4xd5 Bb7xd5 >> 00:02 106735 107k 0 0 291389 (2) 8 (33,321) -0.277 e2-e3 d5xc4 Bf1xc4 c7-c5 >> O-O- >> O c5xd4 Rd1xd4 Nb8-d7 >> ++ c4-d5 procnr=1 terug=-274 org=[-277;-276] newwindow=[-277;520000] >> 00:04 114853 115k 0 0 489278 (2) 8 (42,385) -0.154 c4xd5 e6xd5 O-O-O Rf8-e8 >> e2-e >> 3 Nb8-d7 Kc1-b1 c7-c5 >> 00:07 131301 131k 0 0 942742 (2) 9 (108,662) -0.029 c4xd5 e6xd5 O-O-O >> Nb8-d7 e2- >> e3 Rf8-e8 Kc1-b1 c7-c6 g2-g3 >> 00:12 142974 143k 0 0 1760020 (2) 10 (144,909) -0.198 c4xd5 e6xd5 O-O-O >> Nb8-d7 e >> 2-e3 Rf8-e8 Rd1-e1 c7-c5 Bf1-b5 c5-c4 >> 00:52 151428 151k 0 0 7972708 (2) 11 (455,2309) -0.001 c4xd5 e6xd5 O-O-O >> Rf8-e8 >> e2-e3 Qd8-e7 Rd1-e1 Bb7-a6 Ng1-h3 Ba6xf1 Rh1xf1 >> 01:46 147869 148k 0 0 15786599 (2) 12 (671,3607) -0.112 c4xd5 e6xd5 e2-e3 >> Rf8-e8 >> O-O-O Qd8-e7 Rd1-e1 Nb8-d7 Kc1-b1 Nf6-e4 Bh4xe7 Ne4xc3 Kb1-c2 Re8xe7 Kc2xc3 >> 06:10 149205 149k 0 0 55226860 (2) 13 (1493,7550) -0.027 c4xd5 e6xd5 e2-e3 >> Nb8-d >> 7 O-O-O c7-c5 Kc1-b1 Ra8-c8 d4xc5 b6xc5 Kb1-a1 Qd8-e7 Bf1-b5 >> 11:48 149858 150k 0 0 106234891 (2) 14 (2237,11525) -0.168 c4xd5 e6xd5 >> e2-e3 Nb8 >> -d7 Ng1-h3 c7-c5 Bf1-b5 g7-g5 Bh4-f2 a7-a6 Bb5-e2 c5xd4 Qc3xd4 Ra8-c8 >> >> You see. No forward pruning. Heavy extensions and as you can see in this >> position loads of moves to try in the huge qsearch DIEP has (up to 32 >> checks it can see in qsearch!!) and a slow eval (just 140k+ nps at 2 >> processors). Also first 10 ply a considerable parallel loss because >> hashtable isn't filled yet. >> >> Now let's try the public beancounter: >> >> I just have crafty 18.15 modified to print nodes (19.3 doesn't compile SMP >> here as i just got visual c++ and gcc installed). As we know you can only >> finish a ply when no thread is searching, so it is impossible that the >> number of nodes printed is actually incorrect. Also the first mainline at a >> ply you are garantueed that the other first moves are not split yet, so it >> is garantueed there too that the number of nodes printed is correct: >> >> The public beancounter has next advantages to DIEP when talking about >> number of nodes needed. In theory that is: >> - a) simplistic qsearch. NO checks. not even check evasions last time i >> checked. >> - b) nearly everything that wins a pawn gives a cutoff. >> - c) it hardly doubts. diep above doubts first few ply between cxd5 and >> e3, that's >> *bad*. Of course when crafty doubts that's *bad* too for its >> branching factor. >> - d) no singular extensions everywhere. Very little extensions compared >> to DIEP. >> - e) this version has inline assembly for locking. latest 19.x versions >> suck ass >> for dual K7 at that point, they are just intel optimized (bad thing >> for specint program). In fact it just compiles on and for intel c++ >> compiler when run SMP. intel c++ compiler version 6 and up are noticably >> slower at non-intel hardware... > > >_all_ versions of crafty have inline asm for locking. _every_ one >that has been distributed from version 15.0 onward. Care to explain >what you are talking about??? > > > > >> - f) not doing Singular Extensions in every position means the advantage >> crafty has there is pretty big for its speedup. If you add SE to crafty >> you'll see its speedup gets a lot worse... ...not to mention searchdepth >> >> Disadvantages: >> - a) overhead of parallel search is bigger because it is a faster program > >Yes, my overhead is maybe 5% out of a total of 400%. That is _very_ >high. :) > > > >> - b) i put it in analysis mode here which is fairer as then the asymetric >> code >> is turned off. I call that a fairer compare because diep has *nowhere* >> asymetric evaluation >> - c) it is R=3/2, diep is just R=3 >> - d) 18.xx is slightly more relying upon speed of Level caches than 19.xx >> is, >> because only 19.xx has a new hashtable implementation which i only >> proposed >> hyatt to implement for a year or 2 before he did a few months ago. > >That is simply false. This new hash approach was written about two >years ago, as you well know. It does _not_ use any suggestions you have >made because it is _still_ the same identical algorithm used in 18.x >with a small change to be more cache friendly. But if you drop the new >hash probe code into an 18.x version the node counts will be _identical_ >but the speed is about 1% faster. > > > > >> - e) not using asymetrich king safety is very very very bad for your nps >> > >That is simply crap. Two tests: > >with normal king safety to depth=12, four positions, average NPS: 1914K >with symmetric safety to depth=12 four positions, average NPS: 1963K > >Sometimes your statements are so outlandish you ought to be embarassed >to make them. > >_anybody_ can try the above test... > >pick a test position (or run the bench command) normally. Then run it >again but first enter "eval asym 0" to eliminate the asymmetric king >safety stuff and run it again. Here is the bench output for asymmetric >on and asymmetric off, using the bench command so _anybody_ can do this. >I even ran it with just one processor so that non-SMP users can confirm >that these numbers are real and your comments are nonsense. > >Asymmetric bench = 1.07M > symmetric bench = 1.08M > >Here is the raw bench output, normal first, symmetric second: > >Crafty v19.4 (1 cpus) > >White(1): bench >Running benchmark. . . >...... >Total nodes: 100478644 >Raw nodes per second: 1068921 >Total elapsed time: 94 > > > asym 0 >middle-game phase > clearing hash tables >modified king-safety values: >white: 0 4 15 24 36 42 54 72 81 90 99 108 117 126 135 144 > 148 152 156 160 164 168 172 175 180 180 180 180 180 180 180 180 > 180 180 180 180 180 180 180 180 180 180 180 180 180 180 180 180 > 180 180 180 180 180 180 180 180 180 180 180 180 180 180 180 180 > >black: 0 4 15 24 36 42 54 72 81 90 99 108 117 126 135 144 > 148 152 156 160 164 168 172 175 180 180 180 180 180 180 180 180 > 180 180 180 180 180 180 180 180 180 180 180 180 180 180 180 180 > 180 180 180 180 180 180 180 180 180 180 180 180 180 180 180 180 >White(1): bench >Running benchmark. . . >...... >Total nodes: 99227961 >Raw nodes per second: 1078564 >Total elapsed time: 92 > >So, your statements are crap. Your conclusions are crap. Etc. > > > > >> Now let's not gossip too much and just let it run: >> >> hash table memory = 384M bytes. >> pawn hash table memory = 6M bytes. >> pondering disabled. >> noise level set to 1. >> >> Crafty v18.15 (1 cpus) >> >> White(1): ponder off >> pondering disabled. >> White(1): mt 2 >> max threads set to 2 >> White(1): reada >> type "exit" to terminate. >> read.White(1): d4 >> read.Black(1): Nf6 >> read.White(2): c4 >> read.Black(2): e6 >> read.White(3): Nc3 >> read.Black(3): Bb4 >> read.White(4): Qc2 >> read.Black(4): O-O >> read.White(5): a3 >> read.Black(5): Bxc3 >> read.White(6): Qxc3 >> read.Black(6): b6 >> read.White(7): Bg5 >> read.Black(7): Bb7 >> read.White(8): f3 >> read.Black(8): h6 >> read.White(9): Bh4 >> read.Black(9): d5 >> read.White(10): exit >> White(10): d >> >> +---+---+---+---+---+---+---+---+ >> 8 | *R| *N| | *Q| | *R| *K| | >> +---+---+---+---+---+---+---+---+ >> 7 | *P| *B| *P| | | *P| *P| | >> +---+---+---+---+---+---+---+---+ >> 6 | | *P| | | *P| *N| | *P| >> +---+---+---+---+---+---+---+---+ >> 5 | | | | *P| | | | | >> +---+---+---+---+---+---+---+---+ >> 4 | | | P | P | | | | B | >> +---+---+---+---+---+---+---+---+ >> 3 | P | | Q | | | P | | | >> +---+---+---+---+---+---+---+---+ >> 2 | | P | | | P | | P | P | >> +---+---+---+---+---+---+---+---+ >> 1 | R | | | | K | B | N | R | >> +---+---+---+---+---+---+---+---+ >> a b c d e f g h >> >> White(10): >> >> White(10): analyze >> 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) >> starting thread 1 >> 559 1 0.04 0.00 10. e3 >> 611 1-> 0.11 0.00 10. e35 >> 805 2 0.12 -0.28 10. e3 Nbd7 >> 1183 2-> 0.19 -0.28 10. e3 Nbd7 >> 1775 3 0.20 -0.22 10. e3 dxc4 11. Bxc4 Nbd7 >> 2923 3-> 0.26 -0.22 10. e3 dxc4 11. Bxc4 Nbd7 >> 7804 4 0.29 -0.16 10. e3 Nbd7 11. Nh3 Qe7 >> 10287 4-> 0.34 -0.16 10. e3 Nbd7 11. Nh3 Qe7 >> 22099 5 0.37 -0.18 10. e3 Nc6 11. Nh3 Ba6 12. b3 <HT> >> 35662 5-> 0.44 -0.18 10. e3 Nc6 11. Nh3 Ba6 12. b3 <HT> >> 117137 6 0.53 -0.16 10. e3 Nbd7 11. Nh3 Ba6 12. b3 dxc4 >> 13. bxc4 >> 169131 6-> 0.65 -0.16 10. e3 Nbd7 11. Nh3 Ba6 12. b3 dxc4 >> 13. bxc4 >> 428603 7 0.95 -0.21 10. e3 Ba6 11. Rc1 Bxc4 12. Bxc4 dxc4 >> 13. Qxc4 c6 14. Bxf6 Qxf6 >> 197508 7 1.25 -0.16 10. cxd5 Bxd5 11. Rc1 Bc6 12. e3 a5 >> 13. Bd3 Ra7 >> 694587 7-> 1.31 -0.16 10. cxd5 Bxd5 11. Rc1 Bc6 12. e3 a5 >> 13. Bd3 Ra7 >> 1135903 8 1.78 -0.10 10. cxd5 exd5 11. Bxf6 Qxf6 12. Qxc7 >> Bc6 13. Qe5 Nd7 14. Qxf6 Nxf6 >> 1290008 8-> 2.00 -0.10 10. cxd5 exd5 11. Bxf6 Qxf6 12. Qxc7 >> Bc6 13. Qe5 Nd7 14. Qxf6 Nxf6 >> 2637829 9 3.22 -0.04 10. cxd5 Bxd5 11. Nh3 Nbd7 12. Qc2 >> Bb7 13. e4 e5 14. Bxf6 Nxf6 15. dxe5 >> 2793307 9-> 3.44 -0.04 10. cxd5 Bxd5 11. Nh3 Nbd7 12. Qc2 >> Bb7 13. e4 e5 14. Bxf6 Nxf6 15. dxe5 >> 6525803 10 6.73 -0.04 10. cxd5 exd5 11. Bxf6 Qxf6 12. Qxc7 >> Bc6 13. Rc1 Re8 14. Nh3 Qe6 15. Nf4 >> Qe3 >> 7199512 10-> 7.44 -0.04 10. cxd5 exd5 11. Bxf6 Qxf6 12. Qxc7 >> Bc6 13. Rc1 Re8 14. Nh3 Qe6 15. Nf4 >> Qe3 >> 16903700 11 15.76 0.01 10. cxd5 Bxd5 11. Nh3 Nbd7 12. Qc2 >> c5 13. e4 Bb7 14. e5 g5 15. exf6 gxh4 >> 18098248 11-> 16.89 0.01 10. cxd5 Bxd5 11. Nh3 Nbd7 12. Qc2 >> c5 13. e4 Bb7 14. e5 g5 15. exf6 gxh4 >> 54093818 12 49.75 -0.26 10. cxd5 exd5 11. Bxf6 Qxf6 12. Qxc7 >> Ba6 13. Qe5 Qc6 14. Qf4 Rc8 15. Rd1 >> Nd7 16. e4 Bxf1 17. Kxf1 >> 26589149 12 1:38 -0.19 10. c5 bxc5 11. Qxc5 Nbd7 12. Qc3 Rc8 >> 13. Bf2 Nh5 14. Qa5 Ra8 15. Rc1 Nb6 >> 16. e4 >> 39524901 12 1:58 -0.07 10. e3 Ba6 11. Nh3 Nbd7 12. b3 dxc4 >> 13. Bxc4 Bxc4 14. Qxc4 c5 15. O-O cxd4 >> 16. Qxd4 Rc8 >> 131169166 12-> 1:58 -0.07 10. e3 Ba6 11. Nh3 Nbd7 12. b3 dxc4 >> 13. Bxc4 Bxc4 14. Qxc4 c5 15. O-O cxd4 >> 16. Qxd4 Rc8 >> 261420438 13 3:51 -0.02 10. e3 Nbd7 11. c5 bxc5 12. dxc5 c6 >> 13. Nh3 Re8 14. Bg3 e5 15. Be2 Qe7 >> 16. b4 Rad8 >> 271593488 13-> 4:01 -0.02 10. e3 Nbd7 11. c5 bxc5 12. dxc5 c6 >> 13. Nh3 Re8 14. Bg3 e5 15. Be2 Qe7 >> 16. b4 Rad8 >> 371440200 14 5:27 -0.11 10. e3 Nbd7 11. cxd5 Nxd5 12. Bxd8 >> Nxc3 13. Bxc7 Nd5 14. Bd6 Nxe3 15. >> Bxf8 Nc2+ 16. Kd2 Nxa1 17. Bd6 Rc8 >> 544973707 14-> 8:01 -0.11 10. e3 Nbd7 11. cxd5 Nxd5 12. Bxd8 >> Nxc3 13. Bxc7 Nd5 14. Bd6 Nxe3 15. >> Bxf8 Nc2+ 16. Kd2 Nxa1 17. Bd6 Rc8 >> 15 10:15 1/32? 10. e3 >> >> Not bad nah from diep if you see this output of crafty. >> >> A program doing 544973707 nodes in 8:01 or on average ==> 1.1MLN nodes a >> second. >> >> Diep is like 8 times slower in NPS, but despite crafty efficient search >> compared to yours, still diep is effectively needing about a factor 4 less >> nodes at 14 ply. > >So? What is the _point_ to compare depth to depth, since the programs >extend differently? That is a flawed comparison, and you _know_ it is >a flawed comparison. Compare the above to the time it takes ChessMaster >to get to depth=14, for example, to see how stupid the comparison >_really_ is. > > > >> >> Not bad if you consider SE costs me in this position i estimate a ply or 2 >> at 14 ply depth. >> > >Not bad if pigs could fly and Knuth/Moore didn't know what they were >talking about either. Unfortunately both are false. > >Notice that _my_ data is based on multiple positions, not on a position >_you_ choose to make your statements look good. Of course, I'm sure you >won't understand that. > > > > >-- >Robert Hyatt Computer and Information Sciences >hyatt@cis.uab.edu University of Alabama at Birmingham >(205) 934-2213 115A Campbell Hall, UAB Station >(205) 934-5473 FAX Birmingham, AL 35294-1170 > > >To post a message, send it to: chess-engines@eGroups.com > >To unsubscribe, send a blank message to: chess-engines-unsubscribe@eGroups.com > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > > > >
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.