Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prospective improvements in the C# port #12

Open
respel opened this issue Nov 16, 2020 · 4 comments
Open

Prospective improvements in the C# port #12

respel opened this issue Nov 16, 2020 · 4 comments

Comments

@respel
Copy link

respel commented Nov 16, 2020

Hey, it's me again. So, the C# port is live at https://github.com/respel/Chess22kDotNet.
In one of our previous discussions, you mentioned some stuff that you would like to implement in the C# port. I'm quoting you here

These are some features I would like to implement which are currently not possible in Java:
*use a long array for the hashtable with more than 2^31 entries
*use struct items in the hashtable instead of 2 long values
*add endgame tablebase support by calling external libraries

I'm interested in implementing them. Can you expand a bit more on exactly what hash tables were you talking about here?

Another thing I was thinking about was to make a library out of the common code and then make the engine use that. However, I guess that would render the engine much weaker, so wasn't totally sure whether to go forward with it.

@sandermvdb
Copy link
Owner

Hi,

With the hashtable I meant the transposition table. I can think of 2 possible improvements:

  1. In Java the maximum length of an array is the maximum value of an integer, which is 2147483647. I use 2 long arrays for the transposition table which results in a maximum memory usage of 8 GB. Normally this is more than enough but under TCEC conditions (64 threads, long timecontrol) this is probably a bottleneck. It is hard to say how much but I guess 25 elo.
  2. The transposition table consists of 2 long arrays, one containing the zobrist keys, the other the values (score, bestmove, depth, etc...). I think its much cleaner to store a struct of 128 bit containing all this data. I think there are also some minor performance improvements: no bit shifting necessary to create the value, no xorring necessary to validate that the key and value belong to each other and finally better cache usage because the key and value are adjacent to each other in memory.

Does this help? :)

@respel
Copy link
Author

respel commented Nov 27, 2020

@sandermvdb Thanks for the reply, it did help a lot.

You are already using only one array for the transpositions table, so that's a non-issue 😄

Regarding the struct itself, I have implemented it, however, it's clocking in at 136 bits instead of 128.

namespace Chess22kDotNet.Search
{
    public struct TtEntry
    {
        private short _depth;
        public long Key { get; set; }
        public int Move { get; set; }
        public short Score { get; set; }
        public byte Flag { get; set; }

        public short Depth
        {
            set => _depth = (short)(value + TtUtil.HalfMoveCounter);
            get => (short)(_depth - TtUtil.HalfMoveCounter);
        }
    }
}

@sandermvdb
Copy link
Owner

You are indeed correct that the transposition table is already one array, I changed that some time ago :)

Regarding the 136 bits, you could use 16 bits for the Move and then reconstruct the missing bits (6 I believe).
Or combine _depth or Move with Flag, since Flag only needs 2 bits.

@respel
Copy link
Author

respel commented Nov 28, 2020

@sandermvdb Thanks for the tip. Merged move with flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants