CuckooChess 1.12

[Jim Ablett]

Here are my windows executables. I can't update my website at the moment so I'll put the download links here.
As well as the usual 32 bit Excelsior Jet standalone compile, I have included a JExecutable compile which is basically
the .jar file wrapped up as an executable & still uses the Java Runtime Environment installed on your system.

http://dl.dropbox.com/u/5047625/cuckoochess-112-ja.zip
Mirror:
http://cl.ly/BH1I/cuckoochess-112-ja.zip

Thank you for the update Peter.

Jim.

Hi Jim and thanks for these compilations.

I did some speed measurements:

Code: Select all

Version     N/s
32-bit JVM  548313
64-bit JVM  1058576
JExecutable 554771
Excelsior   523160

So it seems like the JExecutable is running the 32-bit JVM even though both 32- and 64-bit version are installed on this computer. Maybe that is expected.

A bigger concern is that the Excelsior compile doesn't produce the same search tree as the other versions. The code is supposed to be deterministic, so this needs some investigation to figure out if the difference could also affect playing strength. (It also means that the Excelsior nps value can't be directly compared to the other versions.)

When searching from the start position, the difference is seen for depth >= 14. I tried two different hash sizes and got 14 in both cases.

Could you please compile this debug version that dumps search tree information to a file during search? The jar file is here: http://web.comhem.se/petero2home/javach ... _debug.jar

http://dl.dropbox.com/u/5047625/cuckooc ... bug-ja.zip

Jim.

The difference is in evaluation and happens first in this position:
[d]
The java version evaluates this position to 165 and the Excelsior version evaluates it to 185. This exactly matches the bonus for having more than 1 rook on the 7:th rank. To confirm this suspicion, can you please compile this new debug version that adds some logging in the evaluation code: http://web.comhem.se/petero2home/javach ... 112_d2.jar

http://dl.dropbox.com/u/5047625/cuckooc ... -d2-ja.zip

Jim.

Thanks. This confirms my suspicion. The following code seems to be compiled incorrectly:

Code: Select all

        long r7 = pos.pieceTypeBB[Piece.WROOK] & 0x00ff000000000000L;
        if (((r7 & (r7 - 1)) != 0) &&
            ((pos.pieceTypeBB[Piece.BKING] & 0xff00000000000000L) != 0))
            score += 20; // Two rooks on 7:th row

Can you please compile this simplified test case to see if it has the same bug:

Code: Select all

public class JetBug {
    public static void main(String[] args) {
        long l = 0;
        if (args.length > 0)
            l = Long.parseLong(args[0]);
        long x = l & (l - 1);
        boolean b = (l & (l - 1)) != 0;
        System.out.printf("l:%d x:%d b:%d\n", l, x, b?1:0);
    }
}

l=18014398509481984 corresponds to the error in the chess position above.

Code: Select all

test 18014398509481984
l:18014398509481984 x:0 b:0

Jim.

[petero2]

Thanks. This confirms my suspicion. The following code seems to be compiled incorrectly:

Code: Select all

        long r7 = pos.pieceTypeBB[Piece.WROOK] & 0x00ff000000000000L;
        if (((r7 & (r7 - 1)) != 0) &&
            ((pos.pieceTypeBB[Piece.BKING] & 0xff00000000000000L) != 0))
            score += 20; // Two rooks on 7:th row

Can you please compile this simplified test case to see if it has the same bug:

Code: Select all

public class JetBug {
    public static void main(String[] args) {
        long l = 0;
        if (args.length > 0)
            l = Long.parseLong(args[0]);
        long x = l & (l - 1);
        boolean b = (l & (l - 1)) != 0;
        System.out.printf("l:%d x:%d b:%d\n", l, x, b?1:0);
    }
}

l=18014398509481984 corresponds to the error in the chess position above.

Code: Select all

test 18014398509481984
l:18014398509481984 x:0 b:0

Jim.

OK, so the bug isn't triggered by the simplified test case. Never the less, I am quite sure this is a compiler bug. The modified code in the chess program looks like this:

Code: Select all

