Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trust your compiler: Modern C++

categorica.io

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Trust your compiler: Modern C++

#11

Post by xyzzyz »

rzzzt wrote: post #10
Joker_vD wrote: post #9

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 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:…

The first form is easier to send to 32 beefy cores or 1024 small CPUs or a Beowulf cluster or a GPU or people sitting in a room.

Both of them have to be completely rewritten to make use of multiprocessing, so what exactly is the advantage?

Re: Trust your compiler: Modern C++

#13

Post by pjmlp »

sylware wrote: post #12
pjmlp wrote: post #7

Earlier quoted context omitted.

Quite funny comment on the vibe coding age.

And yours is in no way related to mine...

Complaining about C++ compilers given the amount of increasing vibe code garbage and related hallucinations, certainly is.

Re: Trust your compiler: Modern C++

#14

Post by bluGill »

Glandalf wrote: post #4

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.

How does the resulting code compared to what a modern compiler gives me. I don't maintain compilers for a living, I maintain other code, which is ultimately longer and more complex than a C++ compiler. And so if my compiler, by becoming a little bit more complex, can make my resulting code a lot simpler because I don't have to do inline optimizations of various sorts, that makes my life much easier and is a good trade-off since there's a lot more programs in the world than there are compilers.

Re: Trust your compiler: Modern C++

#15

Post by sylware »

pjmlp wrote: post #13
sylware wrote: post #12

Earlier quoted context omitted.

And yours is in no way related to mine...

Complaining about C++ compilers given the amount of increasing vibe code garbage and related hallucinations, certainly is.

Oh!

You meant it is even worse nowadays with vibe coding! My bad.

Re: Trust your compiler: Modern C++

#16

Post by rzzzt »

xyzzyz wrote: post #11
rzzzt wrote: post #10

Earlier quoted context omitted.

The first form is easier to send to 32 beefy cores or 1024 small CPUs or a Beowulf cluster or a GPU or people sitting in a room.

Both of them have to be completely rewritten to make use of multiprocessing, so what exactly is the advantage?

The first one too? Isn't that the map-reduce fork-join golden example of multiprocessing?

Re: Trust your compiler: Modern C++

#17

Post by galangalalgol »

pjmlp wrote: post #7
sylware wrote: post #2

[flagged]

Quite funny comment on the vibe coding age.

Quit poking at the openbsd maintainers. Jokes aside (I mean maybe they are one I don't know), it is at least a coherent opinion that inherently complex but critical software infrastructure would ideally be kept as simple and understandable as possible with all the correctness and verification apparatus staying out of the way so you can see what is there to be backdoored. I use rust primarily and like using it, but there are well over a hundred crates just in the front end, and llvm isn't simple. I do miss the days when I could know what each line did.

Re: Trust your compiler: Modern C++

#18

Post by Someone »

Glandalf wrote: post #4

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.

> even the best compilers don’t use a third of the opcodes our modern CPUs boast of

That’s not necessarily an indication of the weakness of compilers. It also could be an indication that hardware designers could leave out instructions.

X86, in particular, will have lots of them for backwards compatibility reasons (extreme example: the old 80-bit x87 FP stack)

There also are instructions that are expected to never get used by ‘normal’ compilers but cannot be removed because they only make sense in lower-level code such as those for switching between protection levels, implementing compare-and-swap, etc.

Re: Trust your compiler: Modern C++

#19

Post by cwzwarich »

rzzzt wrote: post #16
xyzzyz wrote: post #11

Earlier quoted context omitted.

Both of them have to be completely rewritten to make use of multiprocessing, so what exactly is the advantage?

The first one too? Isn't that the map-reduce fork-join golden example of multiprocessing?

`std::accumulate` is defined to have sequential semantics, so the analysis required to make it parallel is probably not that different than starting from the loop version. I guess you could have an alternate `accumulate_associative` that uses the same interface but assumes the reduction is associative and has unspecified evaluation order?

Re: Trust your compiler: Modern C++

#20

Post by mpyne »

xyzzyz wrote: post #11
rzzzt wrote: post #10

Earlier quoted context omitted.

The first form is easier to send to 32 beefy cores or 1024 small CPUs or a Beowulf cluster or a GPU or people sitting in a room.

Both of them have to be completely rewritten to make use of multiprocessing, so what exactly is the advantage?

The original example isn't really using ranges except to emulate C++98 iterator work though.

The actual equivalent might be something closer to:

    inline double algorithm_call(std::span xs) noexcept {
        return std::accumulate(
            xs, 0.0,
            [](double acc, double volts) {
                auto mv  = calibrated_mv(volts);
                auto err = residual(mv);
                return weighted_square(err) + acc;
        });
    }
(that is, without the boilerplate .begin and .end).

Even that is enough to make ranges useful in my mind, but in a codebase which has started to integrate some functional programming techniques, there are also applications for things like views and transforms.

This can make it easier to reason about iteration pipelines in ways you might already be familiar with from POSIX.

That all said, it's C++ so sometimes the error messages get a lot more 'interesting' than they would have with STL-style iterators, especially when mixed with constexpr expressions as you might do with std::format or fmt libs.

Post reply on HN