fabianVDW wrote: ↑Wed Mar 25, 2020 5:43 pmI have this policy for FabChess aswell, but it terribly failed in multithreaded search. Upto a certain amount of threads, let's say 4-8, one is fine with safe Rust, but for TCEC with 176 Threads I had to wrap the cache and certain shared fields with unsafe. Again though, the idea here is to provide a safe api over the unsafe features, spending effort ensuring that the unsafe code is in fact, safe.
Why should that be necessary? If you have a huge amount of threads and you then need to drop back to writing unsafe code (for which reason?) it defeats the purpose of the language. IMHO. It shouldn't be necessary. I hope this improves in the future.
I know that it's possible to provide safe API's over unsafe code. It's basically what C/C++ and other languages have been trying to do with encapsulation. My C/C++ code has always been very safe; my coding style actually fits Rust's paradigm to a T. I never encountered the borrow checker after day 2, after I just learned to put "mut" or "&mut" before a variable I actually wanted to change.
I'm going to think about the unsafe version of the move list. I just realized that even 128 move lists aren't enough. Stockfish, in some endgames, approaches depths of 128; on very fast computers or on huge numbers of cores, it might already exceed it. So, I built a way for the move list pool to expand when its limits are approached (or even exceeded; I'm testing this with a very small pool, where Perft already starts at depth 6-7 and then works backwards), but at that point, there will be an expensive slowdown.
Just doing "let mut list [Move; 256]" is not going to work, because taking this allocation out of perft sped it up from finding 10 million leaf nodes per second to finding 30 million per second.