Author: Bernhard Bauer
Date: 22:53:41 05/31/99
Go up one level in this thread
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.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.