| > csprng: 909 ns/Op OK, go ships a lousy csprng. I've been asking the team to replace it but no one has gotten around to it. AES-CTR, for example, is competitive with Xorshift and Xoroshiro. > Xorshift128+ is what all major JS engines use for Math.random(). Only because two years ago Yang Guo noticed that MWC1616 was garbage. Up until that point engines were shipping a broken generator because someone had been clever. This failure mode happens again and again. java.util.Random, for example. > I don't think it's a good idea if you use a CSPRNG if there isn't any reason for that Using insecure random sources opens you up to all sorts of attacks that CSPRNGs insulate you to. > Especially if you need a lot of random numbers Over the past year I profiled a huge number of binaries. I found exactly one where fetching random numbers was over 1% of CPU consumption. > your particle effects won't look any better Your particle effects are probably running in a shader. That's a whole other ball game. |
> I found exactly one where fetching random numbers was over 1% of CPU consumption.
Again, Monte Carlo simulation is the obvious exception, and it is a huge, important field and big consumer of random numbers. Stochastic algorithms (see Sebastian Thrun's Probabilistic Robotics) might be another example.
However, one big problem is that many benchmarks basically benchmark the PRN generation, and so incentivise vendors to default to fast PRNG. And I agree with you, the default should be a CSPRNG.
Lastly, on a side note, I seem to recall that some generators from Vigna's Xoroshiro family suffer a very low quality least significant bit. Not sure whether Xorshift128+ is among them.
EDIT to add more:
BTW, it's surprisingly hard to get researchers in PRNG to give clear, unequivocal recommendations for users. They'll often resort to some version of "it depends" (or plug their own).
Lastly, let me plug my related stackoverflow answer:
https://stackoverflow.com/questions/4720822/best-pseudo-rand...