11 comments

[ 3.7 ms ] story [ 38.9 ms ] thread
Trust the compiler - sure - but we can't change the whole program by using -ffast-math, unfortunately, so that particular one is out.
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.

> 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.

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;
        });
    }
more readable, concise, and easier on my eyes than

    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;
    }
Sure, there are some algorithms in <algorithms> that I'm rather not reimplement myself, but this one is not it.
Unremarked: debug build perf, perf-stability against minor edits, build-time bloat when heavily using std templates.
Don't trust your compiler. Your code is only fast if you're lucky.

https://tiki.li/blog/lucky_code.html

that's a nice example. on my M4, i measured 3.4s vs. 0.42s. honestly surprised there's ~10x improvement to be found.

as you've pointed out, you've literally micro-optimised this - isn't this what you'd expect? :)

But what is the resulting assembly? I would assume completely different!
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.