Author: Bernhard Bauer
Date: 03:32:05 06/01/99
Go up one level in this thread
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. 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 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.