Cake 1.88 Help

Overview

Cake 1.88 is a checkers engine for CheckerBoard. If you have trouble running Cake 1.88, read this document carefully, and if you cannot find an answer to your problem, send me a report by email.

System Requirements

The endgame databases for more than 6 pieces are large. Here's an overview of minimum system requirements for running Cake with different sizes of the endgame database:
  • 6-piece: 64MB RAM, 40MB free HD space
  • 7-piece: 96MB RAM, 376MB free HD space
  • 8-piece: 128MB RAM, 4.33GB free HD space
Note that the required RAM is a minimal requirement. To run the 7- or 8-piece database, I recommend at least twice the amount of RAM, and for the 8-piece database, more is always better - you cannot have too much :-)

Engine Options

In CheckerBoard, you can use the engine options dialog to set the following options of Cake:
  • Book
    choose from 4 different book settings. You can turn the book off entirely, or you can select one of 3 book strength levels. When the book is set to "best moves", it will always play the same move in the same position, the move it considers to be best. Best means that it has the highest value, and the most moves following it. When the book is set to "good moves", it will pick one of the moves with the highest value at random, regardless of the depth of the lines. When the book is set to "all kinds of moves", it will play any of the moves which are within 10 points of the value of the best move in the position at random. To get maximum playing strength, use "best moves". To get more variety of play (and to get a better chance to win a game), use "all kinds of moves". For something in between, use "good moves".
  • Memory - Hashtable
    You can set the size of the hashtable from 8 to 2048 MB in powers of 2. The larger the hashtable, the faster the program searches to a fixed depth. However, there is a limit of usefulness: The hashtable stores value/position pairs of previous searches. If the same position turns up again in the search at another place, the program does not have to search again. Cake can store 1 million positions in 8MB RAM, or 32 million positions in 256 MB RAM. If you are running the program at a fast level where it does not search many positions for a move, then a large hashtable is a waste of memory. Here's an example: When I run Cake on my 2018 Core i7 Laptop, it searches about 4 million nodes per second. If I set it to search 5s/move, that means it will search about 20 million positions. Therefore, it needs at most 128 to 256 MB of RAM for the hashtable are quite sufficient. This type of calculation overestimates the RAM necessary for the hashtable, and you can divide the result by a factor of 2-4, Meaning that for this kind of level, 32 to 64 MB for the hashtable is quite sufficient.
  • Memory - Endgame DB
    Since the 8-piece database is so big, it cannot be kept in memory all the time unless you allocate over 4 GB of RAM for the endgame database. If you give it less memory, the program uses a certain amount of memory to store recently accessed positions in the endgame database. The more memory it has for this database cache, the less it will have to access the harddisk, which is very slow in comparison to the RAM. You can set the amount of RAM Cake will use for the database cache here. Changes in the database cache size will only take effect after you restart CheckerBoard. Also, there is a 40MB memory overhead that is not included in the reported DB cache size. Example: if your computer has 4 GB RAM, you can set the DB cache size to 1024 MB, and the hashtable size to 256 MB. This means that Cake will be using 1024 + 40 + 256 = 1320 MB RAM. You should never use more RAM than you actually have in your system, else the program will slow down to a crawl. CheckerBoard will try to prevent you from doing this.
  • All Scores Mode
    If this option is checked, Cake will compute the scores for all moves, not just for the best move. In this mode, it searches more slowly, but on the other hand you get the scores for all moves. This is very nice if you are going over a game looking for blunders or improvements as you get to see the evaluation of all moves at once.

Status Bar Output

