tczajka

As alright2565 already mentioned, sticking rand() in there doesn't add any benefit over a key + counter.

Without rand() it would be something like SHA3-CTR -- it's not standardized which is why I would prefer ChaCha20, but it has been proposed for standardization and yes it's probably a fine algorithm.

Isn't it also similarly conceivable that if you write a predictable PRNG sequence such the outputs of Mersenne Twister you could also potentially extract patterns? Mersenne Twister is essentially as predictable as a short cycle.

If a predictable PRNG is sufficient for wiping disks, why do we care that the data is random at all? How about writing 0, 1, 2, ..., 255, 0, 1, 2, ... to consecutive bytes? Or -- generate 1 kb of good quality random data, and write the same 1 Kb repeatedly? It's not clear to me what we're trying to achieve in this scenario.

I can just about believe that this kind of scenario might be a very rare exception where the performance difference is relevant and you might want to do something else.

Still, color me skeptical.

"In simple enough scenes"? OK perhaps, but we don't want to only run ray tracing for very simple scenes. Simple scenes are those cases where you probably don't need much calculation, so does it really matter that 5-10% of that simple calculation is RNG? It's the complicated computation-heavy scenes that matter!

Also, one would have to see the code to judge this. For instance, maybe that code was wasting random bits a lot?

It's not true that I cherry-picked a slow PRNG for my 7 GB/s number. In fact I selected the second-fastest PRNG on that page (because it's popular)! The fastest one is 8 GB/s. PCG32 is 3 GB/s.

Your 4000x factor speed up for a linear-congruential generator is just a completely false number.

Yes I did pick ChaCha20 for its speed -- it's designed for speed!

"A few hundred FPU instructions" in your Monte Carlo is not comparable to generating a number with ChaCha20. If you need a few hundred FPU instructions per number, you will be running a lot slower than 2 GB/s. ChaCha only requires a few cycles per byte.

I agree that you can optimize out the side-channel free part for non-crypto-purposes. That's a good thing! I recommend doing that.