Chess programming on YouTube: NOBODY CARES?

[Harald]

After watching Bitboard CHESS ENGINE in C on youtube I have some comments.

Don't comment count++; with // increment count.

Write printf("%llu", bitboard);
and not printf("%llud", bitboard);
Otherwise you get an ugly d after the number because you yourself put it there.
%u already means unsigned int and %d means signed int. %ud means unsigned int number followed by d.

Try
#define pop_bit(bitboard, index) ((bitboard) &= ~(1ull << (index)))
using and_assignment (&=), bitwise_not (~) and the left_shift (<<) operators only
without an extra condition and branch. That looks like your other defines and has better performance.
And the makro parameters should really be in parentheses () to avoid ugly errors when you call it
with a whole expression.

I may have made some syntax errors here myself but I just typed without testing.

Harald

[maksimKorzh]

Thanks for your feedback!

btw, you've INTRIGUED me with RUST. Could you please give a brief overview of C vs RUST comparison according to your vision and WHY exactly you prefer rust oves C to create your engine apart from being unique and not following someone else's code? I would really appreciate if you share your opinion at this point.

There are several reasons.

- Rust is (almost) as safe as garbage collected languages, but with the speed of C. It achieves this by rigidly adhering to the principle that you can have only a single owner of some memory space. (This means that you can have many readers, or a single writer.)
- This makes sure that Rust is safe from memory leaks, race conditions, thread deadlocks, etc....
- (PS: This doesn't mean your program can never panic or crash. That's something different.)
- The language has a great static analyzer / code sanitizer built in. If you do something, anything, that is unsafe (like moving a struct in memory and then using it in the old location afterward), the compiler will not compile your code. (If you use rust-analyzer in your IDE, such as MS VSCode, the IDE will even tell you, even before you compile.)
- Rust has a package manager, called cargo. (Compare to Python's "pip", or Javascript "NPM"; or even Debian's "apt") No hassles installing dependencies.
- Rust has a toolchain manager, called "rustup", that can update, install, uninstall, and switch toolchains.
- It has a -single- build system through the package manager: "cargo build". No need to take several build systems into account.
- It has (at this point) a single compiler. No need to take 5 different compilers into account.
- This means that "cargo build" should run and create an executable on any supported operating system, with any supported toolchain.
- If you know C well, and can do memory management reliably there, your code is probably safe, and then Rust is quite easy to pick up. If you don't understand C and memory management that well and write unsafe/crashy programs in C, Rust is the horror of horrors, because you will against the compiler indefinitely.

For me, Rust feels like... C... but designed in 2015 instead of 1973.

(On the other hand, Go feels like... C... designed in 1995, in an effort to make C compatible with the internet... but that's another story.)

Still, after I finish my engine, I'll probably port it to C someday, just because I can. I like C. I just like Rust better nowadays

The engine is here, by the way, if you want to take a look at the code or download and compile it: https://github.com/mvanthoor/rustic

It is now at the stage where it successfully runs perft. Next will be the search, evaluation, and uci functionalities. Some of those have partly been written, but not yet merged due to development temporarily being on hold.

Thanks for such a detailed explanation to the point - now I see the reason WHY you love it so much. I guess memory management in rust is unique - I was intrigued so that started researching about it even more. I've also enjoyed walking through your engine code. Even though it's written in rust and uses magic bitboards still I had a feeling of a strong influence by VICE - just like in all of my sources))) But don't get insulted by this statement please - I'm saying this to show that I really really like your code. It's like when you catch the very gist of what needs to be done from someone else and then simply trying to implement it on your own. GOOD JOB. I'm tempted to see rustic in action one day!

[maksimKorzh]

I took a brief look into the videos, although did not had time right now watch even one of the entirely.
I can give more of a feedback later.

Overall i think its great that more chessprogramming series are appearing - the more the better, just because one can get more inspiration (and understandings) from watching similar stuff being implemented differently.

As for what I wanted to see:
I would love to see more implementations of a more advanced stuff than in the bluefever videos both in eval (like, maybe, king danger) and in search (LMR).

Hi No4b

Overall i think its great that more chessprogramming series are appearing - the more the better, just because one can get more inspiration (and understandings) from watching similar stuff being implemented differently.

I was thinking the same way when just started. Btw I've even made a video describing my dream (https://www.youtube.com/watch?v=jPSQeby ... =3&t=4310s) as "how nice it would be if lots of chess programming serieses appears on YouTube and then just make cross-channel videos where engines we're writing playing versus each other" - literally what happens now on this forum but bring this process to YouTube

[maksimKorzh]

After watching Bitboard CHESS ENGINE in C on youtube I have some comments.

Don't comment count++; with // increment count.

