5 ms·

> to make all the constants known at compile time, everything has to be written in a const function. This means: No allocations [...] No for loops These consta

by evmar 3y ago

> to make all the constants known at compile time, everything has to be written in a const function. This means: No allocations [...] No for loops These constants are relatively unchanging relative to the rest of your program. Why not write a code generator (without the above weird restrictions) to compute them once and save the result?

harerazer 3y ago
I was also confused by this. I was wondering if he was going to use #embed or something of the like.
- thehappypm 3y ago
  I’m not a Rustacean, but it seems much easier to pre compute, store in a file, then load the file at startup
  - JonChesterfield 3y ago
    write rust syntax into that file and feed it into the build to delete misc fears about costs or failure modes of loading files
  - wongarsu 3y ago
    In rust you can also pre-compute (optionally at build time in the build.rs) and load the file at compile time. Either using std::include_str to get a string with the file content (and then parse at startup without needing the separate file) or you generate a valid rust file and use std::include and still get all the potential compiler optimizations from knowing the values of these constants. But honestly, the const code for generating the values doesn't look thaaat bad. It's bad by rust standards, but not far from what equivalent C code would look like.
JonChesterfield 3y ago
It is better to write obscure compile time code in the metalanguage than to write a separate program which generates the same result, even if the separate program would generate something than can then be spliced in at compile time anyway. Well, "better". "Industry practice" might be more accurate. Also "necessary" if your build system is garbage and/or your team is frighted of code generators but not meta-programming.
- vlovich123 3y ago
  You can write the compile time generation as a separate Rust program. It has the added advantage that you only need to run it if the program itself changes and otherwise check in the generated code. The main advantage is that you don’t have to generate Rust code as a string. You’re just generating Rust data structures in Rust and that is convenient. Not sure if there’s any tricks for that.
mcdonje 3y ago
My first thought would be to store the magic numbers in either a db or a config file.
claytonwramsey 3y ago
I thought about that. The big benefit of using `const` here is that I can lean on my existing abstractions (e.g. Bitboard, Square, Direction) which I was already using in the engine. In order to use those abstractions in `build.rs`, I would have to split out those base data structures into a separate crate. I found empirically that splitting out code into a separate crate resulted in an observable Elo reduction (though this was about a year ago, so I forget how much), even with `lto=true`.

by evmar 3y ago

harerazer 3y ago

I was also confused by this. I was wondering if he was going to use #embed or something of the like.

thehappypm 3y ago
I’m not a Rustacean, but it seems much easier to pre compute, store in a file, then load the file at startup
- JonChesterfield 3y ago
  write rust syntax into that file and feed it into the build to delete misc fears about costs or failure modes of loading files
- wongarsu 3y ago
  In rust you can also pre-compute (optionally at build time in the build.rs) and load the file at compile time. Either using std::include_str to get a string with the file content (and then parse at startup without needing the separate file) or you generate a valid rust file and use std::include and still get all the potential compiler optimizations from knowing the values of these constants. But honestly, the const code for generating the values doesn't look thaaat bad. It's bad by rust standards, but not far from what equivalent C code would look like.

JonChesterfield 3y ago

It is better to write obscure compile time code in the metalanguage than to write a separate program which generates the same result, even if the separate program would generate something than can then be spliced in at compile time anyway. Well, "better". "Industry practice" might be more accurate. Also "necessary" if your build system is garbage and/or your team is frighted of code generators but not meta-programming.

vlovich123 3y ago
You can write the compile time generation as a separate Rust program. It has the added advantage that you only need to run it if the program itself changes and otherwise check in the generated code. The main advantage is that you don’t have to generate Rust code as a string. You’re just generating Rust data structures in Rust and that is convenient. Not sure if there’s any tricks for that.

mcdonje 3y ago

My first thought would be to store the magic numbers in either a db or a config file.

claytonwramsey 3y ago

I thought about that. The big benefit of using `const` here is that I can lean on my existing abstractions (e.g. Bitboard, Square, Direction) which I was already using in the engine. In order to use those abstractions in `build.rs`, I would have to split out those base data structures into a separate crate. I found empirically that splitting out code into a separate crate resulted in an observable Elo reduction (though this was about a year ago, so I forget how much), even with `lto=true`.