Move generator advice

[Henk]

And remember evaluation is not much better than a buggy random number generator unless you implement it correctly.

[RedBedHed]

Thank you, Thomas!

I believe that this is the suite that Christian recommended earlier. It did find an en-passant-discovered-check bug that I might never have found on my own! Honestly, I wonder what chess programmers did before all of these tests. I can't imagine how frustrating it must have been to find bugs during gameplay...

[RedBedHed]

Henk,

Oh I bet! I don't know much about chess evaluation strategies (other than watching for discovered checks, using piece heuristics, and giving high scores to checkmates...). I really want to implement a neural network and train it to do all of that work for me... But I also know very little about neural networks. I'm just starting to research them.

We'll have to see how it goes. For now, I think I'm just going to write a very simple search and improve things little by little...

[RedBedHed]

Update on speed (now using pext bitboards, if available) :

perft(1) - 0.000 seconds - 20 nodes visited.
perft(2) - 0.000 seconds - 400 nodes visited.
perft(3) - 0.000 seconds - 8902 nodes visited.
perft(4) - 0.000 seconds - 197281 nodes visited.
perft(5) - 0.016 seconds - 4865609 nodes visited.
perft(6) - 0.344 seconds - 119060324 nodes visited.
perft(7) - 9.047 seconds - 3195901860 nodes visited.
perft(8) - 249.016 seconds - 84998978956 nodes visited.

(about 340,000,000 leaf nps at perft 8)

[RedBedHed]

For some reason it is even faster on KiwiPete and Position 6, yielding upwards of 400,000,000 leaf nps...

[RedBedHed]

In the last GitHub push I commented out a macro definition, and the compiler was using magic instead of pext. I think I fixed it now. Sorry to anyone who cloned it. I'm a total beginner when it comes to controlling compilation explicitly.

[dangi12012]

Update on speed (now using pext bitboards, if available) :

perft(1) - 0.000 seconds - 20 nodes visited.
perft(2) - 0.000 seconds - 400 nodes visited.
perft(3) - 0.000 seconds - 8902 nodes visited.
perft(4) - 0.000 seconds - 197281 nodes visited.
perft(5) - 0.016 seconds - 4865609 nodes visited.
perft(6) - 0.344 seconds - 119060324 nodes visited.
perft(7) - 9.047 seconds - 3195901860 nodes visited.
perft(8) - 249.016 seconds - 84998978956 nodes visited.

(about 340,000,000 leaf nps at perft 8)

You will be interested in my github Sourcecode! I had similar performance for a long time. There are some ideas that took my 200Mnps to now to above 2Giganodes/s. No hashing. Single core
http://www.talkchess.com/forum3/viewtop ... =7&t=78230

[gaard]

Update on speed (now using pext bitboards, if available) :

perft(1) - 0.000 seconds - 20 nodes visited.
perft(2) - 0.000 seconds - 400 nodes visited.
perft(3) - 0.000 seconds - 8902 nodes visited.
perft(4) - 0.000 seconds - 197281 nodes visited.
perft(5) - 0.016 seconds - 4865609 nodes visited.
perft(6) - 0.344 seconds - 119060324 nodes visited.
perft(7) - 9.047 seconds - 3195901860 nodes visited.
perft(8) - 249.016 seconds - 84998978956 nodes visited.

(about 340,000,000 leaf nps at perft 8)

You will be interested in my github Sourcecode! I had similar performance for a long time. There are some ideas that took my 200Mnps to now to above 2Giganodes/s. No hashing. Single core
http://www.talkchess.com/forum3/viewtop ... =7&t=78230

Source code? You keep using that word. I do not think it means what you think it means, since there is none available.

[mvanthoor]

...

Hi, and welcome to Talkchess.

Did I read that correctly? Your perft() function is 20% faster than hgm's qperft and achieves this speed without using neither bulk counting nor hashing? That's really impressive!!

Edit: I did not read correctly and it does use bulk-counting. But still impressive!

It seems to be twice as fast as QPerft, and to be honest, I'm in disbelief. As far as I'm aware, QPerft is one of the fastest, if not THE fastest Perft generator in existence. I'd want to know how one can beat that program by a factor of two.

[mvanthoor]

Rustic is a very very fast engine with almost no pruning apart from alpha beta. But it hardly reaches depth 12. Zahak is much slower, with lots of pruning in place, and reaches depth 20 from startpos in 5 seconds. Even though Zahak's NPS is quarter of that of Rustic. Obviously, rustic is still under development, and I'm sure it will have pruning in the future.

Moral of story, speed is important, but it is not the only factor

Hi Amanj,

Thank you for the props. Rustic will have null move pruning version 5 (*); maybe also static null move pruning. And then more pruning in version 6, 7, and so on. I've just finished up testing and merging the optimizations I wrote in June, since the version 3.1.112 that ran in ZaTour. Those gained more speed and another 52 Elo without even adding features.

(*) Version 4 will have a tapered evaluation with my own tables created on a bigger data-set than what was used for the current tables. I hope to gain some Elo there. My development version is still running on MinimalChess' tables.

Still, Rustic "only" ran Perft at 41 million leaves/second on an i7-6700K. That's a far cry from 140 million / second. But I'm not doing bulk counting. I assume Charon's 140 mln is WITH bulk counting. Maybe I should add that option. Even so, Rustic's Perft has steadily becoming slower and slower, and it's now at 32 million leaves/second. The reason is that Rustic keeps everything incrementally (both sets of PST's, Zobrist hash, material value, phase value, etc...) as it makes moves, which is very good for chess as this lightens the load on evaluation calcluations, but it is very bad for Perft.

And to be honest, I'm a bit hesitant to start sprinkling "if !running_perft { ... }" around all the incremental updates, as Rustic is a chess engine, and not a Perft generator. Maybe, someday, I'll split "RPerft" or "RustPerft" off from the engine or something.