在 2023/7/24 12:49, Xi Ruoyao 写道:
On Mon, 2023-07-24 at 04:01 +0000, tiantao (H) wrote:
Thanks for the reply.
Using FEAT_RNG can be a very big performance boost
Hmm, I think this may be untrue. I've attempted using inline asm to invoke x86 rdrand instead of rand() for some competitive programming code, but the result is *slower*.
Thanks for the reply, I tested the performance on an ARM64 server very well, especially in multithreaded scenarios
The spec of this instruction [1] even says:
If the instruction cannot return a genuine random number in a reasonable period of time, PSTATE.NZCV is set to 0b0100 and the data value returned is 0.So at least for some implementations the "reasonable period of time" may be long. And we need to check PSTATE.NZCV and loop (or fallback to a software-based PRNG), then it will be even slower...
Generally a hardware RNG is for cryptography use, so the design of HWRNG is often focused on security, instead of speed. Maybe it is fast on *your* implementation, and it may never fail on *your* implementation, but other implementations may do things differently.
any suggestions for applying the FEAT_RNG feature to glibc?
The suggestion is "don't do that".
A feature is not necessarily useful for Glibc only because it exists.