Write printf("%llu", bitboard);
and not printf("%llud", bitboard);
Otherwise you get an ugly d after the number because you yourself put it there.
%u already means unsigned int and %d means signed int. %ud means unsigned int number followed by d.

Try
#define pop_bit(bitboard, index) ((bitboard) &= ~(1ull << (index)))
using and_assignment (&=), bitwise_not (~) and the left_shift (<<) operators only
without an extra condition and branch. That looks like your other defines and has better performance.
And the makro parameters should really be in parentheses () to avoid ugly errors when you call it
with a whole expression.

I may have made some syntax errors here myself but I just typed without testing.

Harald

Hi Harald

I appreciate your critics a lot but could you plese alo post it below the video on youtube https://www.youtube.com/watch?v=o-ySJ2E ... Cs&index=2 so that not only community members but the rest of my subscribers could learn from it? Also my replies in that case would be visible to all the subscribers.

Don't comment count++; with // increment count.

Let me explain the reason for doing this. My other Youtube channel related to web scraping taught me to comment every single line of code even if it's trivial to understand. If I don't do that - lot's of commentaries appearing asking what that trivial line of code means, so I comment everything just to save time in future on answering those like comments. On the other hand most of my subscribers came from python background and "++" or "--" increments simply are not available in python - you need to do like x += 1.

Write printf("%llu", bitboard);
and not printf("%llud", bitboard);
Otherwise you get an ugly d after the number because you yourself put it there.
%u already means unsigned int and %d means signed int. %ud means unsigned int number followed by d.

This is done intentionally for the didactic purposes so that view always remember that the type of the variable displayed is UNSIGNED - "ugly d" flags that.

Try
#define pop_bit(bitboard, index) ((bitboard) &= ~(1ull << (index)))
using and_assignment (&=), bitwise_not (~) and the left_shift (<<) operators only
without an extra condition and branch.

I'm gonna change it when it comes to the perft test so that after this change perft would work faster. I want to show this case to demonstrate how one can look for optimizing stuff for better performance.

And the makro parameters should really be in parentheses () to avoid ugly errors when you call it
with a whole expression.

You're right, I'll check that out.

[mvanthoor]

Thanks for such a detailed explanation to the point - now I see the reason WHY you love it so much. I guess memory management in rust is unique - I was intrigued so that started researching about it even more. I've also enjoyed walking through your engine code. Even though it's written in rust and uses magic bitboards still I had a feeling of a strong influence by VICE - just like in all of my sources))) But don't get insulted by this statement please - I'm saying this to show that I really really like your code. It's like when you catch the very gist of what needs to be done from someone else and then simply trying to implement it on your own. GOOD JOB. I'm tempted to see rustic in action one day!

Thanks for the compliment

Why would I be insulted by you noticing that Rustic shows VICE influences? In the beginning, it actually started out as a port of VICE (at least, the general structure and some programming concepts), but written in Rust. Then I did some things different here and there, and then I (partly) switched to bitboards; then I completely switched to magic bitboards. Rustic is at this stage (move generation+perft) for 5 months already. In April, I noticed that Rustic was slower than some other engines when running perft. I started optimizing, and it turned into a friendly "optimization contest" between myself and Terje (author of Weiss):

http://talkchess.com/forum3/viewtopic.php?f=7&t=73577

I took some idea's from Weiss, and I'm quite sure Weiss might have had a few changes inspired by my code. In the end, both Rustic and Weiss ended up running at the same speed; less than 1 second apart on my system, for the same perft run. Both engines got faster in the process.

Fun Facts:
Weiss started out as a fork of VICE, and Terje then turned it into a a magic bitboard engine.
Rustic started out using VICE as a template, with code written in Rust, and I then turned the engine into a bitboard engine.
In the thread above, Weiss and Rustic swapped some optimization idea's.

So it's not surprising you're going to find VICE/Weiss influences in my engine; it's also no surprise to me that Rustic and Weiss have comparable speed.

Obviously, Weiss already plays strong chess for a long time. I hope that, in about a month, I can pick up development for Rustic again, and at some point, you'll see it in action. As soon as I get the chance, I'll also download and compile your engine Wukong as one of the sparring partners for the first few versions of Rustic

===

There's a lot in Rustic that doesn't need to be in the final engine, such as most of the "extra" folder. (It's there for debugging purposes; printing the board in different ways for example). The interfaces (console, uci, xboard) are going to be on a feature-basis; nobody but people who want to develop on the engine will use the console interface. That stuff will improve when I set up compilation using features. (That will also get rid of many of the "allow_dead_code" attributes.)

There are many comments that need to be updated.

Rustic already has quite a lot of error handling and checking; if the program is running and it gets into an unknown state from which it can't recover, I don't want it to crash; I want it to print (or later, maybe, log) a message and quit. Error handling in Rust has improved/made easier since some of the code was written. A lot of error handling can now be shortened by using the "?" operator.