the_othernet

NOTE: I found a counterexample using Z3 Solver in which fast_loop maps to itself (0x5050a1e1d03b6432). A new version will be released with fast_loop and slow_loop as simple Weyl Sequences.

What a great set of feedback. Thank you! I'll look at it as an acton item list.

And you are so right about being just one month in. Every time I think I'm starting to understand what's going on here, I realize the maze just keeps getting deeper.

Using only 32bit fast_loop and mix (for 64bits of state) passes PractRand with 64bit output up to 256GB with only one unusual. That's about a 100 bit LCG equivalent? I did have to alter the output to be "(GR * mix) + fast_loop" and change the rotation constants to be 12 and 5.

Added the Romu variants to benchmark.c. Here are the current results:

LoopMix128 ns/call: 0.380 ns

xoroshiro128++ ns/call: 0.757 ns

wyrand ns/call: 0.379 ns

PCG64 ns/call: 0.757 ns

RomuQuad ns/call: 0.575 ns

RomuDuoJr ns/call: 0.416 ns

Using only 32bit fast_loop and mix (for 64bits of state) passes PractRand up to 256GB with only one unusual. That's about a 90 bit state LCG equivalent?

I did have to alter the output to be "(GR * mix) + fast_loop" and change the rotation constants to be 12 and 5.

Super useful link. Thank you!

I'll have to re-optimize the rotations for the smaller state size, but I will do it and report here.

I wasn't able to analyze the cyclic behavior of the mix directly, but for the purpose of minimal period only fast_loop and slow_loop are used (as a 128bit counter).

Hello! Awesome work on your hashing by the way!

When iterating I first tried to make fast_loop as random as possible by trying all possible rotational values and then having each option tested in PractRand 1000 times from 256M to 8GB. There was a wide range of performance by rotation. 47 was the best (for the GR constant) and resulted in the most tests being passed. The goal was a stronger than normal core for the PRNG that could feed actively into mix.

I found the multiplication to be necessary for passing PractRand and BigCrush with the state mixing as posted.

I had a variant which assigned mix as rotate(mix,constant) + (mix^fast_mix). That would pass cleanly with mix directly outputted (with no multiplication) - but I couldn’t get Z3 prover to show injectivity so I decided to go with the posted route.

I have an offline poker app, and a user asked me what the algorithm was to generate the random numbers. That was a month ago. :)

Just added to benchmark.c in the Github. Performance is comparable to xoroshiro128++.

I just added PGC64 to benchmark.c in the Github. PCG64 speed looks to be about the same as xoroshiro128++.