The main problem of this construction is that it needs uint128_t, which C compilers for 32-bit platforms generally don’t have (before C23), so the RNG there is not slow but doesn’t even compile.
True. If you need a 64-bit RNG on a 32-bit machine, you can grab the 128-bit compatibility code from the PCG distribution or from NumPy. But for most purposes, pcg32 is totally fine, though I wonder if 2 x pcg32 is slower or faster on a 32-bit system than 1 x pcg64 if you need a random double precision floating point number.
Can you share any personal experiences or use cases when working with PCG64 DXSM, and does it offer noticeable advantages over other random number generators in practice?
To be honest, I have not needed to use it yet! After all, I only learned about it last week.
A couple of years ago I was doing some randomized testing and benchmarking with parts of the NLnet Labs NSD authoritative DNS server. It already has a random number generator, but it is designed for safety rather than performance so it usually uses the getrandom() syscall wrapper which is really slow. I swapped in pcg32 and my code ran much much faster.
BIND already has a decent small fast PRNG, for all the reasons I listed in the “background” section of my article. I changed it to use Lemire’s nearly-divisionless algorithm for unbiased bounded random numbers, but it doesn’t need any more maintenance right now.
(There is a way to get a random double using bithacks, precise knowledge of IEEE 754 formats, and violating C’s strict aliasing rules. Clever and cute, but it turns out to waste a bit of the mantissa, and modern CPUs are so fast at FP conversion and multiplication that the bit hacking is not faster in practice. In comparison, the simple multiplication is incredibly lucid. A beautiful line of code that was an enormous pleasure to learn about.)
The main problem of this construction is that it needs
uint128_t, which C compilers for 32-bit platforms generally don’t have (before C23), so the RNG there is not slow but doesn’t even compile.True. If you need a 64-bit RNG on a 32-bit machine, you can grab the 128-bit compatibility code from the PCG distribution or from NumPy. But for most purposes,
pcg32is totally fine, though I wonder if 2 xpcg32is slower or faster on a 32-bit system than 1 xpcg64if you need a random double precision floating point number.Can you share any personal experiences or use cases when working with PCG64 DXSM, and does it offer noticeable advantages over other random number generators in practice?
To be honest, I have not needed to use it yet! After all, I only learned about it last week.
A couple of years ago I was doing some randomized testing and benchmarking with parts of the NLnet Labs NSD authoritative DNS server. It already has a random number generator, but it is designed for safety rather than performance so it usually uses the
getrandom()syscall wrapper which is really slow. I swapped inpcg32and my code ran much much faster.BIND already has a decent small fast PRNG, for all the reasons I listed in the “background” section of my article. I changed it to use Lemire’s nearly-divisionless algorithm for unbiased bounded random numbers, but it doesn’t need any more maintenance right now.
Actually, a place where pcg64 dxsm would have made sense was for generating numbers according to a collection of statistical distributions, which I used when testing my
hg64histogram. The conversion from a randomuint32_tto a randomdoublein that code is really stupid. Much better would be to use a 64-bit RNG (to avoid wasting bits in the mantissa) and use multiplication to scale it to the correct range, not division. Like this: https://dotat.at/cgi/git/pcg-dxsm.git/blob/HEAD:/pcg64_dxsm.h(There is a way to get a random double using bithacks, precise knowledge of IEEE 754 formats, and violating C’s strict aliasing rules. Clever and cute, but it turns out to waste a bit of the mantissa, and modern CPUs are so fast at FP conversion and multiplication that the bit hacking is not faster in practice. In comparison, the simple multiplication is incredibly lucid. A beautiful line of code that was an enormous pleasure to learn about.)