Chess engine: Orion 0.9 NNUE

Orion - UCI chess engine
Author - David Carteau, Rating JCER=3017

Orion 0.9  - author:

More than one year since the last release already: time flies ! I have been very busy these last months, without a lot of time to dedicate to Orion, but the next version is here (it is actually ready since... last November !), with:

support for SMP

a 24x smaller neural network

speed improvement and memory consumption reduction

correction of a small bug in 3-pieces endgame evaluation

Support for SMP

I'm really happy to announce the support for SMP : Orion will now be able to think using several CPUs/threads in parallel, hopefully resulting in a stronger play ;-)

This required a lot, what am I saying, a ** LOT ** of work: I had to redesign the main parts of the engine, to ensure thread-safe execution, split, refactor, simplify, rearrange the code to avoid problems when computing in parallel. On the contrary, I was surprised by the simplicity of the Lazy SMP approach, that's brilliant !

Smaller network architecture

The other big change is the architecture of the neural network: it is now much simpler than the previous one, for a more or less equivalent strength (~20-30 elo weaker in my own tests). I replaced the 40960x2 weights in the first layer by a simple 768x2 scheme (6 types of piece x 2 colors x 64 squares = 768).

This probably hampers accuracy in some complex positions, but globally speeds up evaluation as you don't have to recompute all the first layer when the king is moving (this is really helpful in endgame positions where kings have more mobility). This choice resulted in a 24x smaller network (421 kB vs 10 MB)...!

I'm really happy with the result: It seems possible to compress chess knowledge a lot !

Important note about originality

I know that some people are looking for originality: do not forget that engine creation can remain for some of us (including me) a hobby and/or a way to learn programming and A.I. !

This has always been my goal: develop a 100% original engine, not only in terms of playing style (that's not the case for the moment) but also in terms of code: Orion is not derived from any other engine, I wrote 100% of the lines of code, in my own way, always after having taken the time to understand what I was doing (the most recent example being the NNUE experiments I led in 2020).

For example, Orion is based on a "only-legal" move generator, using flags embedded in each move representation to help sorting and pruning moves during search. Its transposition table also uses the number of pieces on the board as a criterium to replace old-entries.

But then comes the issue of the data used to train the neural network with the NNUE approach.

As for the 0.8 version, the provided network has been trained on positions that were statically evaluated with the nn-82215d0fd0df.nnue network which is the one embedded in StockFish 12. The StockFish engine itself was not used at all in that process: I took the network, reused the code I developed for my NNUE experiments to read the weights and evaluate a bunch of positions that I collected from CCRL games, and then trained my own network with my own (shared) Cerebrum library (note: this time, I was able to use only 128 million of positions, compared to the 360 million used for 0.8).

Finally, from this perspective, I think one cannot consider that Orion is - at this stage - a 100% original work, as it uses knowledge coming from another engine. Please note that starting from v0.4, it has actually been the case: I was previously using StockFish 8 (static) evaluations to tune parameters of my handcrafted evaluation function.

But, for sure, this remains the goal, and I already started to work on reaching that objective...

The "zero" approach

I think the most exciting challenge now that I know how to design and train neural networks is to find a way to train a network from zero, i.e. only using results of games (win / draw / loss). Inspired by an idea proposed by Connor McMonigle (Seer author), I tried to train one of such network, without success so far.

The idea is to consider endgame positions (3-4-5-6 pieces), use the results provided by Syzygy tablebases, train a network on these positions, use the engine to evaluate 7-pieces positions with the trained network (after a depth 'd' search), re-train a new network on these labelled 3-to-7 pieces positions, and then restart all the process for 8 up to 32 pieces positions. The beauty of this approach is that the network is trained only using the endgame outcome, and shall learn how to "retropropagate" to middlegame positions the expected result.

Orion 0.9 NNUE download