4 ms·
According to Intel’s manual (although I don’t think it still applies): “Under heavy load, with multiple cores executing RDRAND in parallel, it is possible, tho
by ryacko 7y ago
According to Intel’s manual (although I don’t think it still applies):
“Under heavy load, with multiple cores executing RDRAND in parallel, it is possible, though unlikely, for the demand of random numbers by software processes/threads to exceed the rate at which the random number generator hardware can supply them.”
I don’t think it would be that hard to find something to route over multiple cores. If certain operations were unrolled and buffered, it would be overall more efficient.
- zamadatix 7y agoDepends on the elements you're talking about. RDRAND takes no input other than "I need a number" and produces output by feeding the constant output of a hardware RNG to the AES components of a particular core. Pretty much every other piece of the CPU needs to consume inputs and produce outputs without race conditions or cache coherency. This is where it becomes difficult to connect and schedule and is the reason AMD ends up with 16*16 MB of L3 cache instead of 1x256MB, trying to pump coherency instead of just output over an interconnect comes with an ENORMOUS penalty.
- ryacko 7y agoI wasn’t aware that RDRAND was implemented in microcode on the same core, I thought it was implemented as a coprocessor with some microcode checks for quality. Avoiding speculation on the output of high latency instructions seems prudent.