private final int rookBonus(Position pos) {
        int score = 0;
        final long wPawns = pos.pieceTypeBB[Piece.WPAWN];
        final long bPawns = pos.pieceTypeBB[Piece.BPAWN];
        final long occupied = pos.whiteBB | pos.blackBB;
        System.out.printf("%.3f Evaluate.rookBonus(): wP:%d bP:%d occ:%d\n", System
                .currentTimeMillis() * 1e-3, wPawns, bPawns, occupied);
        long m = pos.pieceTypeBB[Piece.WROOK];
        while (m != 0) {
            System.out.printf("%.3f Evaluate.rookBonus(): m:%d\n", System
                    .currentTimeMillis() * 1e-3, m);
            int sq = BitBoard.numberOfTrailingZeros(m);
            final int x = Position.getX(sq);
            if ((wPawns & BitBoard.maskFile[x]) == 0) { // At least half-open file
                score += (bPawns & BitBoard.maskFile[x]) == 0 ? 25 : 12;
            }
            long atk = BitBoard.rookAttacks(sq, occupied);
            wAttacksBB |= atk;
            score += rookMobScore[Long.bitCount(atk & ~(pos.whiteBB | bPawnAttacks))];
            System.out.printf("%.3f Evaluate.rookBonus(): s:%d\n", System
                    .currentTimeMillis() * 1e-3, score);
            if ((atk & bKingZone) != 0)
                bKingAttacks += Long.bitCount(atk & bKingZone);
            m &= m-1;
        }
        long r7 = pos.pieceTypeBB[Piece.WROOK] & 0x00ff000000000000L;
        System.out.printf("%.3f Evaluate.rookBonus(): r7:%d\n", System
                .currentTimeMillis() * 1e-3, r7);
        if (((r7 & (r7 - 1)) != 0) &&
            ((pos.pieceTypeBB[Piece.BKING] & 0xff00000000000000L) != 0)) {
            score += 20; // Two rooks on 7:th row
            System.out.printf("%.3f Evaluate.rookBonus(): s2:%d\n", System
                    .currentTimeMillis() * 1e-3, score);
        }
        m = pos.pieceTypeBB[Piece.BROOK];
        while (m != 0) {
            System.out.printf("%.3f Evaluate.rookBonus(): m:%d\n", System
                    .currentTimeMillis() * 1e-3, m);
            int sq = BitBoard.numberOfTrailingZeros(m);
            final int x = Position.getX(sq);
            if ((bPawns & BitBoard.maskFile[x]) == 0) {
                score -= (wPawns & BitBoard.maskFile[x]) == 0 ? 25 : 12;
            }
            long atk = BitBoard.rookAttacks(sq, occupied);
            bAttacksBB |= atk;
            score -= rookMobScore[Long.bitCount(atk & ~(pos.blackBB | wPawnAttacks))];
            System.out.printf("%.3f Evaluate.rookBonus(): s:%d\n", System
                    .currentTimeMillis() * 1e-3, score);
            if ((atk & wKingZone) != 0)
                wKingAttacks += Long.bitCount(atk & wKingZone);
            m &= m-1;
        }
        r7 = pos.pieceTypeBB[Piece.BROOK] & 0xff00L;
        System.out.printf("%.3f Evaluate.rookBonus(): r7b:%d\n", System
                .currentTimeMillis() * 1e-3, r7);
        if (((r7 & (r7 - 1)) != 0) &&
            ((pos.pieceTypeBB[Piece.WKING] & 0xffL) != 0)) {
          score -= 20; // Two rooks on 2:nd row
          System.out.printf("%.3f Evaluate.rookBonus(): s2b:%d\n", System
                  .currentTimeMillis() * 1e-3, score);
        }
        return score;
    }

When run on the previously mentioned test position, it printed:

Code: Select all

1319661449,883 Evaluate.rookBonus(): wP:2144000 bP:49258120924364800 occ:-7066394088766654659
1319661449,883 Evaluate.rookBonus(): m:18014398509481985
1319661449,883 Evaluate.rookBonus(): s:-7
1319661449,883 Evaluate.rookBonus(): m:18014398509481984
1319661449,883 Evaluate.rookBonus(): s:29
1319661449,883 Evaluate.rookBonus(): r7:18014398509481984
1319661449,883 Evaluate.rookBonus(): s2:49
1319661449,883 Evaluate.rookBonus(): m:-9151314442816847872
1319661449,883 Evaluate.rookBonus(): s:56
1319661449,883 Evaluate.rookBonus(): m:-9223372036854775808
1319661449,883 Evaluate.rookBonus(): s:60
1319661449,883 Evaluate.rookBonus(): r7b:0

