📚 Open Source Technology DailyExploring the Infinite Possibilities of the Open Source World2025/11/17✨ Qt Abandons Direct Use of RDRAND/RDSEED to Improve Performance and Reduce ErrorsThe Qt toolkit is gradually phasing out direct reliance on the RDRAND and RDSEED instructions from the CPU for random number generation, opting instead for entropy sources provided by the operating system.A commit that has been merged into the Qt 6.11 development branch and is marked for backporting to the Qt 6.5/6.8/6.10 branches removes the direct calls to hardware instructions from QRandomGenerator. This decision stems from issues with the RDSEED instruction on the AMD Zen 5 architecture, which is currently being addressed through microcode updates. Additionally, the performance advantages of RDSEED/RDRAND over relying on the operating system have not met expectations.This week’s merged commit removes the direct use of hardware instructions in QRandomGenerator: “QRandomGenerator: Remove direct calls to hardware instructionsHardware random number generation instructions are not necessarily faster than the solutions provided by the operating system. Furthermore, the operating system can collect entropy from sources beyond the CPU. More importantly, this avoids Qt directly handling faulty hardware random number generators, delegating that responsibility to the operating system (which may disable CPUID bits leading to application load failures).”In the discussion thread regarding this issue, Linux random number generation expert and WireGuard developer Jason Donenfeld provided benchmark data for performance comparison: “RDRAND and RDSEED are slow! Benchmarking operations like filling buffers shows that even accounting for system calls, getrandom() and /dev/urandom are still faster than RDRAND and RDSEED.Here are the times taken to fill 1GB of data on my Tiger Lake laptop:getrandom vdso: 1.520942015 seconds getrandom system call: 2.323843614 seconds /dev/urandom: 2.629186218 seconds rdrand: 79.510470674 seconds rdseed: 242.396616879 secondsHere are the times for 25,000,000 calls of 4 bytes each—this data can be referenced if there are concerns about system call conversion:getrandom vdso: 0.371687883 seconds getrandom system call: 5.334084969 seconds /dev/urandom: 5.820504847 seconds rdrand: 15.399338418 seconds rdseed: 45.145797233 seconds”The performance differences are significant, and Qt now adopts a more robust solution that relies on the operating system.⚙️ NVIDIA Highlights Shortcomings in Wayland Screen Recording FeaturesIn addition to revealing the necessity for a unified DRM driver interface within the Linux kernel, NVIDIA’s Linux graphics driver team pointed out existing deficiencies in screen projection features under the Wayland protocol at the XDC2025 conference.
NVIDIA engineer Doğukan Korkmaztürk discussed the ongoing issues with screen projection technology in the Wayland environment from both the synthesizer and client perspectives. From the current state of explicit synchronization mechanisms to performance differences with the X11 protocol, these pain points still need to be addressed to provide a better screen projection/capture experience for Wayland users.For more in-depth information, viewers can check out NVIDIA’s presentation on Wayland screen projection technology through the recorded video and related PDF documents from the X.Org Developer Conference below. 🎯 GCC Patch Adds Support for Rust-Based Wild LinkerThe Wild linker, a high-speed linker written in Rust, has performance that can compete with mainstream linkers like Mold. A patch submitted this weekend adds support for the Wild linker to the GNU Compiler Collection (GCC).This patch integrates the compiler with the Wild linker via the GCC “–with-ld” option. Testing has shown that the Wild linker has successfully passed “the vast majority” of test cases.
Martin Liška wrote in the GCC mailing list: “After two years of active development, we plan to add linker options for the -fuse-ld flag in GCC. This linker has achieved significant performance improvements—matching the runtime speed of the Mold linker—and has matured to successfully link large complex projects like the Chromium browser and the Rust compiler (rustc).Currently, there are still a few test suites that have not passed, mainly involving symbol versioning and constructor/destructor ordering in edge cases, and the development team is actively working to resolve these issues. Support for GCC linker plugins has not yet been implemented. The current linker supports the Linux platforms for x86_64, aarch64, and riscv64gc architectures.”The patch is currently under code review, and based on initial feedback, an optimized revision is expected to be incorporated into the GCC compiler codebase soon.🌟 Open Source Changes the World, Let’s Drive Technological Progress Together 🚀