Add SHISHUA?

[SUPERCILEX]

See: https://espadrine.github.io/blog/posts/shishua-the-fastest-prng-in-the-world.html

That looks cool, but I don't know anything about rngs so I'm sure there's a reason against adding it. If not, would a Rust port be welcome?

[vks]

Thanks for the heads up! It seems to be a non-CSPRNG that uses SIMD and a large state size to beat the competition. This approach seems sound, because non of the existing non-CSPRNGs are designed with SIMD in mind. However, this also makes it not a good fit for Rand at the moment:

• It cannot be used for StdRng, because it is not cryptographically secure.
• It cannot be used for SmallRng, because it is very large (15 times StdRng, 65 times SmallRng) and complex.

Its niche would be for applications were maximum throughput is required and the size of the state can be large. Rand does currently not provide a generator optimized for these constraints. We could add SHISHUA as FastRng behind a feature flag, but I'm not convinced that this niche is important enough to add it to Rand instead of providing it as a separate crate.

There is already a Rust implementation: https://github.com/dbartussek/shishua_rs

[TheIronBorn]

Being SIMD there's some alleviation of the state-size problem because it would use different registers (at least on x86) which probably aren't as busy as the scalar registers. Though 5 registers and at least 4 temporary ones is still fairly large.

This also only matters if your only state-size concern is register pressure

[SUPERCILEX]

Oh yeah, I definitely don't think it should be an easy default without more rigorous statistical analysis. I was thinking it could be added as a rand_shishua crate like the xor rand crates. As for the Rust implementation, it barley gets 2GB/s so I wouldn't consider it a usable implementation.

[dhardy]

If there's significant interest in using this PRNG, go ahead and write your implementation... we could accept it as an addition here, but considering it is not directly of use to us I think it would only make sense to do so when someone will commit to maintaining the crate. Otherwise, go ahead and publish your own crate.

My personal feeling is that there isn't a lot of point to having the fastest non-crytographic PRNG. The speed of the PRNG itself is often not going to be a significant limitation unless all you're doing is writing a block of random data, and I have no idea why you would want to do that (with a non-cryptographic PRNG).

[SUPERCILEX]

Sounds good, I'll add it to my backlog. 😁

The speed of the PRNG itself is often not going to be a significant limitation unless all you're doing is writing a block of random data, and I have no idea why you would want to do that (with a non-cryptographic PRNG).

Ha! I have that exact use case lol: I'm writing random bytes to a randomly generated set of files. With PCIe 5 and 6 just around the corner, being able to generate anything less than 10GB/s is going to be a bummer.

[vks]

I would also be open to a rand_shishua crate. Getting a fast implementation will probably be a lot of work. 😅