"Less Slow C++" offers practical advice for improving C++ build and execution speed. It covers techniques ranging from precompiled headers and unity builds (combining source files) to link-time optimization (LTO) and profile-guided optimization (PGO). It also explores build system optimizations like using Ninja and parallelizing builds, and coding practices that minimize recompilation such as avoiding unnecessary header inclusions and using forward declarations. Finally, the guide touches upon utilizing tools like compiler caches (ccache) and build analysis utilities to pinpoint bottlenecks and further accelerate the development process. The focus is on readily applicable methods that can significantly improve C++ project turnaround times.
For the first time in two decades, PassMark's CPU benchmark data reveals a year-over-year decline in average CPU performance. While single-threaded performance continued to climb slightly, multi-threaded performance dropped significantly, leading to the overall decrease. This is attributed to a shift in the market away from high-core-count CPUs aimed at enthusiasts and servers, towards more mainstream and power-efficient processors, often with fewer cores. Additionally, while new architectures are being introduced, they haven't yet achieved widespread adoption to offset this trend.
Hacker News users discussed potential reasons for the reported drop in average CPU performance. Some attributed it to a shift in market focus from single-threaded performance to multi-core designs, impacting PassMark's scoring methodology. Others pointed to the slowdown of Moore's Law and the increasing difficulty of achieving significant performance gains. Several commenters questioned the validity of PassMark as a reliable benchmark, suggesting it doesn't accurately reflect real-world performance or the specific needs of various workloads. A few also mentioned the impact of the pandemic and supply chain issues on CPU development and release schedules. Finally, some users expressed skepticism about the significance of the drop, noting that performance improvements have plateaued in recent years.
Summary of Comments ( 18 )
https://news.ycombinator.com/item?id=43727743
Hacker News users discussed the practicality and potential benefits of the "less_slow.cpp" guidelines. Some questioned the emphasis on micro-optimizations, arguing that focusing on algorithmic efficiency and proper data structures is generally more impactful. Others pointed out that the advice seemed tailored for very specific scenarios, like competitive programming or high-frequency trading, where every ounce of performance matters. A few commenters appreciated the compilation of optimization techniques, finding them valuable for niche situations, while some expressed concern that blindly applying these suggestions could lead to less readable and maintainable code. Several users also debated the validity of certain recommendations, like avoiding virtual functions or minimizing branching, citing potential trade-offs with code design and flexibility.
The Hacker News post titled "Less Slow C++" (https://news.ycombinator.com/item?id=43727743) sparked a discussion with a moderate number of comments, largely focusing on the practicality and nuances of the advice offered in the linked GitHub repository.
Several commenters appreciated the author's effort to collect and present performance optimization tips. One user highlighted the value in consolidating such information, especially for those newer to C++, acknowledging that while experienced developers might be familiar with many of the tips, having them readily available in one place is beneficial.
However, a recurring theme in the comments was the caution against premature optimization. Multiple users emphasized that focusing on code clarity and correctness should precede optimization efforts. They argued that optimizing without proper profiling and understanding of actual bottlenecks can be counterproductive, leading to more complex code without significant performance gains. One commenter even suggested the title should be "Faster C++," as "Less Slow" implies a focus on fixing slowness rather than writing efficient code from the start.
Some commenters delved into specific points from the GitHub document. There was discussion around the use of
std::vector
versusstd::array
, pointing out thatstd::array
is often preferable for small, fixed-size collections due to its avoidance of heap allocation. Another discussion centered on the advice to avoid exceptions, with some agreeing on their performance overhead, especially when thrown frequently, while others argued that exceptions are crucial for error handling and shouldn't be dismissed solely for performance reasons.The topic of inlining also garnered attention. While the GitHub document recommends strategic use of inlining, some commenters elaborated on the compiler's role in inlining decisions. They highlighted that modern compilers are often better at determining which functions to inline, making explicit inlining less necessary and sometimes even detrimental.
Finally, a few commenters shared their own experiences and preferred optimization techniques, adding further depth to the conversation. One mentioned the importance of considering data locality and cache efficiency for performance-critical code.
Overall, the comments section provides a balanced perspective on C++ optimization. While acknowledging the usefulness of the compiled tips, the discussion emphasizes the importance of careful profiling, prioritizing code readability, and understanding the trade-offs involved in different optimization strategies. It serves as a reminder that blindly applying performance tweaks without proper consideration can often do more harm than good.