Author: Robert Hyatt
Date: 15:27:43 05/31/99
Go up one level in this thread
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...
This page took 0.01 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.