Chess Optimizations

Question

ok, so i have been working on my chess program for a while and i am beginning to hit a wall. i have done all of the standard optimizations (negascout, iterative deepening, kille

Answer 1

Answering an old question.

Assuming you already have a working transposition table.

Late Move Reduction. That gave my program about 100 elo points and it is very simple to implement.

In my experience, unless your implementation is very inefficient, then the actual board representation (0x88, bitboard, etc.) is not that important.

Although you can criple you chess engine with bad performance, a lightning fast move generator in itself is not going to make a program good.

The search tricks used and the evaluation function are the overwhelming factors determining overall strength.

And the most important parts, by far, of the evaluation are Material, Passed pawns, King Safety and Pawn Structure.

The most important parts of the search are: Null Move Pruning, Check Extension and Late Move reduction.

Your program can come a long, long way, on these simple techniques alone!

Answer 2

I know that one improvement that was talked about at the AI courses in university where having a huge database of finishing moves. So having a precalculated database for games with only a small number of figures left. So that if you hit a near end positioning in your search you stop the search and take a precalculated value that improves your search results like extra deepening that you can do for important/critique moves without much computation time spend. I think it also comes with a change in heuristics in a late game state but I'm not a chess player so I don't know the dynamics of game finishing.

Answer 3

Profile and benchmark. Theoretical optimizations are great, but unless you are measuring the performance impact of every change you make, you won't know whether your work is improving or worsening the speed of the final code.

Try to limit the penalty to yourself for trying different algorithms. Make it easy to test various implementations of algorithms against one another. i.e. Make it easy to build a PVS version of your code as well as a NegaScout version.

Find the hot spots. Refactor. Rewrite in assembly if necessary. Repeat.

Answer 4

Good move ordering!

An old question, but same techniques apply now as for 5 years ago. Aren't we all writing our own chess engines, I have my own called "Norwegian Gambit" that I hope will eventually compete with other Java engines on the CCRL. I as many others use Stockfish for ideas since it is so nicely written and open. Their testing framework Fishtest and it's community also gives a ton of good advice. It is worth comparing your evaluation scores with what Stockfish gets since how to evaluate is probably the biggest unknown in chess-programming still and Stockfish has gone away from many traditional evals which have become urban legends (like the double bishop bonus). The biggest difference however was after I implemented the same techniques as you mention, Negascout, TT, LMR, I started using Stockfish for comparison and I noticed how for the same depth Stockfish had much less moves searched than I got (because of the move ordering).

Move ordering essentials

The one thing that is easily forgotten is good move-ordering. For the Alpha Beta cutoff to be efficient it is essential to get the best moves first. On the other hand it can also be time-consuming so it is essential to do it only as necessary.

1. Transposition table
2. Sort promotions and good captures by their gain
3. Killer moves
4. Moves that result in check on opponent
5. History heuristics
6. Silent moves - sort by PSQT value

The sorting should be done as needed, usually it is enough to sort the captures, and thereafter you could run the more expensive sorting of checks and PSQT only if needed.

About Java/C# vs C/C++/Assembly

Programming techniques are the same for Java as in the excellent answer by Adam Berent who used C#. Additionally to his list I would mention avoiding Object arrays, rather use many arrays of primitives, but contrary to his suggestion of using bytes I find that with 64-bit java there's little to be saved using byte and int instead of 64bit long. I have also gone down the path of rewriting to C/C++/Assembly and I am having no performance gain whatsoever. I used assembly code for bitscan instructions such as LZCNT and POPCNT, but later I found that Java 8 also uses those instead of the methods on the Long object. To my surprise Java is faster, the Java 8 virtual machine seems to do a better job optimizing than a C compiler can do.

Answer 5

Be warned, getting game search right in a threaded environment can be a royal pain (I've tried it). It can be done, but from some literature searching I did a while back, it's extremely hard to get any speed boost at all out of it.

Answer 6

• Transposition Table
• Opening Book
• End Game Table Bases
• Improved Static Board Evaluation for Leaf Nodes
• Bitboards for Raw Speed