Discussion summary
Discussions highlight skepticism about modern C++ compilers' efficiency and complexity, with some advocating for developer control and understanding.
What the discussion says
- Some believe compilers underutilize CPU opcodes and are too complex.
- Others emphasize understanding hardware and code optimization over blind trust in compilers.
- Concerns about performance issues like debug build speed and build bloat are raised.
- Proposals for better exception handling and safer coding practices are discussed.
“Trust your compiler, but your code is only fast if you're lucky.”
“Modern compilers don't use a third of CPU opcodes, and their complexity is hard to grasp.”
Comments
Hacker News
I’ve seen some terrible horrid nonsense from them and even the best compilers don’t use a third of the opcodes our modern CPUs boast of. Nobody understands the big compilers any more either, they’re all too huge. And soon AI will be “improving” hem too.
You want to see a beautiful compiler? Look at Plan 9’s compiler suite. A man could understand and even build on that.
by Glandalf
> exceptions are slow
There are proposals to introduce better exceptions into C++. Like this: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p07....
But until it's not in the standard, people should use std::expceted instead.
by Panzerschrek
> Virtual vs static polymorphism
> std::visit over std::variant<A, B, C> is lowered to a switch over the active alternative.
> In this case, layout is probably doing more work than the dispatch mechanism itself.
Very likely because last time I checked visit lowers to a virtual call.
by mike_hock
Unremarked: debug build perf, perf-stability against minor edits, build-time bloat when heavily using std templates.
by mwkaufma
I trust the C++ committee to introduce new features in the most convoluted way possible, then spend the next 20 years trying to fix it, while adding even more syntax that makes my eyes hurt.
Case in point: templates. They are essentially a pure functional programming language embedded inside C++, expressed in a verbose syntax that barely resembles the rest of the language, and somehow makes even Java look concise.
It has been a slow-motion train wreck, with one questionable design decision after another. And a perfect example of why design by committee often leads to unnecessary complexity.
Trust the compiler - sure - but we can't change the whole program by using -ffast-math, unfortunately, so that particular one is out.
by kzrdude
Don't trust your compiler. Your code is only fast if you're lucky.
by chrka
Every time I see "use ranges and algorithms!" examples, I am baffled that apparently, I am supposed to find
inline double algorithm_call(std::span<double const> xs) noexcept {
return std::accumulate(
xs.begin(),
xs.end(),
0.0,
[](double acc, double volts) {
auto mv = calibrated_mv(volts);
auto err = residual(mv);
return weighted_square(err) + acc;
});
}
inline double raw_loop(std::span<double const> xs) noexcept {
double sum = 0.0;
for (double volts : xs) {
auto mv = calibrated_mv(volts);
auto err = residual(mv);
sum += weighted_square(err);
}
return sum;
}
by Joker_vD
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I’ve seen some terrible horrid nonsense from them and even the best compilers don’t use a third of the opcodes our modern CPUs boast of. Nobody understands the big compilers any more either, they’re all too huge. And soon AI will be “improving” hem too.
You want to see a beautiful compiler? Look at Plan 9’s compiler suite. A man could understand and even build on that.
by Glandalf - > exceptions are slow
There are proposals to introduce better exceptions into C++. Like this: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p07....
But until it's not in the standard, people should use std::expceted instead.
by Panzerschrek - > Virtual vs static polymorphism
> std::visit over std::variant<A, B, C> is lowered to a switch over the active alternative.
> In this case, layout is probably doing more work than the dispatch mechanism itself.
Very likely because last time I checked visit lowers to a virtual call.
by mike_hock - Unremarked: debug build perf, perf-stability against minor edits, build-time bloat when heavily using std templates.by mwkaufma
- I trust the C++ committee to introduce new features in the most convoluted way possible, then spend the next 20 years trying to fix it, while adding even more syntax that makes my eyes hurt.
Case in point: templates. They are essentially a pure functional programming language embedded inside C++, expressed in a verbose syntax that barely resembles the rest of the language, and somehow makes even Java look concise.
It has been a slow-motion train wreck, with one questionable design decision after another. And a perfect example of why design by committee often leads to unnecessary complexity.
- Trust the compiler - sure - but we can't change the whole program by using -ffast-math, unfortunately, so that particular one is out.by kzrdude
- Don't trust your compiler. Your code is only fast if you're lucky.by chrka
- Every time I see "use ranges and algorithms!" examples, I am baffled that apparently, I am supposed to find
more readable, concise, and easier on my eyes thaninline double algorithm_call(std::span<double const> xs) noexcept { return std::accumulate( xs.begin(), xs.end(), 0.0, [](double acc, double volts) { auto mv = calibrated_mv(volts); auto err = residual(mv); return weighted_square(err) + acc; }); }
Sure, there are some algorithms in <algorithms> that I'm rather not reimplement myself, but this one is not it.inline double raw_loop(std::span<double const> xs) noexcept { double sum = 0.0; for (double volts : xs) { auto mv = calibrated_mv(volts); auto err = residual(mv); sum += weighted_square(err); } return sum; }by Joker_vD