4 ms·

what are the faster / more effective alternatives?

ReleaseCandidat 2y ago
Depends what you need and how/where you implement it. For example, if it should pass BigCrush https://en.m.wikipedia.org/wiki/TestU01 https://en.m.wikipedia.org/wiki/TestU01 or PractRand https://github.com/MartyMacGyver/PractRand https://github.com/MartyMacGyver/PractRand Just a page with SmallCrush and BigCrush examples, not to be taken as an endorsement for their PRNG: https://www.pcg-random.org/statistical-tests.html https://www.pcg-random.org/statistical-tests.html
DistractionRect 2y ago
If you don't need cryptography secure rngs, PCG is pretty cool. It's pretty straightforward and builds off basic primitives, but the results has some neat qualities/features if you find you need them. E.g. People often find that they don't want pure randomness, but rather want some kind of uniformity//equidistribution over some period, which implies state (I.e. Shuffling a music playlist).
olliej 2y ago
That depends on what your use case is, but because we're considering MT we can assume there's nothing remotely related to cryptography so there are plenty of options. In practice people seem to have adopted the various xorshift style generators - certainly IIRC from back when I worked on JSC (and so also paid attention to other JS engines) we all adopted xorshift128+ for all unsafe RNGs (Math.random, but also internal entropy used in mitigations and similar), though the general family is "xorshift"[1]. There are a few others, and for me this was a decade+ ago so maybe there have been improvements since - xorshift does fail some of the diehard tests but so few as to be acceptable for the overwhelming majority of cases. There days I believe that the PCG RNG[2] family might be a better choice? They claim to be both faster and statistically better, but I'm guessing not by enough for JS engines to care (RNG performance was a 10-20 years ago as the increasing perf of the rest of the engines meant the cost of Math.random() in benchmarks started being a problem lol - JSC at the time used two calls to the system arc4random(), which required call overhead and the system implementation required locking, but it was cryptographically secure! at least on Mac+iOS where it is not actually RC4). Very very big NB: If you're wanting random numbers to feed into _any_ part of _anything_ cryptographic (keys, nonces, padding, ...) use the OS provided secure RNG, do not try and do it yourself - not just because of "it's real easy to get it wrong", but because the system APIs automatically leverage hardware RNGs automatically when possible (the semi-mythical "true random"). [1] https://en.wikipedia.org/wiki/Xorshift https://en.wikipedia.org/wiki/Xorshift [2] https://www.pcg-random.org/index.html https://www.pcg-random.org/index.html

Depends what you need and how/where you implement it. For example, if it should pass BigCrush https://en.m.wikipedia.org/wiki/TestU01 https://en.m.wikipedia.org/wiki/TestU01 or PractRand https://github.com/MartyMacGyver/PractRand https://github.com/MartyMacGyver/PractRand Just a page with SmallCrush and BigCrush examples, not to be taken as an endorsement for their PRNG: https://www.pcg-random.org/statistical-tests.html https://www.pcg-random.org/statistical-tests.html

DistractionRect 2y ago

If you don't need cryptography secure rngs, PCG is pretty cool. It's pretty straightforward and builds off basic primitives, but the results has some neat qualities/features if you find you need them. E.g. People often find that they don't want pure randomness, but rather want some kind of uniformity//equidistribution over some period, which implies state (I.e. Shuffling a music playlist).

olliej 2y ago

That depends on what your use case is, but because we're considering MT we can assume there's nothing remotely related to cryptography so there are plenty of options. In practice people seem to have adopted the various xorshift style generators - certainly IIRC from back when I worked on JSC (and so also paid attention to other JS engines) we all adopted xorshift128+ for all unsafe RNGs (Math.random, but also internal entropy used in mitigations and similar), though the general family is "xorshift"[1]. There are a few others, and for me this was a decade+ ago so maybe there have been improvements since - xorshift does fail some of the diehard tests but so few as to be acceptable for the overwhelming majority of cases. There days I believe that the PCG RNG[2] family might be a better choice? They claim to be both faster and statistically better, but I'm guessing not by enough for JS engines to care (RNG performance was a 10-20 years ago as the increasing perf of the rest of the engines meant the cost of Math.random() in benchmarks started being a problem lol - JSC at the time used two calls to the system arc4random(), which required call overhead and the system implementation required locking, but it was cryptographically secure! at least on Mac+iOS where it is not actually RC4). Very very big NB: If you're wanting random numbers to feed into _any_ part of _anything_ cryptographic (keys, nonces, padding, ...) use the OS provided secure RNG, do not try and do it yourself - not just because of "it's real easy to get it wrong", but because the system APIs automatically leverage hardware RNGs automatically when possible (the semi-mythical "true random"). [1] https://en.wikipedia.org/wiki/Xorshift https://en.wikipedia.org/wiki/Xorshift [2] https://www.pcg-random.org/index.html https://www.pcg-random.org/index.html