hi Robert, We are using xoroshiro128 and not moved to the next state of art. We did see a lot of low values as put in my last message. -Parag
On Wed, Apr 10, 2024 at 9:37 AM Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Apr 10, 2024 at 12:02 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > As I said to Parag, I see exactly no reason to believe that that's a > > problem, unless it happens *a lot*, like hundreds of times in a row. > > If it does, that's an RNG problem not s_lock's fault. Now, I'm not > > going to say that xoroshiro can't potentially do that, because I've > > not studied it. But if it is likely to do that, I'd think we'd > > have noticed the nonrandomness in other ways. > > The blog post to which Parag linked includes this histogram as an > example of a low-Hamming-weight situation: > > Reps | Value > -----+-------- > 84 | 0x00 > 10 | 0x2d > 6 | 0xa0 > 6 | 0x68 > 6 | 0x40 > 6 | 0x02 > 5 | 0x0b > 4 | 0x05 > 4 | 0x01 > 3 | 0xe1 > 3 | 0x5a > 3 | 0x41 > 3 | 0x20 > 3 | 0x16 > > That's certainly a lot more zeroes than you'd like to see in 192 bytes > of output, but it's not hundreds in a row either. > > Also, the blog post says "On the one hand, from a practical > perspective, having vastly, vastly more close repeats than it should > isn't likely to be an issue that users will ever detect in practice. > Xoshiro256's large state space means it is too big to fail any > statistical tests that look for close repeats." So your theory that we > have a bug elsewhere in the code seems like it might be the real > answer. > > -- > Robert Haas > EDB: http://www.enterprisedb.com >
