GitHub (MIT): https://github.com/danielcota/biski64

Highlights:

* ~0.42 ns/value (GCC 11.4, -O3 -march=native), 92% faster than xoroshiro128++.

* Easily passes PractRand (32TB), exceptional BigCrush results (running BigCrush 100 times against established PRNGs).

* Guaranteed 2^64 period - through the use of a 64-bit Weyl sequence.

* Parallel streams, robust reduced state size tests.

* Core requires only stdint.h.

Details on the 100x BigCrush tests (including reference PRNG results), parallel streams and reduced state size tests can be found in the Github README).

Seeking feedback on design, use cases, or further testing.

Comments URL: https://news.ycombinator.com/item?id=44097398

Points: 3

# Comments: 0

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.

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

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

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.

GitHub (MIT): https://github.com/danielcota/LoopMix128

Highlights:

* ~0.37 ns/value (GCC 11.4, -O3 -march=native), 98% faster than xoroshiro128++ and PCG64.

* Passes TestU01 BigCrush & PractRand (32TB).

* Guaranteed 2^128 period.

* Proven injective (192-bit state) via Z3 SMT solver; allows parallel streams.

* Core requires only stdint.h.

Seeking feedback on design, use cases, or further testing.

Comments URL: https://news.ycombinator.com/item?id=43949134

Points: 76

# Comments: 34

I'd like to share DualMix128, a pseudo-random number generator I developed. It's written in C and achieves very high speed while maintaining strong statistical properties for non-cryptographic use.

GitHub (MIT License): https://github.com/the-othernet/DualMix128

Key points:

* *Fast:* Benchmarked at ~0.36 ns per 64-bit generation on GCC 11.4 (-O3 -march=native). This was over 2x faster than `xoroshiro128++` (~0.74 ns) and competitive with `wyrand` (~0.36 ns) in the same tests. (Benchmark code/results in repo).

* *Robust:* Passes the full TestU01 BigCrush suite and PractRand up to 32TB with no anomalies reported. (Test harnesses/logs in repo).

* *Simple Algorithm:* Uses a 128-bit state (two `uint64_t`) with simple mixing based on addition, XOR, rotation, and a final multiplication by the golden ratio constant.

* *C Implementation:* Minimal dependencies (`stdint.h` for core), straightforward C code.

This came out of exploring simple constructions for efficient PRNGs that still hold up under heavy statistical testing.

Curious to hear feedback on the design, performance, potential applications, or any weaknesses you might spot. Thanks!

Comments URL: https://news.ycombinator.com/item?id=43893388

Points: 5

# Comments: 1