TalkChess.com

Why should an object-oriented PHP program be significantly slower than a classical PHP program? Most importantly, because you are generating a ton of objects that need to be garbage collected, which takes significant amounts of time. You are also introducing an abstraction penalty that PHP's rather...

Why should an object-oriented PHP program be significantly slower than a classical PHP program? Most importantly, because you are generating a ton of objects that need to be garbage collected, which takes significant amounts of time. You are also introducing an abstraction penalty that PHP's rather...

You have three problems:

1. You are using PHP.
2. Your board structure is based on text (e.g. “a1”) instead of primitive values (e.g. 0, 0).
3. You are doing this object-oriented.

Fix those three, and your code will be much, much faster.

Well, it did manage to have a much smaller branching factor with such an impressive play. But you don't know whether that was from the NN evaluation or due to MCTS. How well would AZ have played with Stockfish's evaluation and AZ's MCTS? Nobody knows. You also have to consider the very real possibi...

So with the dust settling from the generation, where are we? Stockfish master has full support; is there a version of Fathom with 7-man support yet?

You can also pick the best move out of the transposition hash, recursively. However, you do risk that it has been overwritten (and if so, the PV gets cut short).

Question for Sesse. When you said that your set passes tbcheck, did you do the full check wherein the hash sum is recomputed and compared to the stored value, or did you do the quick check? The quick check only proves that the metadata block containing the sum transferred correctly. It won't catch ...

All my files match that checksum file. Success!

(This is after I replaced the faulty KRRNvKRR.rtbz earlier today, of course.)

rsync is nice, but very CPU-heavy, so it doesn't scale well for busy servers at all. There are variations like zsync that try to remedy some of this by not requiring an active server that checksums lots of data, but I don't think they ever caught on (and zsync requires extra storage space). I couldn...

I've checked file sizes against Lichess. For four of the tables, my file sizes match their mirror. For KRRNvKRR.rtbz and KRBBNvKQ.rtbz, we disagree. Both of these (as well as KQBNvKQN.rtbw, where I match with Lichess but disagree with the posted SHA256 sums) were among the files that were initially ...