[tomatsu]

https://github.com/mohae/bench-rng

csprng: 909 ns/Op

Xorhift128+: 2 ns/Op

Xorhift128+ is what all major JS engines use for Math.random().

I don't think it's a good idea if you use a CSPRNG if there isn't any reason for that. Especially if you need a lot of random numbers. E.g. a game might drop some additional frames here and there and your particle effects won't look any better and your AI won't behave any smarter either.

Not to use PRNGs ever is bad advice.

[bhickey]

> 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.

[FabHK]

Three comments:

> 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...

[bhickey]

> Monte Carlo simulation is the obvious exception

It depends. :) Even then very few realistic simulations are going to be RNG bound. Even fewer of those are going to care about the difference between Xoroshiro and AES-CTR (with AESNI).

A common failure mode I've seen is programmers picking Mersenne Twister and then assuming initialization is cheap.

> suffer a very low quality least significant bit

IIRC, the LSB behaves like a LFSR.

> it's surprisingly hard to get researchers in PRNG to give clear, unequivocal recommendations for users

There are about five PRNG researchers in the world and few (none?) of them are doing it full time. L'Ecuyer, the biggest name since Marsaglia died, seems to be dealing with PRNGs mostly as a means to doing operations research.

(Side note: Pierre L'Ecuyer is very likely the strongest over-50 cyclist in Quebec.)

[Veedrac]

You should be talking ~50ns for a good CSPRNG, which is almost never going to be the overhead.