To get a rough estimate about how Pleco performs against other engines, it needs to be submitted in the Computer Chess Rating System.

However, a few things need to be done before that can happen.

• [x] Finish the uci command line interface to allow for the full range of commands.
• [x] Finish the LazySMP Searcher to use the TranspositionTable correctly, and allow the table to be resized and cleared.
• [x] Allow parsing of the Board and Limits prior to the start of searching
• [x] Allow for proper time management based on the UCI protocol
• [x] Test the current TimeManagement struct for accuracy & parsing errors.
• [ ] Submit to CCRL for engine rating

Other things that would be of use:

1. Implement use of opening Board bases, SysgzyBases I believe they are called.
2. Allow for endgame board tables.

In order to be considered a modern chess engine, Pleco needs to support the Universal Chess Interface (shorthand is UCI) inside of both the engine, as well as the primary searcher. More information about UCI can be found here.

There are four parts I would like to outline for implementing this.

1) main.rs args

When given the command "uci" as an argument (or stdin after load), Engine::uci(...) should be called, letting the Engine handle it from there.

2) Engine

The Engine must contain a Engine::uci(...) method to allow for communication to and from the GUI. Communication uses stdin and stdout to pass commands back and forth. The command "isready" should allow the engine the opportunity to get both a UCI compatible Searcher (more on this later) and a Board object ready. The GUI can send in options to the Engine before the game actually begins, starting with the "setoption" command. All commands leading up to "go" (which starts the game) can be implemented with a simple IO loop.

3) Mid Game Message sending to / from UCI Searcher

When the Searcher is in the midst of searching, the Engine must act as an intermediary between the GUI and the Searcher. Mid-search, the GUI should only be able to send the command "stop" to the Searcher, which should within reasonable time stop the Search and return the best move found so good.

Some problems that need to be dealt with in concern of this:

• How do we allow stdin to be scanned in a separate thread, but without impacting search performance?
• What type of structure do we need to pass into the UCI Searcher that allows for checking when to stop?

Furthermore, the Engine needs to be able to do the opposite: Await information from the UCI Searcher and relay that information to the GUI.

4) Implementing the UCISearcher Trait

The UCISearcher Trait should mark specific Searchers as UCI compatible. Currently, the UCISearcher implementation is the following:

pub trait UCISearcher: Searcher {
   fn uci_move(board: Board, timer: &Timer, rx: Arc<Mutex<Option<GuiToEngine>>>) -> BitMove where Self: Sized;
}

Some notes on this:

• Receiver needs to be solidified in uci_move as determined by item 3.
• A Sender needs to be given in somewhere, to allow the chess board to communicate back.
• `fn configuration()' or similar function should allow easily setting up options.

Running Board::get_piece_locations() causes a stack overflow when run. This is the code that causes this bug for me: let board = Board::start_pos() for (sq, piece) in board.get_piece_locations() { debug!("{} {:?}", sq, piece);}`

Currently, all the parallel algorithms implement Principal Variation Splitting (See section on ChessProgramming Wiki) to utilize mutli-core processing. PVS works by searching a set amount of moves sequentially to find an alpha cut-off, and then the remaining nodes are searched in parallel with that alpha cutoff. Can this be done better?

Hello, i am trying to teach neural-network : input as board + bitmove and output as score.

So, i know that pleco provides this function https://docs.rs/pleco/latest/pleco/bots/minimax/fn.minimax.html for example. It returns best BitMove and Score for it.

And my question : Is there any method in pleco like fn minimax_score_move(b: &Board, m: &BitMove) -> i16 that will return score for provided bitmove ?

System Version: macOS 10.14.6 (18G103) Kernel Version: Darwin 18.7.0 rustc 1.41.0-nightly (25d8a9494 2019-11-29) Git: master, 0.1.5, 0.1.6

error[E0635]: unknown feature `const_slice_len`
  --> pleco/src/lib.rs:77:42
   |
77 | #![cfg_attr(feature = "nightly", feature(const_slice_len))]
   |                                          ^^^^^^^^^^^^^^^

The following features need to be stabilized before pleco can compile on stable:

• [ ] const_fn (rust-lang/rust#24111)
• [x] const_indexing (rust-lang/rust#29947)
• [ ] trusted_len (rust-lang/rust#37572)
• [ ] integer_atomics (rust-lang/rust#32976)
• [ ] allocator_api (rust-lang/rust#32838)
• [ ] cfg_target_feature
• [ ] target_feature
• [ ] stdsimd
• [ ] fused

For benchmarking:

• [x] test (Switched to Criterion with #92 )

Dependency stabilization

• [ ] lazy_static nightly (no current tracking issue)

It looks like compilation (on Nightly, release) is failing due to:

error[E0557]: feature has been removed
  --> pleco_engine\src/lib.rs:24:12
   |
24 | #![feature(const_fn)]
   |            ^^^^^^^^ feature has been removed
   |
   = note: split into finer-grained feature gates

tried to build engine by:

$ cargo build --release
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /media/demo/1a16bb7d-7776-4545-b1d6-7f7ec43d7e64/Pleco/pleco/Cargo.toml
workspace: /media/demo/1a16bb7d-7776-4545-b1d6-7f7ec43d7e64/Pleco/Cargo.toml
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /media/demo/1a16bb7d-7776-4545-b1d6-7f7ec43d7e64/Pleco/pleco_engine/Cargo.toml
workspace: /media/demo/1a16bb7d-7776-4545-b1d6-7f7ec43d7e64/Pleco/Cargo.toml
   Compiling prefetch v0.2.0
   Compiling crossbeam-utils v0.8.1
   Compiling memoffset v0.6.1
   Compiling num-traits v0.2.14
error[E0554]: `#![feature]` may not be used on the stable release channel
  --> /home/demo/.cargo/registry/src/github.com-1ecc6299db9ec823/prefetch-0.2.0/src/lib.rs:18:1
   |
18 | #![feature(link_llvm_intrinsics)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `prefetch`

How to solve this?

Right now, we use the standard libraries benchmarking tool for benchmarking.

Despite it's easy of use, there are a couple drawbacks for using it:

• No customization on the number of runs
• Output is limited to a number + estimated degree of confidence

It would be beneficial to switch the benchmarks to Criterion.rs, to get more detailed analysis of the benchmarks, alongside additional benchmark customization.

While great, the standard library's Arc could be made faster for our use case. To name one modification, we do not use the Weak pointer of the standard library Arc.

Some inspiration for this could be from the Server Arc.

I tried to use pleco_engine in Arena but it keeps panicking. I'm running it on Debian buster x86-64.

Reproduction steps:

1. Compile pleco_engine, add engine to Arena, then load it as engine 1
2. Start engine
3. Arena doesn't output analysis, and the logs show that it panicked

2021-05-02 15:14:32.208**----------New game---2021-05-02 15:14:32,208 Sun -------------
2021-05-02 15:14:33.370*1*Start calc, move no: 1
2021-05-02 15:14:33.371-->1:ucinewgame
2021-05-02 15:14:33.371-->1:isready
2021-05-02 15:14:33.371<--1:readyok
2021-05-02 15:14:33.378-->1:position startpos moves e2e4
2021-05-02 15:14:33.378-->1:go wtime 300000 btime 300000 winc 0 binc 0
2021-05-02 15:14:33.378<--1:info id 0 start
2021-05-02 15:14:33.378<--1:thread '1' panicked at 'attempted to leave type `movepick::pick::Pick` uninitialized, which is invalid', /home/makoto/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:660:9
2021-05-02 15:14:33.378<--1:stack backtrace:
2021-05-02 15:14:33.379<--1:   0:     0x55fcb6c5c530 - std::backtrace_rs::backtrace::libunwind::trace::hdcf4f90f85129e83
2021-05-02 15:14:33.379<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
2021-05-02 15:14:33.380<--1:   1:     0x55fcb6c5c530 - std::backtrace_rs::backtrace::trace_unsynchronized::h2669e30cb82f6732
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2021-05-02 15:14:33.380<--1:   2:     0x55fcb6c5c530 - std::sys_common::backtrace::_print_fmt::hfbda19e17f6db318
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:67:5
2021-05-02 15:14:33.380<--1:   3:     0x55fcb6c5c530 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h1a8751bf59281272
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:46:22
2021-05-02 15:14:33.380<--1:   4:     0x55fcb6c1b0ef - core::fmt::write::h7aa6cd0067dca82a
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/core/src/fmt/mod.rs:1094:17
2021-05-02 15:14:33.380<--1:   5:     0x55fcb6c5bd44 - std::io::Write::write_fmt::hd7dd3a1df9b6befb
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/io/mod.rs:1580:15
2021-05-02 15:14:33.380<--1:   6:     0x55fcb6c5b8c5 - std::sys_common::backtrace::_print::h551e9ec8a9fa8106
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:49:5
2021-05-02 15:14:33.380<--1:   7:     0x55fcb6c5b8c5 - std::sys_common::backtrace::print::ha4b1c5e95fa040b3
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:36:9
2021-05-02 15:14:33.380<--1:   8:     0x55fcb6c5b8c5 - std::panicking::default_hook::{{closure}}::h0b34c9ab7fb9f857
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:208:50
2021-05-02 15:14:33.380<--1:   9:     0x55fcb6c5a8bb - std::panicking::default_hook::h3067e8318decd17a
2021-05-02 15:14:33.380<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:225:9
2021-05-02 15:14:33.380<--1:  10:     0x55fcb6c5a8bb - std::panicking::rust_panic_with_hook::h81b8facc50f34daa
2021-05-02 15:14:33.381<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:591:17
2021-05-02 15:14:33.381<--1:  11:     0x55fcb6c75910 - std::panicking::begin_panic_handler::{{closure}}::ha376ab85d95a000e
2021-05-02 15:14:33.381<--1:  12:     0x55fcb6c758ac - std::sys_common::backtrace::__rust_end_short_backtrace::h6795c8afdd1a77e6
2021-05-02 15:14:33.382<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:141:18
2021-05-02 15:14:33.382<--1:  13:     0x55fcb6c7585d - rust_begin_unwind
2021-05-02 15:14:33.382<--1:BytesRead > 0
2021-05-02 15:14:33.382<--1:n > 0
2021-05-02 15:14:33.382<--1:-- LiesThread.Execute terminated --
2021-05-02 15:14:33.383<--1::5
2021-05-02 15:14:33.383<--1:  14:     0x55fcb6c131f0 - core::panicking::panic_fmt::hbe99dddd3092ba3c
2021-05-02 15:14:33.383<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/core/src/panicking.rs:92:14
2021-05-02 15:14:33.383<--1:  15:     0x55fcb6c1313c - core::panicking::panic::h3de4db67bd397eb3
2021-05-02 15:14:33.383<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/core/src/panicking.rs:50:5
2021-05-02 15:14:33.383<--1:  16:     0x55fcb6c3ae2c - pleco_engine::search::Searcher::search::h5101e7830a14161b
2021-05-02 15:14:33.383<--1:  17:     0x55fcb6c3a524 - pleco_engine::search::Searcher::search::h5101e7830a14161b
2021-05-02 15:14:33.383<--1:  18:     0x55fcb6c36378 - pleco_engine::search::Searcher::search_root::ha097df830d13b18a
2021-05-02 15:14:33.383<--1:  19:     0x55fcb6c359ac - std::sys_common::backtrace::__rust_begin_short_backtrace::hfe1ee00e5ba6c1af
2021-05-02 15:14:33.383<--1:  20:     0x55fcb6c35679 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h5f7dd8b7c406aef8
2021-05-02 15:14:33.383<--1:  21:     0x55fcb6c79455 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h3aa31cb6360b59d9
2021-05-02 15:14:33.383<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/alloc/src/boxed.rs:1546:9
2021-05-02 15:14:33.383<--1:  22:     0x55fcb6c79455 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h7719d3c7c5841461
2021-05-02 15:14:33.383<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/alloc/src/boxed.rs:1546:9
2021-05-02 15:14:33.383<--1:  23:     0x55fcb6c79455 - std::sys::unix::thread::Thread::new::thread_start::hfbe13ead469fd0bc
2021-05-02 15:14:33.383<--1:                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys/unix/thread.rs:71:17
2021-05-02 15:14:33.383<--1:  24:     0x7fe79102afa3 - start_thread
2021-05-02 15:14:33.383<--1:  25:     0x7fe790dd34cf - clone
2021-05-02 15:14:33.383<--1:  26:                0x0 - <unknown>

There are mutliple uses of unsafe that can be either replaced with safe code or with an external crate. I propose using this issue to discuss these cases and then document in the code why each unsafe is fine. This makes code review much easier.

• Transmutes to enums. Totally fine although the compiler generates the same assembly for safe match statements.
• Custom Arc without weak counter from servo_arc. The discussion to include this in std died here. Why not use the crate? The currently published version has possible UB https://github.com/servo/servo/issues/26358
• Custom TranspositionTable that allows to trigger undefined behaviour from safe code (if I understand the code correctly):

let tt = TranspositionTable::new_num_entries(40000);
let prng = PRNG::init(932445561);
let key: u64 = prng.rand();
let (found1, entry1): (bool, &mut Entry) = tt.probe(key);
let (found2, entry2) = tt.probe(key); // second mutable reference to the same object -> UB

I did not look into the usecases yet. There are probably alternatives available in the ecosystem.

• Custom TimeManager: Internals can be replaced with atomics and Ordering::Relaxed load/store (although the Instance might be problematic). Also: do not create mutable references from UnsafeCell in unguarded code but use ptr::write to avoid UB.
• Unchecked array access with enums like this: https://github.com/sfleischman105/Pleco/blob/292d38e78dd7d82112aef79a379e8329707e3659/pleco_engine/src/tables/counter_move.rs#L24 I am quite sure that the compiler will elide the bound checks. Another possibility is to use enum_map or static asserts.
• Remove static mut and replace it either with lazy_static or with const fn initialization. https://github.com/sfleischman105/Pleco/blob/292d38e78dd7d82112aef79a379e8329707e3659/pleco_engine/src/tables/pawn_table.rs#L82
• Use arrayvec or tinyvec for MoveList.
• mem::uninitialized to gether with an enum that encodes if a field is used or not. Is there a reason that this is a repr(u8) enum instead of carrying the data itself? https://github.com/sfleischman105/Pleco/blob/292d38e78dd7d82112aef79a379e8329707e3659/pleco_engine/src/movepick/mod.rs#L64

The README says "This project is for speed comparisons between the two languages". Would you please update the README to give some speed comparisons between Pleco and Stockfish?

Hi! I'm planning on writing a chess engine in rust to learn the language better and I'm looking for a move generator to use. I'm currently in between Pleco and chess. Do you have any benchmarks on which one is a faster move generator? Thanks in advance!

This is probably the weakest part of the engine right now: playing well into the end-game.

Porting over Stockfish End of Game table bases would fix this, and seems pretty easy to do.

The following features need to be stabilized before pleco_engine can compile on stable:

• [ ] const_fn (rust-lang/rust#24111)
• [x] const_indexing (rust-lang/rust#29947)
• [ ] fused (rust-lang/rust#35602)
• [ ] integer_atomics (rust-lang/rust#32976)
• [ ] allocator_api (rust-lang/rust#32838)
• [ ] trusted_len (rust-lang/rust#32838)
• [ ] ptr_internals

For benchmarking:

• [x] test (Switched to Criterion with #92 )

Dependency stabilization

• [ ] lazy_static nightly (no current tracking issue)
• [ ] pleco needs to be usable on stable as defined by #76 .