C++ Core Guidelines
C++ Core Guidelines
Posted Apr 19, 2021 11:59 UTC (Mon) by excors (subscriber, #95769)In reply to: C++ Core Guidelines by Cyberax
Parent article: Rust in the Linux kernel (Google security blog)
I think it'd be more accurate to say there's no real reason to avoid them *by default*. Very occasionally you might write some code where it has a large enough impact on system performance that it's worth optimising, and it's important that the language lets you optimise those cases without too much pain.
E.g. https://coaxion.net/blog/2018/01/speeding-up-rgb-to-grays... has an example of an image processing loop where some bounds checks can be eliminated by simply adding asserts before the loop, and the rest can be eliminated by defining a new iterator type, giving a 2.2x speedup. And there's always the possibility of doing non-bounds-checked accesses in unsafe (/not-proved-safe-by-the-compiler) blocks, wrapped with some higher-level logic to guarantee it is still safe, as a last resort.
That seems no worse than optimising C/C++ code, where various aspects of the language (aliasing, lack of inlining across translation units, template code bloat, etc) tend to hurt performance across your whole codebase but the effect is so small that you can usually ignore it; and in the few cases where it really matters, you can tweak the code to encourage the compiler to optimise it better (restrict, inline function definitions in headers, type erasure, etc). A high-performance language isn't one where code automatically has high performance - it's one where most code has adequate performance, and then the language plus tools (profiler, compiler, etc) can work effectively in a feedback loop with the programmer to optimise the parts that need it, and it sounds like Rust does okay at that.
(Incidentally C++ has a more serious performance problem in how its "zero-overhead principle" is violated by exceptions and RTTI - that's reported as increasing code size by typically 15% and sometimes ~40% (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p...), even in code that never throws an exception. That's something you can't fix locally after identifying bottlenecks; you have to disable exceptions globally, and reject libraries that rely on exceptions (like STL and much of the rest of the C++ standard library). So in code where you're worried about every byte, standard C++ is not a good solution. C++-without-exceptions is okay but sacrifices some of the advertised benefits of modern C++. I don't know if Rust has any similarly expensive misfeature.)