Author: Robert Hyatt
Date: 05:19:42 06/01/99
Go up one level in this thread
On June 01, 1999 at 06:32:05, Bernhard Bauer wrote: >On June 01, 1999 at 02:18:27, Eugene Nalimov wrote: > >>1. Chess program searches much faster when one move is significally better than >>all others - there are a lot of cutoffs in the tree, "fast" evaluation is >>sufficient, null move works almost each time, etc. >> >>2. Crafty 16.6 sees right move in that position early because of the poor moves >>ordering. When it started to consider the right move, it's effective search >>depth is much higher, because to necesary information is stored in the hash >>table. And it's stored there because program earlier evaluated (and discarded) a >>line that resulted in the same board position. >> >>3. Due to the modifications made in parallel search in 16.8 (it splits tree at >>the root, if I remember it correctly), it now considers right move *before* >>considering the bad move that nevertheless stores necessary information in the >>hash tables. >> >>4. So, till ply 26, 16.8 has no move that is much better than all other moves. >>That is why it takes 16.8 much longer to go to some depth compared to 16.6. >> >>Eugene >> > >Practically that means that you cannot use Crafty 16.8 with mt>1 for solving >this type of position since Crafty 16.8 cannot find usefull data in the hash >table and will *not* give the solution move back in reasonable time. Not at all... you are missing the point entirely. with mt=1, 16.8 (or any other version of crafty) finds the solution to fine #70 at ply=18, but it is _pure_ _luck_. If the move ordering were better, it would take 26 plies to find it with one processor. So this is _not_ an issue of 16.8 being worse in these positions... it is about a coin toss and it comes up heads sometimes, tails others, and neither has a thing to do with how well it plays chess. I can show you positions where 16.8 solves them 10X faster when using 4 threads than it does when using only 1. Is that really possible? Yes. Will it happen often enough to depend on it? Absolutely not. If you don't like non-deterministic behavior, and Crafty has had it since the first 15.x version with thread support, then you _must_ disable the parallel search. There is no other solution. In some positions you lose some. In others you gain a lot. The gains far outweigh the losses.. > >Here I give 4 other positions of the same type. Their solution relays hevily >on the use of hash tables. > >F. Sackmann, 1913 FEN: 8/8/2p/k1p1K/p1P/P/8/8 w >M. Botwinnik, 1939 FEN: 8/1k/p/p2p2K/P2P/8/8/8 w >C. Locock, 1892 FEN: 6k/3p/3p/3P/4P1p/6P/8/K w >C. Locock, 1892 FEN: 6k/3p/3p/3P/4P1p/6P/8/K b These don't exhibit the fine 70 behavior for me. first one is mate in 31 found in .2 seconds. > >Enjoy. >Kind regards >Bernhard > >>On June 01, 1999 at 01:53:41, Bernhard Bauer wrote: >> >>>On May 31, 1999 at 18:27:43, Robert Hyatt wrote: >>> >>>>On May 31, 1999 at 03:58:54, Bernhard Bauer wrote: >>>> >>>>>On May 28, 1999 at 09:38:24, Robert Hyatt wrote: >>>>> >>>>>>On May 28, 1999 at 07:18:38, Bernhard Bauer wrote: >>>>>> >>>>>>>On May 28, 1999 at 02:48:23, Bernhard Bauer wrote: >>>>>>> >>>>>>>>On May 27, 1999 at 20:30:32, Robert Hyatt wrote: >>>>>>>> >>>>>>>>>On May 27, 1999 at 13:36:03, Eugene Nalimov wrote: >>>>>>>>> >>>>>>>>>>On May 27, 1999 at 08:07:46, Robert Hyatt wrote: >>>>>>>>>> >>>>>>>>>>>On May 27, 1999 at 07:32:02, Bernhard Bauer wrote: >>>>>>>>>>> >>>>>>>>>>>>On May 27, 1999 at 07:19:17, Jeremiah Penery wrote: >>>>>>>>>>>> >>>>>>>>>>>>>On May 27, 1999 at 07:04:14, Bernhard Bauer wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>On May 26, 1999 at 19:14:14, Michel Chassey wrote: >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> 8 | | | | | | | | | >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> 7 | *K| | | | | | | | >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> 6 | | | | *P| | | | | >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> 5 | *P| | | P | | *P| | | >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> 4 | P | | | P | | P | | | >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> 3 | | | | | | | | | >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> 2 | | | | | | | | | >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> 1 | | K | | | | | | | >>>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>> a b c d e f g h >>>>>>>>> >>>>>>>>> >>>>>>>>>Thanks Eugene... so the executable seems to be ok. Now I wonder what caused >>>>>>>>>this problem in the first place... >>>>>>>> >>>>>>>>Looks like the executables from Bob Hyatt's site are ok. >>>>>>>>the problem occurs with my own executable. >>>>>>>> >>>>>>>>I use >>>>>>>>Optimierender Microsoft (R) 32-Bit C/C++-Compiler, Version 12.00.8168, fuer x86 >>>>>>>>CFLAGS = /O2 /G6 /Gr /Ob2 >>>>>>>>COPTS = /MT /DSMP /DCPUS=2 /DFAST >>>>>>>>and do a "nmake wcraftyx" >>>>>>>> >>>>>>>>and still get the problem. >>>>>>>> >>>>>>>> (2) 23 55.62 1.05 1. Kb2 Ka8 2. Kc2 Kb8 3. Kd2 Kc8 4. >>>>>>>> Kd3 Kc7 5. Ke3 Kd7 6. Kf2 Ke7 7. Ke1 >>>>>>>> Kd7 8. Kd1 Kc7 9. Ke2 Kd7 10. Kf3 Ke7 >>>>>>>> 11. Kf2 Kd7 12. Ke3 >>>>>>>> 23-> 1:45 1.05 1. Kb2 Ka8 2. Kc2 Kb8 3. Kd2 Kc8 4. >>>>>>>> Kd3 Kc7 5. Ke3 Kd7 6. Kf2 Ke7 7. Ke1 >>>>>>>> Kd7 8. Kd1 Kc7 9. Ke2 Kd7 10. Kf3 Ke7 >>>>>>>> 11. Kf2 Kd7 12. Ke3 >>>>>>>> (3) 24 1:45 1.05 1. Kb2 Ka8 2. Kc2 Kb8 3. Kd2 Kc8 4. >>>>>>>> Kd3 Kc7 5. Ke3 Kd7 6. Kf2 Ke7 7. Ke1 >>>>>>>> Kd7 8. Kf1 Ke7 9. Kf2 Ke8 10. Ke2 Kd7 >>>>>>>> 11. Kf3 Ke7 12. Ke3 Kd7 >>>>>>>> time=5:00 cpu=200% mat=1 n=90832482 fh=96% nps=302381 >>>>>>>> ext-> checks=21673 recaps=0 pawns=182451 1rep=2 thrt:0 >>>>>>>> predicted=0 nodes=90832482 evals=1096106 >>>>>>>> endgame tablebase-> probes done=0 successful=0 >>>>>>>> SMP-> split=3258 stop=215 data=11/64 cpu=10:01 elap=5:00 >>>>>>>> >>>>>>>>White(1): Kb2 >>>>>>>> time used: 5:00 >>>>>>>> >>>>>>>>May be my compiler has a problem? >>>>>>>>Any help is apreciated. >>>>>>>> >>>>>>>>Kind regards >>>>>>>>Bernhard >>>>>>> >>>>>>>Well, with mt=1 I get similar results as Eugene. But with mt=2 I get a poor >>>>>>>result compared with crafty16.6. >>>>>>>Here my inputfile >>>>>>> >>>>>>>computer >>>>>>>ponder off >>>>>>>swindle off >>>>>>>book off >>>>>>>hash 12M >>>>>>>hashp 4M >>>>>>>mt 1 >>>>>>>noise 9999 >>>>>>>time cpu >>>>>>>sd 25 >>>>>>>st 300 >>>>>>>setboard 8/k7/3p/p2P1p/P2P1P///K w >>>>>>>d >>>>>>>go >>>>>>>end >>>>>>> >>>>>>>And here the output: >>>>>>> (3) 21 5.79 1.07 1. Kb2 Ka8 2. Kc2 Kb8 3. Kd2 Kc8 4. >>>>>>> Ke2 Kd7 5. Kd1 Ke7 6. Kc1 Kf6 7. Kd2 >>>>>>> Kf7 8. Ke3 Kg6 9. Kd3 Kh5 10. Ke2 Kg4 >>>>>>> 11. Ke3 >>>>>>> 21-> 13.27 1.07 1. Kb2 Ka8 2. Kc2 Kb8 3. Kd2 Kc8 4. >>>>>>> Ke2 Kd7 5. Kd1 Ke7 6. Kc1 Kf6 7. Kd2 >>>>>>> Kf7 8. Ke3 Kg6 9. Kd3 Kh5 10. Ke2 Kg4 >>>>>>> 11. Ke3 >>>>>>> (3) 22 14.21 1.07 1. Kb2 Ka8 2. Kc2 Kb8 3. Kd2 Kc8 4. >>>>>>> Kc1 Kb7 5. Kb1 Ka7 6. Ka2 Kb8 7. Kb3 >>>>>>> Kc7 8. Kc4 Kb6 9. Kd3 Kc7 10. Kc3 Kb7 >>>>>>> 11. Kc4 Kb6 >>>>>>> 22 1:15 ++ 1. Kb1!! >>>>>>> 22-> 1:17 1.46 1. Kb1 >>>>>>> 23 2:03 ++ 1. Kb1!! >>>>>>> (2) 23 2:31 2.89 1. Kb1 Kb8 2. Kc2 Kc8 3. Kd2 Kd8 4. >>>>>>> Kc3 Kc7 5. Kd3 Kb6 6. Ke2 Ka6 7. Ke3 >>>>>>> Kb7 8. Kf3 Kb6 9. Kg3 Kb7 10. Kh4 Kc8 >>>>>>> 11. Kg5 Kd7 12. Kxf5 >>>>>>> 23-> 2:31 2.89 1. Kb1 Kb8 2. Kc2 Kc8 3. Kd2 Kd8 4. >>>>>>> Kc3 Kc7 5. Kd3 Kb6 6. Ke2 Ka6 7. Ke3 >>>>>>> Kb7 8. Kf3 Kb6 9. Kg3 Kb7 10. Kh4 Kc8 >>>>>>> 11. Kg5 Kd7 12. Kxf5 >>>>>>> 24 2:42 2.89 1. Kb1 Kb8 2. Kc2 Kc8 3. Kd2 Kd8 4. >>>>>>> Kc3 Kc7 5. Kd3 Kb6 6. Ke2 Ka6 7. Ke3 >>>>>>> Kb7 8. Kf3 Kb6 9. Kg3 Kc7 10. Kh4 Kd7 >>>>>>> 11. Kg5 Kd8 12. Kxf5 Kd7 >>>>>>> 24-> 2:43 2.89 1. Kb1 Kb8 2. Kc2 Kc8 3. Kd2 Kd8 4. >>>>>>> Kc3 Kc7 5. Kd3 Kb6 6. Ke2 Ka6 7. Ke3 >>>>>>> Kb7 8. Kf3 Kb6 9. Kg3 Kc7 10. Kh4 Kd7 >>>>>>> 11. Kg5 Kd8 12. Kxf5 Kd7 >>>>>>> 25 2:54 2.89 1. Kb1 Kb8 2. Kc2 Kc8 3. Kd2 Kd8 4. >>>>>>> Kc3 Kc7 5. Kd3 Kb6 6. Ke2 Kc7 7. Kf3 >>>>>>> Kd7 8. Kg3 Ke7 9. Kh4 Kf6 10. Kh5 Ke7 >>>>>>> 11. Kg6 Ke8 12. Kxf5 Kd7 13. Ke4 >>>>>>> 25-> 2:55 2.89 1. Kb1 Kb8 2. Kc2 Kc8 3. Kd2 Kd8 4. >>>>>>> Kc3 Kc7 5. Kd3 Kb6 6. Ke2 Kc7 7. Kf3 >>>>>>> Kd7 8. Kg3 Ke7 9. Kh4 Kf6 10. Kh5 Ke7 >>>>>>> 11. Kg6 Ke8 12. Kxf5 Kd7 13. Ke4 >>>>>>> time=2:55 cpu=199% mat=1 n=47500484 fh=88% nps=270288 >>>>>>> ext-> checks=49578 recaps=0 pawns=146 1rep=0 thrt:0 >>>>>>> predicted=0 nodes=47500484 evals=11647417 >>>>>>> endgame tablebase-> probes done=0 successful=0 >>>>>>> SMP-> split=6040 stop=475 data=12/64 cpu=5:51 elap=2:55 >>>>>>> >>>>>>>White(1): Kb1 >>>>>>> time used: 2:55 >>>>>>>Black(1): execution complete. >>>>>>> >>>>>>>I think 75 sec to find Kb1! on a 2 proc PPro 223 MHz is too long. >>>>>>> >>>>>>>Kind regards >>>>>>>Bernhard >>>>>> >>>>>> >>>>>>Here is the problem in your case. Fine 70 takes 26 plies to solve, and there >>>>>>is _no_ way to see winning the pawn any quicker. So how does crafty find it >>>>>>at depth=18? Poor move ordering somewhere. What happens is it finds a way to >>>>>>win the pawn with black playing poorly, then discovers that it can force a >>>>>>position to be reached with black playing perfectly, where this position was >>>>>>already reached with black playing poorly and it found that below this position >>>>>>even if black plays perfectly it can force a win. This will be 100% repeatable >>>>>>with a serial search. But with the parallel search, not at all. And you get >>>>>>such wild results. Normal positions don't behave like this, but fine 70 is >>>>>>solved by 'cheating' (a program with perfect move ordering will take 26 plies >>>>>>no matter what). And this 'cheating' is screwed up by a non-deterministic >>>>>>parallel search. >>>>> >>>>>Hallo Robert, >>>>> >>>>>thank you for your replay and explanation. I agree that it may take 26 plys to >>>>>find Kb1, however, what about the search times? >>>>> >>>>>Now lets compare version 16.6 and 16.8 >>>>> >>>>>version ply time score move >>>>>------------------------------------ >>>>>16.6 23 1.17 3.31 Kb1 >>>>>16.6 24 1.26 3.39 Kb1 >>>>>16.6 25 1.37 3.39 Kb1 >>>>>16.6 26 1.57 3.64 Kb1 nps=197622 >>>>> >>>>>16.8 22 56.72 1.05 Kb2 >>>>>16.8 23 1:43 1.05 Kb2 >>>>>16.8 24 6:24 1.05 Kb2 >>>>>16.8 25 >10:00 ?? ?? nps=295048 >>>>> >>>>>So the question remains: Why can't Crafty16.8 with mt=2 not reach ply 26 >>>>>in a reasonable time and why can't it find Kb1? >>>>> >>>>>Is it a compiler problem? >>>>>Is it a crafty problem that only comes ub in the windows version? >>>>>Since I used the same compiler for 16.6 and 16.8 it may have to do with >>>>>changes in the source code. >>>>> >>>>>Kind regards >>>>>Bernhard >>>> >>>> >>>>No... you are comparing apples and oranges above. IE I'd rather start an >>>>N+1 ply search with the _right_ score. In your case, you start with a score >>>>too low, which first requires a fail high and then a re-search. And earlier >>>>searches had a worse alpha/beta window to start with as well... >>>> >>>>IE you can't compare times when one search gets +2.x at depth=18, and the >>>>other gets it at depth=22 or whatever. That is a hazard of parallel search >>>>that is interesting and not fixable... >>> >>>I'm not comparing apples and oranges. >>>I'm comparing Crafty16.6 with Crafty16.8. >>>And I'm showing that Crafty16.6 reaches play 26 in 1.57 sec but Crafty16.8 >>>does not reach play 25 in 600 sec. >>> >>>As this position is a good test case for the use of hash tables it's reasonable >>>to ask whether the hash table works correctly with mt=2. >>> >>>Kind regards >>>Bernhard
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.