In the 70's and 80's, people where of the opinion that assembler was the only serious language to write software in.Joost Buijs wrote: ↑Mon Sep 14, 2020 7:21 pm All this fancy stuff will put you in a straitjacket, I don't know about Rust ('Rust roest' we say here in Holland), but I still think C/C++ is the only serious language to write a chess engine in. Most other languages output slower code (or the compilers are worse), for instance I keep a shadow copy of my engine in Pascal (Free Pascal to be exact) and it is at least 30 to 40% slower as my C++ version.
Rust can be as fast as C and C++. Yes, it's a LOT harder to get started with (especially compared to C), just because you have to know quite a lot about the language if you want to do non-trivial things. However, if you get going, you can be close to 100% sure that if your code compiles, it will run exactly as intended if you didn't make any logic mistakes. (lLike: getting stuff[10] if there are only 5 elements, saying "if x >= 5" if you actually meant 6.)
While Rust isn't an easy language, and I'm sometimes frustrated by how hard some stuff is to actually implement, in the end I'm always glad about it. I'd rather have a hard time during implementation and then knowing all will (very probably) be correct, than having an easy time during implementation and then having to resolve crash bugs because somewhere, I did something that isn't 100% correct.
C is a very easy language to learn, but very hard to write correctly. (I know... I've written a lot of it in the past.)
Rust is a very hard language to learn, but very easy to write correctly. (I'm discovering over and over again right now.)
Thanks for the props Fabian, but the engine isn't finished yet. Today I got a step closer though. (It now has a threaded communication protocol; on the console for now, so I can input moves manually while writing/testing the search.) I've also implementing the command line (using the CLAP library) so I can now do things such as --fen and --perft 6 from the command line, and it has a very simple text user interface (in its own thread, already) that accepts moves, so I can start writing the search. I'm glad I've been able to resume development.fabianVDW wrote: ↑Mon Sep 14, 2020 8:16 pm I would love to disprove this quote with an actual fast chess engine, but sadly FabChess is not, since I am not the best programmer. Have a look at Asymptote or Rustic though, they are both very fast. Most compiled Rust code compiles to similar speed as C/C++. Convince yourself with a quick google search about Rust performance vs C++ performance if you want. Fact is that you can port C code to Rust with unsafe and achieve the same performance pretty much guaranteed - this would include a lot of unsafe that one doesn't want though.
But you are right: the move generator and make_move/take_move are quite fast. Maybe people remember the optimization thread: http://talkchess.com/forum3/viewtopic.php?f=7&t=73577 Rustic's perft capability (without hash or counting tricks) is just as fast, or faster (depending on the position) than Weiss (written in C), and 20% faster than Minic (written in C++). I assume Minic could be made faster. Maybe Weiss and Minic have become faster; I haven't checked it since that thread.
The only unsafe code I've used the one you yourself suggested: not having the move list zero-initialized when creating it, because I'll be writing moves into them anyway.
===
To get back on topic with regard to SMP and the shared hash table... I'm sure that's going to be possible as well, somehow. I'll see when I get there. I have my own array-based hash table (which works already), but I'll also look into HashMap. The engine already uses a thread for its communication, and there will be a thread for the search as well. As Rust doesn't even allow global variables without going unsafe, the engine has none. Because the search will start out having its own thread (and probably its own copy of the board, which also contains the complete game state and history) from the beginning, it should be a problem to give it 4 threads and 4 boards (or 16 threads and 16 boards), and share the hash table somehow.
===
Oh, and with regard to speed vs. strength:
Booot 6.4 64-bit 4CPU 3297 (Pascal)
Combusken 1.3.0 64-bit 3052 (Go... 3x as slow as Rust, and a language I'd probably never use voluntarily)
CuckooChess 1.12 32-bit 2590 (Java (!) So even though it's not a top engine, it's still possible to write a strong engine in a quite slow language)
Delphil 3.2 64-bit 4CPU 2554 (Delphi... which should be as fast as C++. Borland wrote its C++ Builder GUI and cmpiler in Delphi... and Dephi was written in Delphi itself, which was written in Borland Pascal for Windows.)
In short, I think if you're using any language that compiles to machine code, it's no use mulling over the speed of the language if your engine hasn't at least reached 2500+ ELO on the CCRL-list. If you can write an almost 2600 ELO engine in Java, and a 3000+ ELO engine in Go, you can certainly do it in languages such as Pascal, Rust, Ada, or whatever language that has a current compiler.