Author: Robert Hyatt
Date: 11:13:07 08/11/99
Go up one level in this thread
On August 11, 1999 at 10:12:09, Robert Hyatt wrote: >On August 11, 1999 at 03:35:12, Bernhard Bauer wrote: > >>On August 10, 1999 at 12:00:07, Robert Hyatt wrote: >> >>>On August 10, 1999 at 10:44:49, Bernhard Bauer wrote: >>> >>>>On August 10, 1999 at 10:24:30, Robert Hyatt wrote: >>>> >>>>>On August 10, 1999 at 02:25:56, Bernhard Bauer wrote: >>>>> >>>>>>On August 09, 1999 at 12:24:56, Robert Hyatt wrote: >>>>>> >>>>>>>On August 09, 1999 at 10:02:42, Bernhard Bauer wrote: >>>>>>> >>>>>>>>Hallo, >>>>>>>> >>>>>>>>recently I came across a position from a game >>>>>>>>Haenninnen - Szabo, Wageningen. >>>>>>>> >>>>>>>>The position is >>>>>>>>FEN: 3r1rk/pp1q2b/3p2pp/PP1Np2n/2Pp1p/B2P2Pb/3QPPBP/R4RK w >>>>>>>> >>>>>>>>The game went on >>>>>>>>19. Bxd6 Bxg2 >>>>>>>>20. Bxf8 Qh3 >>>>>>>>21. Bxg7 f3 >>>>>>>>22. exf3 Bxf3 >>>>>>>>23. Ne3 Kg7 >>>>>>>>24. Qb4 Rd7 >>>>>>>>25. Ra2 Nf6 >>>>>>>>White resigned. >>>>>>>> >>>>>>>>Programs have difficulties to find out that 19. Bxd6 is bad. >>>>>>>>The whole line seems to be difficult at least for Crafty. >>>>>>>>BTW Crafty produces a lot of debug messages on a Sun, not on a PC. >>>>>>>> >>>>>>>>Enjoy >>>>>>>>Bernhard >>>>>>> >>>>>>> >>>>>>>What is "a lot of debug messages"? If you are getting oddball error messages >>>>>>>then something is definitely wrong... >>>>>>> >>>>>>Messages like this: >>>>>>captured a king >>>>>>piece=5,from=51,to=44,captured=3 >>>>>>ply=16 >>>>>>My logfile is 5.2 Mb in size. >>>>>> >>>>>> >>>>>>>As far as the position goes, the end has a B on F3, Q on h3, which is a known >>>>>>>"null-move" killer... >>>>>> >>>>>>Oh, not known to me. But I feared it would be a null move problem again -:) >>>>>>Kind regards >>>>>>Bernhard >>>>> >>>>> >>>>>That is definitely bad. Such errors should never occur, and are only present >>>>>to catch errors that I introduce when changing the code... Can you post a >>>>>FEN for aposition that will produce such an error? >>>> >>>>Of course >>>>FEN: 3r1rk/pp1q2b/3p2pp/PP1Np2n/2Pp1p/B2P2Pb/3QPPBP/R4RK w >>>>See above. >>>> >>>>BTW the hardware is a Ultra Sparc with 2 procs. >>>>fpversion gives: >>>> A SPARC-based CPU is available. >>>> CPU's clock rate appears to be approximately 166.8 MHz. >>>> Kernel says CPU's clock rate is 168.0 MHz. >>>> Kernel says main memory's clock rate is 84.0 MHz. >>>> >>>> Sun-4 floating-point controller version 0 found. >>>> An UltraSPARC chip is available. >>>> FPU's frequency appears to be approximately 170.5 MHz. >>>> >>>> Use "-xtarget=ultra" code-generation option. >>>> >>>>The OS is Solaris 7 from May 99. It's the 64-bit version. >>>>The compiler is gcc2.95 >>>> >>>>Kind regards >>>>Bernhard >>> >>> >>>OK.. I overlooked that this was the same position discussed earlier. I ran this >>>a bunch of times with no strange output at all. I'd guess that somehow the >>>optimizations are going wrong... try compiling without the -O at all, and then >>>run the same test. And keep adding optimizations back in until you do see the >>>error. >>> >>>I ran with 1 cpu, 4 cpus, long and short search times, with none of that >>>'captured a king' internal diagnostic error stuff at all... >> >>Here my results. >>Without -O , but with assembler code Crafty produces "captured a kink". >>Without -O , and without assembler code Crafty looks fine. >>With -O3, and without assembler code Crafty dumps core from beginning. >> >>May be the Sparc assembler code does'nt fit my system, or somthing is wrong for >>target=SUN, since Crafty runs well under WinNT. >> >>Kind regards >>Bernhard > > >For comparison, are you using the SUN option in the Makefile? Also, if you >use the sparc assembly code, you _must_ use COMPACT_ATTACKS as the sparc >assembly depends on that. > >A friend of mine is running a sparc version on an ultra-sparc 300, and isn't >seeing this, although I am going to test your position on it to see if I see >any errors... I ran this on the latest version, compiled by Sun's C compiler, on a 300mhz ultrasparc, and got no errors of any kind reported while it searched the position... I'd suspect the new gcc 2.95 (sparc version) since we have no data on it prior to this...
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.