Qt Moves Away From Direct RDRAND/RDSEED Usage For Better Performance & Less Bugs
([Qt] 4 Hours Ago
Qt No RDRAND/RDSEED)
- Reference: 0001592270
- News link: https://www.phoronix.com/news/Qt-Moves-Off-RDRAND-RDSEED
- Source link:
The Qt toolkit is moving away from directly relying on the CPU's RDRAND and RDSEED instructions for random number generation and to instead rely on the OS-supplied entropy.
In a commit merged to the Qt 6.11 development branch and marked for back-porting to Qt 6.5 / 6.8 / 6.10 branches is removing the direct usage of hardware instructions by QRandomGenerator. This follows [1]AMD Zen 5 being affected by an RDSEED issue that is now [2]being addressed with updated microcode . In addition, the performance benefits of RDSEED/RDRAND aren't panning out compared to relying on the operating system.
[3]This commit merged this week is what dropped the direct use of hardware instructions by QRandomGenerator:
"QRandomGenerator: remove direct use of HW instructions
The HWRNG instructions are not necessarily faster than what we can get from the OS. Moreover, the OS is able to collect entropy from sources other than the CPU itself. More importantly, this removes the need for Qt to deal with broken HWRNG, passing the buck to the OS (which may disable the CPUID bit, causing the application to fail to load).
[ChangeLog][QtCore][QRandomGenerator] This class no longer directly uses a hardware random number generator on x86 systems, even if one is available. Instead, it will always use a generator provided by the OS (so performance will be OS-specific), though there should be no meaningful difference in the quality of the samples generated."
Within [4]the discussion thread over the issue Linux RNG expert and WireGuard developer Jason Donenfeld provided some benchmark numbers on the performance difference:
"RDRAND and RDSEED are slow! Benchmark filling a buffer or whatever, and you'll find that even with the syscall, getrandom() and /dev/urandom are still faster than RDRAND and RDSEED.
Here are timings on my tiger lake laptop to fill a gigabyte:
getrandom vdso: 1.520942015 seconds
getrandom syscall: 2.323843614 seconds
/dev/urandom: 2.629186218 seconds
rdrand: 79.510470674 seconds
rdseed: 242.396616879 seconds
And here are timings to make 25000000 calls for 4 bytes each -- in case you don't believe me about syscall transitions:
getrandom vdso 0.371687883 seconds
getrandom syscall: 5.334084969 seconds
/dev/urandom: 5.820504847 seconds
rdrand: 15.399338418 seconds
rdseed: 45.145797233 seconds"
Quite a difference and now Qt is relying on the more robust approach of relying on the OS.
[1] https://www.phoronix.com/news/AMD-SB-7055-RDSEED-Zen-5
[2] https://www.phoronix.com/news/AMD-Zen-5-More-RDSEED-ucode
[3] https://github.com/qt/qtbase/commit/5a685653b8903dbfd722b0c299651b65e3632ac5
[4] https://lore.kernel.org/all/CAHmME9o+cVsBzkVN9Gnhos+4hH7Y7N6Sfq9C5G=bkkz=jzRUUA@mail.gmail.com/T/
In a commit merged to the Qt 6.11 development branch and marked for back-porting to Qt 6.5 / 6.8 / 6.10 branches is removing the direct usage of hardware instructions by QRandomGenerator. This follows [1]AMD Zen 5 being affected by an RDSEED issue that is now [2]being addressed with updated microcode . In addition, the performance benefits of RDSEED/RDRAND aren't panning out compared to relying on the operating system.
[3]This commit merged this week is what dropped the direct use of hardware instructions by QRandomGenerator:
"QRandomGenerator: remove direct use of HW instructions
The HWRNG instructions are not necessarily faster than what we can get from the OS. Moreover, the OS is able to collect entropy from sources other than the CPU itself. More importantly, this removes the need for Qt to deal with broken HWRNG, passing the buck to the OS (which may disable the CPUID bit, causing the application to fail to load).
[ChangeLog][QtCore][QRandomGenerator] This class no longer directly uses a hardware random number generator on x86 systems, even if one is available. Instead, it will always use a generator provided by the OS (so performance will be OS-specific), though there should be no meaningful difference in the quality of the samples generated."
Within [4]the discussion thread over the issue Linux RNG expert and WireGuard developer Jason Donenfeld provided some benchmark numbers on the performance difference:
"RDRAND and RDSEED are slow! Benchmark filling a buffer or whatever, and you'll find that even with the syscall, getrandom() and /dev/urandom are still faster than RDRAND and RDSEED.
Here are timings on my tiger lake laptop to fill a gigabyte:
getrandom vdso: 1.520942015 seconds
getrandom syscall: 2.323843614 seconds
/dev/urandom: 2.629186218 seconds
rdrand: 79.510470674 seconds
rdseed: 242.396616879 seconds
And here are timings to make 25000000 calls for 4 bytes each -- in case you don't believe me about syscall transitions:
getrandom vdso 0.371687883 seconds
getrandom syscall: 5.334084969 seconds
/dev/urandom: 5.820504847 seconds
rdrand: 15.399338418 seconds
rdseed: 45.145797233 seconds"
Quite a difference and now Qt is relying on the more robust approach of relying on the OS.
[1] https://www.phoronix.com/news/AMD-SB-7055-RDSEED-Zen-5
[2] https://www.phoronix.com/news/AMD-Zen-5-More-RDSEED-ucode
[3] https://github.com/qt/qtbase/commit/5a685653b8903dbfd722b0c299651b65e3632ac5
[4] https://lore.kernel.org/all/CAHmME9o+cVsBzkVN9Gnhos+4hH7Y7N6Sfq9C5G=bkkz=jzRUUA@mail.gmail.com/T/