Skip to content

Releases: Algorhythm-sxv/Cheers

1.0.0

01 Oct 13:42
Compare
Choose a tag to compare

This release is the feature-complete version of Cheers, with a significant strength improvement over 0.3.x

STC:
Elo   | 180.91 +- 8.06 (95%)
Conf  | 8.0+0.08s Threads=1 Hash=8MB
Games | N: 5010 W: 2823 L: 427 D: 1760
Penta | [16, 141, 560, 1007, 781]

LTC:
Elo   | 213.55 +- 7.88 (95%)
Conf  | 60.0+0.60s Threads=1 Hash=8MB
Games | N: 5002 W: 2945 L: 207 D: 1850
Penta | [3, 72, 461, 1114, 851]

This improvement was realised with a number of changes and additions to the search functionality, leaving evaluation untouched. These self-test results are likely to be inflated and comparing Cheers 1.0.0 to other engines may yield smaller Elo differences over 0.3.x. Nevertheless I believe this version will break the 3000 Elo barrier on the CCRL rating list.

Change Highlights:

  • Syzygy endgame tablebase support with pyrrhic-rs, a Rust translation of Andrew Grant's Pyrrhic
  • Continuation History Heuristic
  • History-based Late Move Reductions
  • Node-based time management at the search root
  • Capture History for move ordering
  • Split capture and quiet move lists for faster move sorting

Bugfixes

This version fixes a longstanding but only recently noticed bug that would cause hangs during OpenBench tests. The underlying cause was that very rarely the test runner's time margin settings would result in Cheers receiving a negative amount of time to calculate a move, which would cause a failure when parsing the time as an unsigned integer.

What next?

I am stopping work on Cheers for the time being in favour of my new engine, CriNNge which is an opportunity for me to build an engine free of Cheers' technical debt and explore new techniques without the invasive changes necessary to add them to Cheers. I may yet return to Cheers in the future, but only time will tell!

0.3.1

31 Oct 15:51
Compare
Choose a tag to compare

Bugfix: Chess960 castling

This release fixes a bug related to Chess960 castling, where boards would get corrupted if the rooks started on the C or G files, where the king would move to after castling. This would cause crashes and make a lot of Chess960 positions unplayable.

0.3.0

24 Sep 07:52
Compare
Choose a tag to compare

This version features a ground-up rebuild of the evaluation function for a significant strength improvement over version 0.2.2

STC:
ELO   | 206.78 +- 10.22 (95%)
CONF  | 8.0+0.08s Threads=1 Hash=8MB
GAMES | N: 5000 W: 3446 L: 778 D: 776

LTC:
ELO   | 241.04 +- 10.46 (95%)
CONF  | 60.0+0.60s Threads=1 Hash=64MB
GAMES | N: 5000 W: 3568 L: 566 D: 866

These self-play results are likely inflated, and comparing Cheers 0.3.0 to other engines will result in smaller Elo gains over 0.2.2.

Evaluation data

On top of creating a stronger evaluation function with the existing dataset, the open lichess-big3-resolved dataset was incorporated for another large strength increase.

Bugfixes

This release fixes a long-standing 'bug' in the reporting of castling moves in regular chess vs. chess960. cutechess-cli, a de-facto standard of sorts, will accept 960-style castling (king takes friendly rook) regardless of the UCI_Chess960 setting, but other programs will crash if regular castling (king moves 2 squares) is not used. #2

This release properly respects the UCI_Chess960 setting and will report castling correspondingly. As to what the 'correct' behaviour should be, it is underspecified in the UCI documentation.

0.2.2

26 Mar 10:33
Compare
Choose a tag to compare

This is a hotfix release that corrects time management issues around movestogo

When using movestogo Cheers 0.2 would use the opposite side's clock to select the time. This bug has been fixed and the underlying ergonomic issue that caused the mistake has also been corrected.

0.2

22 Mar 20:06
Compare
Choose a tag to compare
0.2 Pre-release
Pre-release

BUG ALERT: when given a movestogo command Cheers 0.2 will use the opponent's clock to decide the move time, which can result in timeouts when movestogo = 1. This is fixed in 0.2.2

Version 0.2 represents a large improvement over 0.1, with fewer bugs, higher speed, and more/better features.

This version outperforms 0.1 by approximately 200 Elo at 8+0.08s and 60+0.6s time controls:

ELO   | 207.61 +- 7.38 (95%)
CONF  | 8.0+0.08s Threads=1 Hash=8MB
GAMES | N: 10000 W: 7039 L: 1686 D: 1275

ELO   | 216.10 +- 7.32 (95%)
CONF  | 60.0+0.60s Threads=1 Hash=64MB
GAMES | N: 10000 W: 7019 L: 1494 D: 1487

Bugfixes

As these things tend to go, I found two small typos in the evaluation function about a day after the 0.1 release that amounted to ~80 Elo when fixed.

Search rewrite

Cheers' search function has been rewritten from scratch with version 0.2, resulting in more readable code and 100 Elo points over 0.1 thanks to better implementations of the same techniques.

Lazy SMP

Cheers now supports multithreaded search with Lazy SMP, which provides ~50 Elo per doubling of threads:

2 threads vs 1 thread:
ELO   | 55.68 +- 18.40 (95%)
SPRT  | 5.0+0.05s Threads=2 Hash=16MB
LLR   | 2.96 (-2.94, 2.94) [0.00, 5.00]
GAMES | N: 1095 W: 510 L: 336 D: 249

4 threads vs 1 thread:
ELO   | 78.94 +- 22.32 (95%)
SPRT  | 8.0+0.08s Threads=4 Hash=32MB
LLR   | 2.96 (-2.94, 2.94) [0.00, 5.00]
GAMES | N: 761 W: 377 L: 207 D: 177

4 threads vs 2 threads:
ELO   | 43.88 +- 16.09 (95%)
SPRT  | 8.0+0.08s Threads=4 Hash=32MB
LLR   | 2.96 (-2.94, 2.94) [0.00, 5.00]
GAMES | N: 1393 W: 618 L: 443 D: 332

Rust's concurrency guarantees and my thread-safe transposition table made SMP implementation extremely easy, much more than I was expecting.

Improved static evaluation

Cheers' static evaluation function was re-tuned with data available at the Zurichess repository, which provided a total of ~65 Elo points of improvement after a subsequent search tune. I don't want to rely on the data of others in the long term, but generation of high-quality texel tuning data is a time- and resource-intensive task that I am not yet prepared to do.

0.1

22 Dec 12:37
8a1f592
Compare
Choose a tag to compare
0.1

This is the first release of Cheers, providing a reasonable strength on a single thread

Known Issues

  • The error handling around UCI commands is not complete, and so the engine may panic and exit if provided invalid UCI command. The parser will correctly report some errors but remains rather simple and so cannot account for all edge cases.

Next steps

  • The next release of Cheers will implement multithreading with Lazy SMP on top of several planned single-threaded improvements for a significant Elo boost