From this we can see that r7 is 18014398509481984, which means that r7&(r7-1) is 0, but the s2 line is still printed, which shows that the preceding conditional statment was incorrectly evaluated.

To repeat this, start the exe with "txt" as command line argument, then enter

Code: Select all

setpos r1bqk2r/pppp1pRp/5n2/2b5/8/2N2P2/PPP1PP1P/R1BQKB2 b Qkq - 0 7

[Jim Ablett]

I'll remove the Excelsior jet compile from the download for the time being.

Jim.

[Jim Ablett]

I have compiled a new Windows java-wrapper executable using
'Launch4J' which should be 32/64 bit compatible i.e it will use 64 bit JRE if available.

http://dl.dropbox.com/u/5047625/cuckoochess_112-ja.zip
Mirror:
http://cl.ly/BKKE/cuckoochess_112-ja.zip

Jim.

[Sylwy]

I have compiled a new Windows java-wrapper executable using
'Launch4J' which should be 32/64 bit compatible i.e it will use 64 bit JRE if available.

http://dl.dropbox.com/u/5047625/cuckoochess_112-ja.zip
Mirror:
http://cl.ly/BKKE/cuckoochess_112-ja.zip

Jim.

Thank you a lot Mr.Jim Ablett !
Thank you also for the new & nice logos for Cheng 3 1.05 (JA compile !!!) and CuckooChess 1.12 !

Regards,
SilvianR

[Jim Ablett]

I have compiled a new Windows java-wrapper executable using
'Launch4J' which should be 32/64 bit compatible i.e it will use 64 bit JRE if available.

http://dl.dropbox.com/u/5047625/cuckoochess_112-ja.zip
Mirror:
http://cl.ly/BKKE/cuckoochess_112-ja.zip

Jim.

Thank you a lot Mr.Jim Ablett !
Thank you also for the new & nice logos for Cheng 3 1.05 (JA compile !!!) and CuckooChess 1.12 !

Regards,
SilvianR

You're welcome.

Jim.

[petero2]

I'll remove the Excelsior jet compile from the download for the time being.

Jim.

Could you please try to compile this version:http://web.comhem.se/petero2home/javach ... oo112b.jar. I rewrote the problematic code in a way that hopefully avoids the bug. You can test if the bug got fixed by starting the exe in a dos prompt and type "go depth 17". If the last info line reports 35985254 nodes, the problem got fixed. If it reports 20828056 nodes, the same bug is still present.

[petero2]

I have compiled a new Windows java-wrapper executable using
'Launch4J' which should be 32/64 bit compatible i.e it will use 64 bit JRE if available.

http://dl.dropbox.com/u/5047625/cuckoochess_112-ja.zip
Mirror:
http://cl.ly/BKKE/cuckoochess_112-ja.zip

Jim.

Thanks Jim.

It works well on my computer and runs at the same speed as the 64 bit java version, as expected.

[Jim Ablett]

I'll remove the Excelsior jet compile from the download for the time being.

Jim.

Could you please try to compile this version:http://web.comhem.se/petero2home/javach ... oo112b.jar. I rewrote the problematic code in a way that hopefully avoids the bug. You can test if the bug got fixed by starting the exe in a dos prompt and type "go depth 17". If the last info line reports 35985254 nodes, the problem got fixed. If it reports 20828056 nodes, the same bug is still present.

Code: Select all

info currmove f2f3 currmovenumber 18
info currmove b1c3 currmovenumber 19
info currmove f2f4 currmovenumber 20
info nodes 35985254 nps 154619 time 232734
bestmove e2e4 ponder e7e5

Jim.

[petero2]

I'll remove the Excelsior jet compile from the download for the time being.

Jim.

Could you please try to compile this version:http://web.comhem.se/petero2home/javach ... oo112b.jar. I rewrote the problematic code in a way that hopefully avoids the bug. You can test if the bug got fixed by starting the exe in a dos prompt and type "go depth 17". If the last info line reports 35985254 nodes, the problem got fixed. If it reports 20828056 nodes, the same bug is still present.

Code: Select all

info currmove f2f3 currmovenumber 18
info currmove b1c3 currmovenumber 19
info currmove f2f4 currmovenumber 20
info nodes 35985254 nps 154619 time 232734
bestmove e2e4 ponder e7e5

Jim.

Good, then it worked. I will include this workaround in my next version, as I don't think it will have a measurable effect on program speed.