Author: Bernhard Bauer
Date: 00:31:40 08/12/99
Go up one level in this thread
On August 11, 1999 at 14:13:07, Robert Hyatt wrote:
>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.
>>
Yes, I use target=SUN.
Yes, I use COMPACT_ATTACKS
>>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...
>
Is he using the Solaris 2.7 OS in 64 bit mode?
>
>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...
Now, as I have a working egtb.o (thanks to Jose) I could make crafty with the
SUN compiler and got:
White(1): White(1):
+---+---+---+---+---+---+---+---+
8 | | | | *R| | *R| *K| |
+---+---+---+---+---+---+---+---+
7 | *P| *P| | *Q| | | *B| |
+---+---+---+---+---+---+---+---+
6 | | | | *P| | | *P| *P|
+---+---+---+---+---+---+---+---+
5 | P | P | | N | *P| | | *N|
+---+---+---+---+---+---+---+---+
4 | | | P | *P| | *P| | |
+---+---+---+---+---+---+---+---+
3 | B | | | P | | | P | *B|
+---+---+---+---+---+---+---+---+
2 | | | | Q | P | P | B | P |
+---+---+---+---+---+---+---+---+
1 | R | | | | | R | K | |
+---+---+---+---+---+---+---+---+
a b c d e f g h
White(1): clearing hash tables
time surplus 0.00 time limit 20:00 (20:00)
s depth time score variation (1)
starting thread 1
5 0.40 0.48 1. Bxd6 Qxd6 2. Bxh3 fxg3 3. hxg3 Nf6
(3) 5-> 0.76 0.48 1. Bxd6 Qxd6 2. Bxh3 fxg3 3. hxg3 Nf6
(2) 6 1.16 0.57 1. Bxd6 Qxd6 2. Bxh3 fxg3 3. hxg3 Nf6
4. Nxf6+ Qxf6 5. Bg2
6-> 1.86 0.57 1. Bxd6 Qxd6 2. Bxh3 fxg3 3. hxg3 Nf6
4. Nxf6+ Qxf6 5. Bg2
7 2.58 0.55 1. Bxd6 Qxd6 2. Bxh3 fxg3 3. hxg3 Nf6
4. Bg2 Nxd5 5. cxd5
(2) 7-> 4.34 0.55 1. Bxd6 Qxd6 2. Bxh3 fxg3 3. hxg3 Nf6
4. Bg2 Nxd5 5. cxd5
8 7.33 0.74 1. Bxd6 Qxd6 2. Bxh3 fxg3 3. hxg3 Nf6
4. Bg2 Ng4 5. e4 dxe3 6. Nxe3
8-> 9.68 0.74 1. Bxd6 Qxd6 2. Bxh3 fxg3 3. hxg3 Nf6
4. Bg2 Ng4 5. e4 dxe3 6. Nxe3
captured a king 9 15.30 1/45 1. Bxd6
piece=7,from=46,to=62,captured=3
ply=7
captured a king
piece=7,from=62,to=54,captured=3
ply=15
captured a king
piece=7,from=62,to=54,captured=3
ply=15
captured a king
piece=7,from=62,to=55,captured=3
So I do not know any reason for this behavior. However, from hearsay the 64-bit
Solaris is said to make problems.
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.