While it is thinking about a move, Cake will tell you some of the details of it's thinking process. A typical output when in book is this:
book  23-18 v14 d12   22-17 v8 d8   28-24 v6 d9   22-18 v4 d8   27-24 v0 d9   23-19 v-4 d6   21-17 v-4 d2   
which means that there are 7 moves in the opening book. The move 23-18 has a value of +14, and 12 more book moves after it in the main line. The move 23-19 has a value of -4 and 6 more moves in the main line. Once out of book, the status bar line will look like this:
depth 25/43/23.5  time 82.28s  value=56  nodes 61024837  741kN/s  pv 24-20 16-19 32-28  5- 9 27-24  9-14 21-17 14x21 
The first 3 numbers report the search depth. 25 is the nominal search depth, 43 the maximal search depth, and 23.5 the average search depth. The nominal search depth is the depth Cake attempts to search on this iteration. However, some lines are searched deeper because of selective extensions, and other lines are searched less deep because of pruning. The next number is the search time in seconds. Next, the value of the position. The higher this is, the better Cake thinks the position is for the side to move. 100 points correspond to winning a man, 0 means an equal position. Values around +/-1000 indicate database wins/losses. Next is the number of positions Cake searched, then the number of positions it searched per second. Here, it searched 741kN/s or 741'000 positions per second. The faster your computer is, the higher this number will be. Finally, it prints the first 8 moves of the main line of it's analysis. For technical reasons I can't explain here, this main line may not be correct, but it is most of the time (for experts: it's not easy to get a main line from MTD searches).

The Opening Book

The opening book of Cake is the result of automated analysis on all 174 official 3-move openings of the ACF. It was computed in 2001 (!) with a beta version of Cake Sans Souci (the predecessor of Cake Manchester) in 6 weeks. Naturally, 6 weeks is not long enough to compute a perfect opening book, and so this opening book certainly has some weaknesses, especially in the barred ballots. But it is better than the old opening book, and good enough to give even the best humans (and most programs) a real challenge in the opening. Since there is no reference to published play at all in this book, it probably also contains some original moves that are not considered in published play.

The Endgame Database

I wrote an endgame database generator in 2001 and computed the 4vs4 subset of the 8-piece endgame database with it. The Cake endgame database has a smaller memory overhead than the Chinook database (about 40 instead of about 70MB for the 8-piece database), and it is compressed better by about 20%, lowering the minimal/recommended system requirements. The CheckerBoard 1.5 (and greater) installation includes the 2-4 piece endgame database. You can generate the 6-piece database with a simple menu click in CheckerBoard on your own computer. You can download the larger databases, this will require some patience though... Cake expects the database files (db2.cpr, db2.idx, db3.cpr, db3.idx etc) to be located in a folder called "db" inside the CheckerBoard folder. If you download the larger databases, this is where you have to save the files to. Cake will not run without the 4-piece database which is included in the CheckerBoard 1.5 (or greater) installation. If it cannot find this database, it will terminate CheckerBoard when asked to think (the CB window will close). If this happens, make sure that the "db" folder is present and has the required database files inside.

Credits

All code in Cake is original code. But a lot of other people have been important in the development of Cake, first and foremost Ed Gilbert with whom I have had a friendly rivalry for over 20 years. He kept improving his KingsRow engine and by trying to keep up with each other we both created much stronger engines than we could have on our own.

Other people worth mentioning are Jonathan Schaeffer and his Chinook project which got me interested in checkers programming in the first place. I also used the Chinook endgame database for a long time until I computed my own endgame database. In the early days, Nelson Castillo and his Dama program provided me with some competition. Thomas Lincke computed the first opening book for Cake and introduced me to drop-out-expansion. Ed Trice called me "denser than a neutron star about to collapse into a black hole", which made me compute the 8-piece database. George Miller kindly gave me a copy of DEO's Encyclopedia of Checkers, from which I learned a little something about checkers. George Miller, Mac Banks and Gerry Lopez made the las Vegas computer world championship possible, which made me work harder on Cake than ever before, both before and after the event. Last but not least, whenever I was tired of programming, I got a little help from the little Gecko in my office!


Updated by Martin Fierz on July 20th 2020. Feedback to checkers_at_fierz.ch