Qualcomm has open-sourced ELD, a new linker designed specifically for embedded systems. ELD aims to be faster and more memory-efficient than traditional linkers like GNU ld, especially beneficial for resource-constrained devices. It achieves this through features like parallel processing, demand paging, and a simplified design focusing on common embedded use cases. ELD supports ELF and is designed for integration with existing embedded workflows, offering potential improvements in link times and memory usage during development.
The author dramatically improved the debug build speed of their C++ project, achieving up to 100x faster execution. The primary culprit was excessive logging, specifically the use of a logging library with a slow formatting implementation, exacerbated by unnecessary string formatting even when logs weren't being written. By switching to a faster logging library (spdlog), deferring string formatting until after log level checks, and optimizing other minor inefficiencies, they brought their debug build performance to a usable level, allowing for significantly faster iteration times during development.
Commenters on Hacker News largely praised the author's approach to optimizing debug builds, emphasizing the significant impact build times have on developer productivity. Several highlighted the importance of the described techniques, like using link-time optimization (LTO) and profile-guided optimization (PGO) even in debug builds, challenging the common trade-off between debuggability and speed. Some shared similar experiences and alternative optimization strategies, such as using pre-compiled headers (PCH) and unity builds, or employing tools like ccache. A few also pointed out potential downsides, like increased memory usage with LTO, and the need to balance optimization with the ability to effectively debug. The overall sentiment was that the author's detailed breakdown offered valuable insights and practical solutions for a common developer pain point.
Wild is a new, fast linker for Linux designed for significantly faster linking than traditional linkers like ld. It leverages parallelization and a novel approach to symbol resolution, claiming to be up to 4x faster for large projects like Firefox and Chromium. Wild aims to be drop-in compatible with existing workflows, requiring no changes to source code or build systems. It also offers advanced features like incremental linking and link-time optimization, further enhancing development speed. While still under development, Wild shows promise as a powerful tool to accelerate the build process for complex C++ projects.
HN commenters generally praised Wild's speed and innovative approach to linking. Several expressed excitement about its potential to significantly improve build times, particularly for large C++ projects. Some questioned its compatibility and maturity, noting it's still early in development. A few users shared their experiences testing Wild, reporting positive results but also mentioning some limitations and areas for improvement, like debugging support and handling of complex linking scenarios. There was also discussion about the technical details behind Wild's performance gains, including its use of parallelization and caching. A few commenters drew comparisons to other linkers like mold and lld, discussing their relative strengths and weaknesses.
Summary of Comments ( 0 )
https://news.ycombinator.com/item?id=43644966
Hacker News users generally expressed cautious optimism about ELD, Qualcomm's new embedded linker. Several commenters questioned its practical advantages over existing linkers like ld, particularly regarding its performance and debugging capabilities. Some wondered about its long-term support given Qualcomm's history with open-source projects. Others pointed out potential benefits like improved memory usage and build times, especially for complex embedded systems. The lack of clear benchmarks comparing ELD to established solutions was a recurring concern. A few users expressed interest in trying ELD for their projects, while others remained skeptical, preferring to wait for more evidence of its real-world effectiveness. The discussion also touched on the challenges of embedded development and the need for better tooling.
The Hacker News post titled "ELD: A new open-source embedded linker tool for embedded systems" has generated several comments discussing various aspects of the new linker and its potential impact.
One commenter expressed skepticism about the genuine openness of the project, pointing out Qualcomm's history with open-source projects and suggesting they might abandon it if it doesn't directly benefit their business interests. They questioned the long-term viability of relying on a tool from a vendor with such a track record.
Another commenter focused on the technical merits, praising the linker's claimed performance improvements and the ability to perform link-time garbage collection, which can significantly reduce the size of embedded binaries. They expressed excitement about potentially integrating it into their own workflow.
Several commenters discussed the challenges and complexities of embedded systems development, highlighting the fragmented tooling landscape and the difficulty of achieving optimal performance and code size. They saw ELD as a potential solution to some of these challenges, particularly for developers working with resource-constrained devices.
One commenter, identifying as an embedded developer, shared their experience with existing linkers and expressed frustration with their limitations, especially when dealing with complex projects. They welcomed the introduction of a new linker, hoping it would offer improved performance and debugging capabilities.
The discussion also touched upon the importance of build systems and the integration of ELD with existing tools. One commenter inquired about CMake integration, emphasizing the need for seamless integration with popular build systems for wider adoption.
A few commenters mentioned other linkers like Mold and LLD, comparing their features and performance with ELD. They speculated on whether ELD could compete with these established tools and what advantages it might offer.
Finally, some commenters expressed interest in learning more about the technical details of ELD, particularly its internal workings and optimization strategies. They hoped for more in-depth documentation and examples to facilitate experimentation and evaluation.