Radiance codebase change

[ppipelin]

Hello,
I have been reworking my engine in another language, from C++ to Zig. It is listed in some databases and on the CCRL blitz.
Since at the moment the new version of the engine has the same features and roughly the same level as the previous, is it okay if I archive the old one and rename the new repository to the old one?

Version-wise it will start a new major (4.0)

Something like:
OLD : https://github.com/ppipelin/radiance --> https://github.com/ppipelin/radiancearchived
New : https://github.com/ppipelin/radiancerecharged --> https://github.com/ppipelin/radiance

[Brunetti]

is it okay if I archive the old one and rename the new repository to the old one?

Hi,
obviously, you can do whatever you want in your repositories.
You may choose to be kind/helpful and write this in the README of both, and also communicate it here as you did

Alex

[ppipelin]

Hi,
I updated both projects with new releases!
Last C++ minor : https://github.com/ppipelin/radiance_ar ... es/tag/3.5
Newer version in Zig : https://github.com/ppipelin/radiance/releases/tag/4.0

TLDR: Nice improvements and chess 960 support!

Feel free to test and contribute!

[Steve Maughan]

Cool!

I'm also thinking of rewriting Maverick in Zig. I've poked around in Zig and it seems like the perfect language to use to write a chess engine. Having done a rewrite, what are your thoughts? Did the engine's speed increase (if so, how much)? Was it super easy to cross compile?

— Steve

[fkarger]

Why is Zig a good candidate for chess programming?

[Steve Maughan]

Why is Zig a good candidate for chess programming?

A few reasons.

1. You're in control of all memory allocations (which means you can optimize)
2. The executables are some of the fastest. In some benchmarks zig beats "c" by >10%
3. You get cross-compilation out of the box
4. It seems like an interesting language to learn

— Steve

[fkarger]

So it does not clearly 'beat' C/C++ but is an interesting alternative?

I briefly looked at the syntax and thought there could be less boilerplate code.
Maybe it is also easier to debug?

[ppipelin]

I talked a bit about zig benefits on zig forum : https://ziggit.dev/t/chess-engine-in-zig/9671. In short, migration was fun and really enjoyable, most of the zig features makes sense. It feels good not to suffer from the std or the test and build systems. (+ cross compiling is so nice when deploying)

As for speed comparision, I had a great increase during move generation but had differences in the code.
--> In my c++ version, every pseudo legal move had to be tested to be legal separately, whereas now I have attacked squares and pins taken into account during move generation via bitboards.

With perft on startpos I went from 2.3Mnps to 7.5Mnps. And in both cases I use precomputed dictionnaries instead of magic number hashing.

I encourage you to read the top zig chess engine : Avalanche https://github.com/SnowballSH/Avalanche/. However it is on zig 0.10.X and some functions could be written in a simpler way now.

I also feel that the community is helping which is nice.

A drawback would be that zig does not have a major version yet, some great efforts are put each version to come closer to a release but they might/will be breaking changes by 1.0.0. From the changelogs, it is close to be free from LLVM which would be a great step forward.

[fkarger]

Thank you for the deep explanation!

[ppipelin]

Once used to zig, the language is really readable I'd say. And there is no hidden control flow.

Zig compiler can compile C with some default optimizations (like LTO), it can import C code and I think gives better tracebacks and handling of undefined behaviours, but don't know much about this.