minipci1321

> so they do not allow the efficient use of modern CPUs otherwise than by using inline assembly or compiler intrinsics.

When one provides the full effect of the operation in the source code, a properly ported compiler backend should be able to spot the pattern and emit the instructions with matching non-C semantics. (Typically, saturated operations are a very low hanging fruit.)

That doesn't always work because the optimization passes targeting local optimum break these patterns while "optimizing" them, so they arrive to the instruction emitter unrecognizable. And these passes, living in the generic "good-for-all" area of the compiler core, cannot be made aware of what a particular target does or doesn't support. So ironically, such instructions appear more when the optimizations are disabled.

Intrinsics emit internal representation forms that optimization passes don't dare to touch.

> C is an abstraction of the machine, so thin it's nearly transparent.

-Werror might help with that

Thought it was about electric fence the malloc debug library, and was surprised to see so many comments. Turns out it is not mentioned at all in the comments, so correcting that :)

These days they do that using a vape, cover the PCB with a thick layer of vapor and see where it raises the fast after power-up. Youtube has videos.

Ooooh, that hit the nerve )).

The author, rather unfortunately, focuses primarily on the predation from the "generalized colleague", and that wasn't welcomed by many commenters, possibly because people in big-tech tend to be young and do need help, so have to ask for it.

But the way I see it, the predation is institutionalized in big companies.

-- The Intellectual Property department blocking the entire R&D of the entire product division for the whole day, to give a presentation on how to file a patent. Knowing full well that only a dozen of these people will every do, at best.

-- IT dept locking down everything, because, you know, there are risks and we don't want to take it. Doesn't matter if it slows down everyone else everywhere.

-- "Security" disabling access to slightest technical information, because, you know, someone could steal it. Just ask and you'll have access. (How does one asks for something one doesn't know exists?)

-- Purchasing that shortlists only some contracting shops and not accepting any others. Doesn't matter if the shortlisted one don't "carry" the competence (e.g., try EMC specialists).

All these people consider that as their achievements and are not shy about it when yearly appraisal comes. We all work as one team aren't we? And then comes the day of layoffs. One reason of it being that the R&D hasn't been performant enough. Guess what, we aren't so much of one team anymore.

Do you have siblings? How have they turned out?

> And even if you write inefficient code, CPUs are so fast that you won't notice it.

I think you are arguing for the right cause but with wrong arguments. In C language, not understanding in details what exactly the code does, can be just as disastrous as in Verilog. Internet examples abound.

"Potop" is also missing it seems? Didn't find "Katyn" either.

> Yeah they compile to the same machine code operations though.

Not always. Switch your example to AARCH64 and check out the BFI instruction.

> ... malloc() returns a pointer to sequentially-addressable bytes ...

malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.

> It's also hard to know anything other than C++, because of how taxing the language is; there's little energy left in you to learn something else.

When I think that in my industry, good mastership of C++ is, what, 30% of what it takes... Throw in real-time design principles and a few different kernels, several CPU architectures, unavoidable Linux and a one or two build systems (Yocto anyone?). And only then comes the real problem domain, communications protocol stacks or image-processing algos, or what have you.

I spent time typing in a setup with very dim ambient light (think of a photo room with dim red light). I still cannot touch-type, but after some time I discovered I can type in QWERTY on any keyboard layout.