TalkChess.com

I think what makes Leela as strong as Komodo is that Leela plays as good moves as Komodo.

I'm starting with full window until depth 3. Then I always use the score from the previous iteration as base, +/- 50 centipawns. When failing low/high, I open the lower/upper boundary to full, i.e. re-search with half-open window. That also handles pathologic corner cases: if I fail low, I search fr...

This is what I get with the ISO multiplier, not much better (still 8 PRNG calls for each byte): Just out of curiosity, can you please post the corresponding images for MS-rand and ISO-rand using the 8 LSBs from the RNG directly for each byte, i.e. with one RNG call per byte and so that the LSB of t...

Instead, a better way, is to make it re-entrant: rand(&seed). POSIX-2001 has rand_r for this, but it was declared as obsolete in POSIX-2008 - any idea why? There's no variation whatsoever, the modulo simply reduces the output to 15 bits I meant in actual usage. When you want a small variation, say ...

mar wrote: ↑

Sat Jan 12, 2019 7:46 pm

(aka "not bad")

Completely irrelevant for this application, and also bear in mind that it's mod'ed down to have the desired small variation. For image and audio processing, that would be another issue, of course, especially where you don't mod down.

This is no excuse for using a bad PRNG. It isn't "bad", it's at worst unsuited for certain applications. The one in question here simply doesn't belong to them. The issues that Chris was experiencing had nothing to do with the LGC, but with how the state is managed. I still don't follow how masking...

but Microsoft stdlib implements this as a dumb LCG (which is anything but pseudo-random) PLUS the return value is masked so that only 15 lsbits are kept => disastrous. Here is what ISO/IEC 9899 suggests as portable example implementation: static unsigned long int next = 1; int rand(void) // RAND_MA...

No, that cannot happen. Caching is fully transparent and coherent. OK, that's a point, but the load-modify-store cycle is interruptible, and memory ordering is not guaranteed across cores because the execution order can vary. Not sure whether this alone could already explain the observations. That ...

I'm still intrigued as to why rand() will always produce the same stream of random numbers in parallel versions of the same thread. rand() has a global variable behind it, the state of the random generator. If you do stuff on a global variable from one thread, another thread will not see the update...

chrisw wrote: ↑

Thu Jan 10, 2019 5:46 pm

What could possibly go wrong?

If one thread finishes its game early and modifies the engine weights while the other threads are still playing, they might not like that? Also, it looks strange with the "+=" in both cases, but probably more serious in the parallel case.