Endgame tablebase progress report

[Koistinen]

I am happy to say it now looks like I am able to compute 3-man endgame tablebases that look ok for me.
I am using tables of booleans and the code is very inefficient: One endgame takes about 13 minutes on my computer.
Next step is changing the file format to use one bit per boolean.
Then I'll move on to the fourth version, improving performance by using a bitboard for the white king.
I think a speedup is necessary for debugging when I fix the lookup to work for the case of white wins after capture.
Code is at https://github.com/Koistinen/chess.
Someone might find the code for printing a chessboard to the terminal useful. I found it helped a lot when debugging.

[dangi12012]

Well there is your culpruit:

Code: Select all

    for ♔sq in 0..63:
      for ♚sq in 0..63:
        for ♕sq in 0..63:
          if ♔sq != ♚sq and ♔sq != ♕sq and ♚sq != ♕sq

You should use the lexicographically greater permutation in base 2 and it will be 1-2 orders of magnitude faster.
Also I have NEVER heard of "nim" language.
Also unicode variable names are funny to look at.

[dangi12012]

Here we go. Helped me a lot when accelerating the search for magic numbers.

Code: Select all

static void bit_twiddle_permute(uint64_t& v) {
	uint64_t t = v | (v - 1);
	v = (t + 1) | (((~t & -~t) - 1) >> (countr_zero(v) + 1));
}

Fun fact:
If you paste this to Chat-GPT4 withtout the function name - it can explain what it does and how it works.
If you paste this to Chat-GPT3.5 without the function name - it cannot.

[Koistinen]

the lexicographically greater permutation in base 2

https://stackoverflow.com/questions/828 ... mber-of-1s

I follow the maxim:

Premature optimization is the root of all evil.

and have good hope that I'll get a better result in the end.
For now I prioritize correctness. I try to keep the code as simple as I can so I might have a chance at understanding why it doesn't work.
Once I get 4-man to work correctly, I will be confident enough to start going full on for performance. Things like computing many positions at the same time. It doesn't work for normal search, but for tablebases it should be fine. I think I/O will become the limiting factor.