Zobrist keys

[benvining]

Most descriptions of Zobrist hashing I've found say that the keys are randomly generated at program startup. Why generate them each time the program runs, why not just use some static constants? Is there a downside to using hard-coded keys?

[Joost Buijs]

Using static or compile-time constants for the Zobrist keys is fine (besides making the executable somewhat larger on disk).

[hgm]

Note that reading them from disk as part of the executable's initialized data is probably much slower than having the computer calculate them.

[Steve Maughan]

I use the Polyglot Zobrist keys in my engine. This has the added advantage of making it really easy for your engine to use Polyglot opening books. You can find the keys here:

http://hgm.nubati.net/book_format.html

— Steve

[JacquesRW]

Most descriptions of Zobrist hashing I've found say that the keys are randomly generated at program startup. Why generate them each time the program runs, why not just use some static constants? Is there a downside to using hard-coded keys?

No engine should (and I am not aware of a single decent engine that does) generate different zobrist keys at each startup, it should use a fixed seed and fixed prng. This is because you want the ability to make a change to some code, and verify that it is nonfunctional in search (on a single thread) which would be immediately impossible if each time you run the engine you have different zobrist values. An example of where this is valuable is when you perform large refactors.

Whether you hard code these values or (re)generate them at startup is just preference.

Edit:
Also, pretty much every strong engine implements `bench`(see here https://github.com/AndyGrant/OpenBench/ ... quirements) as a checksum for distributed testing via OpenBench as linked or Fishtest in the case of Stockfish, that directly relies on engines being deterministic on a single thread across multiple runs.

[benvining]

Note that reading them from disk as part of the executable's initialized data is probably much slower than having the computer calculate them.

I'm not reading the keys from a file, I've just got them defined as `constexpr` variables in my C++ code

[syzygy]

Note that reading them from disk as part of the executable's initialized data is probably much slower than having the computer calculate them.

But if you run the engine more than once, the executable will usually be cached in RAM, and calculating the Zobrist keys will be a huge slowdown (measured in attoseconds).

[hgm]

Note that reading them from disk as part of the executable's initialized data is probably much slower than having the computer calculate them.

I'm not reading the keys from a file, I've just got them defined as `constexpr` variables in my C++ code

That means they are in the .exe file, which the OS must read in order to execute it.

[hgm]

Note that reading them from disk as part of the executable's initialized data is probably much slower than having the computer calculate them.

But if you run the engine more than once, the executable will usually be cached in RAM, and calculating the Zobrist keys will be a huge slowdown (measured in attoseconds).

Well, even reading the keys from RAM is probably slower than recalculating them. And in a test with fast TC you would probably not reload the engine for every game. (And you would calculate the keys only on loading, not for every new game.)

[syzygy]

Note that reading them from disk as part of the executable's initialized data is probably much slower than having the computer calculate them.

But if you run the engine more than once, the executable will usually be cached in RAM, and calculating the Zobrist keys will be a huge slowdown (measured in attoseconds).

Well, even reading the keys from RAM is probably slower than recalculating them. And in a test with fast TC you would probably not reload the engine for every game. (And you would calculate the keys only on loading, not for every new game.)

Your engines don't have an array of Zobrist keys in RAM?