cimarronost/monolith

UCI chess engine

Monolith 2

Monolith is a powerful open source chess engine written in C++17, compliant with the Universal Chess Interface (UCI) protocol. It uses the alpha-beta search algorithm. The search and parallelization-algorithms, the position evaluation principles, the fast move-generating methods, the support for opening books and endgame table-bases, all of it wasn't newly invented in this engine. Monolith is rather a new original implementation of many well-established concepts of computer chess, resulting in its own unique personality as a chess playing entity.

Playing against the top-notch chess engines leading the rating lists, Monolith will have not much of a winning chance. That picture however is totally different when playing against humans, be it hobby-players or chess Grandmasters, who almost certainly wont stand a chance against Monolith.

Monolith is not a standalone chess program and needs a graphical interface in order to be used properly, for example the freely available Arena, Cute Chess and Tarrash for PCs or DroidFish and Chess for Android for Android devices.

Strength

Rating list	CPU Threads	Approximate Elo
CCRL 40/15	1	3000
CCRL Blitz	4	3100
CCRL 40/2 FRC	1	3120
TCEC	176	3350

Main features

• Move-generation: staged, pseudo-legal, using magic bitboards or PEXT bitboards
• Evaluation: hand crafted, tuned automatically with the Texel-tuning-method
• Search: alpha-beta algorithm & principal variation search
• Support for:
  • Universal Chess Interface (UCI) protocol
  • Multiple CPU-threads through Shared Hash Table & ABDADA
  • PolyGlot opening books
  • Syzygy endgame table-bases
  • Fischer Random Chess / Chess960

Which executable to use

• x64-pext is the fastest, making use of the PEXT instruction which only works on recent CPUs (Intel Haswell and newer).
• x64-popcnt is almost as fast, making use of the POPCNT instruction which is supported by most non-ancient CPUs.
• x64 does not need modern CPU instruction sets and therefore runs a bit slower but works also on old computers requiring only a 64-bit architecture.
• x86 runs also on 32-bit systems but is considerably slower because there is no dedicated code for 32-bit instruction-sets.
• armv8 targets the 64-bit ARM architecture (AArch64) and works on most devices running Android, like mobile phones.
• armv7 targets the 32-bit ARM architecture and runs also on old Android devices.

You can compile it yourself

Run make [ARCH=architecture] [COMP=compiler]

• supported architectures, see above for more detailed descriptions:
  x64-pext, x64-popcnt, x64, x86, armv8, armv7;
  Omitting ARCH will use the -march=native flag and hopefully optimize the build for the building machine.
• some supported compilers:
  g++, icpc, clang++, armv7a-linux-androideabi16-clang++, aarch64-linux-android21-clang++;
  Omitting COMP will use g++ as default.

Running the Monolith bench command should result in a total of 22296396 nodes if compiled correctly.

UCI options overview

• Threads: Number of CPU threads than can be used in parallel. Default is 1.
• SMP: Algorithm to be used when searching with multiple threads. Default is SHT. ABDADA performs equally good on a small number of threads but may perform better with more threads.
• Ponder: Searching also during the turn of the opponent. Default is false.
• Hash: Size of the Transposition Table. Default is 128 MB.
• Clear Hash: Clearing the hash table (i.e. to be able to start a new search without being affected by previous search results saved in the Transposition Table).
• UCI_Chess960: Playing the chess variant Fischer Random Chess / Chess960. Default is false.
• MultiPV: Number of Principal Variations to be displayed in detail. Default is 1. A higher value may be useful for analysis of positions but decreases the playing strength of the engine.
• Move Overhead: Time buffer if the communication with the engine is delayed, in order to avoid time losses. Default is 0 milliseconds.
• Log: Redirecting all output of the engine to a log file. Default is false.
• OwnBook: Using own PolyGlot opening book. Default is true, i.e. if the book specified by Book File (see below) is found, it will be used.
• Book File: Location of the PolyGlot opening book. Default is set to the same location as the running engine, the default book name is Monolith.bin.
• SyzygyPath: Location of the Syzygy table-bases. Default is <empty>. Multiple paths should be separated with a semicolon (;) on Windows and with a colon (:) on Linux.
• SyzygyProbeDepth: Limiting the use of the table-bases to nodes which have a remaining depth higher than SyzygyProbeDepth. Default is set to 5, i.e. the table-bases are only used if the remaining search-depth of a node is 5 or higher, thus preventing the expensive probing at nodes near the leaves of the search-tree. A higher value is more cache-friendly and should be used if the speed of the engine drops a lot because of slow table-base access. A smaller value might lead to stronger play in the endgame on computers where table-bases can be accessed very fast (e.g. SSD).
• SyzygyProbeLimit: Number of pieces that have to be on the board in the endgame before the table-bases are probed. Default is 7 which is the upper limit of pieces that Syzygy table-bases currently support.

Additional unofficial commands

• bench: Running a couple of benchmark searches of an internal set of various positions.
• perft [depth]: Running perft up to [depth] on the current position.
• eval: Computing the static evaluation of the current position without the use of the search function.
• board: Displaying a basic character-chessboard of the current position.
• tune [positions.epd] [threads]: Tuning the evaluation parameters with a set of positions. This option is only available if the compilation target tune was chosen.

Acknowledgements

Big thanks go to the Chess Programming Wiki and to the equally fantastic community on talkchess.com which offer an endless source of wisdom and inspiration. With these great resources everybody can write a chess engine. Thanks also to the CCRL group for including the engine in their rating lists since the very start of development.
Some of the ideas incorporated into Monolith derive from the marvellous and insanely strong chess engines Stockfish and Ethereal, so thanks to all the people involved in those engines for pushing the limits and making their ideas open source. Special thanks also go to Tom Kerrigan who provided a lot of information about the simplified ABDADA SMP algorithm, to Ronald de Man for providing the Syzygy endgame table-bases & probing code, to Fabien Letouzey for the PolyGlot opening book format, and to grzegoszwu for lending Monolith a graphical face.

License

Monolith is distributed under the GNU General Public License. Please read LICENSE for more information.

Have fun

That's what it's all about.

monolith's Issues

unofficial "tune" command : how does it work ?

In your README, under "Additional unofficial commands", you describe a 'tune' option :

tune [positions.epd] [threads]: Tuning the evaluation parameters with a set of positions. This option is only available if the compilation target tune was chosen.

To try this, i first compiled such binary (on Linux) by doing :

make ARCH=x64-pext tune

and indeed the resulting binary file differs; its size is 330 Kb compared to 297 Kb for the normal executable file. Also now the 'tune' command gives output (although it seems useless when no EPD file is given as parameter).

I did not yet try to 'tune' Monolith by any EPD file, because i don't fully understand this process and i can not imagine a way to test the result. First question that comes to mind : when processing such tune command, will Monolith create a 'tuned file' or any config file which holds the result ? Or will the binary itself be changed ? -i guess not .. How does 'tune' work ? Can you point us to information of such process or give an example ?

Monolith 1.0 doesn't find all TBs

It appears it finds all 145 6 men but only 330 out of 365 3-4-5 mens on windows 10. Haven't checked any other OS yet.

memory error thrown

in fritz 16 when in kibitzer or analysis mode the engine throws error msgbox "memory could not be written."
it happens only in certain positions when moving backward (not forward) in a game.

Example: whites 43rd move to black's 42nd Bf4 move throws error.

[Event "Montreal International"]
[Site "Montreal"]
[Date "1979.04.13"]
[Round "3"]
[White "Larsen, Bent"]
[Black "Karpov, Anatoly"]
[Result "1/2-1/2"]
[ECO "B10"]
[WhiteElo "2620"]
[BlackElo "2705"]
[PlyCount "85"]
[EventDate "1979.04.11"]
[EventType "tourn"]
[EventRounds "18"]
[EventCountry "CAN"]
[EventCategory "15"]
[SourceTitle "MCL"]
[Source "ChessBase"]
[SourceDate "1999.07.01"]
[SourceVersion "1"]
[SourceVersionDate "1999.07.01"]
[SourceQuality "1"]

1. e4 c6 2. c4 d5 3. exd5 cxd5 4. cxd5 Nf6 5. Qa4+ Nbd7 6. Nc3 g6 7. d4 Bg7 8.
   Qb3 O-O 9. Bg5 Nb6 10. Bxf6 Bxf6 11. Nf3 Bg7 12. Be2 e6 13. dxe6 Bxe6 14. Qb5
   a6 15. Qb4 Nd5 16. Qxb7 Rb8 17. Qxa6 Rxb2 18. Nxd5 Qxd5 19. O-O Ra8 20. Qd3
   Raxa2 21. Rxa2 Qxa2 22. Re1 Bf8 23. Bf1 Bb4 24. Rc1 Rxf2 25. d5 Rxf1+ 26. Qxf1
   Qxd5 27. Kh1 Be7 28. Rd1 Qb7 29. Rb1 Qa7 30. Ra1 Qc5 31. Nd2 Kg7 32. Re1 Qd4
2. Qe2 Bf6 34. Ne4 Bh4 35. Rd1 Qe5 36. Qf3 h5 37. Qc3 Qxc3 38. Nxc3 Bf6 39.
   Ne4 Be5 40. Kg1 Bf5 41. Nc5 Bc7 42. Na6 Bf4 43. Nb4 1/2-1/2

3-31-18:

It has occurred to me that this error could be a compiler problem for new amd ryzen cpu's - as a few other minGW engines throw same error code at same spot. I have not tested Monolith on intel cpus yet.

Can't compile on macOS

I have tried to compile Monolith on my iMac, using both g++ and clang but no hope. Below is one of my tries and the error about linking:

make ARCH=x64 COMP=clang++ 
clang++ -std=c++17 -O3 -m64 -static -Wall -Wextra -Wpedantic -DNDEBUG attack.cpp bench.cpp bit.cpp board.cpp eval.cpp magic.cpp main.cpp misc.cpp move.cpp movegen.cpp movepick.cpp movesort.cpp polyglot.cpp random.cpp search.cpp syzygy.cpp texel.cpp thread.cpp time.cpp trans.cpp types.cpp uci.cpp zobrist.cpp -pthread -s -o Monolith-x64.exe
ld: warning: option -s is obsolete and being ignored
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)

analysis of mate-in-n positions wrong score & PV output

Sometimes when analyzing a not too easy mate-in-n position, the score and PV output may not be right, i.e. the "cp mate x" output may not correspond to the mate the PV leads to or the score & PV may jump to simply wrong mates at higher iterations. The issue doesn't affect game play because the "bestmove" output is right.

time forfeits when playing with time increment

Monolith loses most of its games due to time forfeits in cutechess-cli when playing with a time increment. Assigning too much time at move 40 when movestogo=1 seems the issue, although I'm confused about the way the increment is applied in cutechess-cli.

where is the Book file ?

In the UCI options i see Monolith can use a book file called Monolith.bin .. where can i get it ?