The 5.7 kernel is out [LWN.net]

The 5.7 kernel is out

Posted Jun 1, 2020 17:32 UTC (Mon) by mathstuf (subscriber, #69389)
In reply to: The 5.7 kernel is out by quotemstr
Parent article: The 5.7 kernel is out

The problem is keeping people to using only the "kernel-sensible" parts of C++. There are quite a number of goobers around the stdlib (vector<bool>, unordered_set perf pessimizations, etc.) and the language itself (operator overloading, ADL, etc.) that is unlikely to be allowed beyond RAII and some better typing behaviors.

to post comments

The 5.7 kernel is out

Posted Jun 1, 2020 20:10 UTC (Mon) by Wol (subscriber, #4433) [Link] (13 responses)

Yup. Simply put, C++ is a high-level language. It is not designed for resource-constrained environments. Modern programmers are not trained for resource-constrained environments.

And resource-constrained is not fixed by throwing level 4 ram at an "insufficient cache in the processor" problem ... :-)

Cheers,
Wol

The 5.7 kernel is out

Posted Jun 1, 2020 20:24 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (4 responses)

There are folks working on standalone contexts for standard C++, but it is in progress and probably won't land everything Linux would likely want/need until C++26. It mostly works by stripping down stdlib features though. You're still stuck with bad language behaviors.

The 5.7 kernel is out

Posted Jun 1, 2020 20:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Some of them DID get fixed, like vector<bool>.

The 5.7 kernel is out

Posted Jun 2, 2020 1:49 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

Do you have a paper number for that?

The 5.7 kernel is out

Posted Jun 2, 2020 2:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I think P1957R2 but I can swear I've seen another one about implicit bool casts.

The 5.7 kernel is out

Posted Jun 2, 2020 2:44 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Those papers do nothing about vector<bool>'s problems:

- auto& item = boolvec[3]; is busted as you get a proxy object instead of a real boolean
- does not work with parallel algorithms (the bits all write to the same byte and collide there)
- T* data = vec.data(); doesn't work in generic code when passed a vector<bool>
- I'm sure there are others

It's just a bad design the standard allows (it's not even required!) that won't get fixed due to ABI guarantees stdlib implementers are basically bound by from the ecosystem. Sure, the standard can tell them to do something, but they can also say "sorry, no can do" (they effectively have a veto on such things because of this).

The paper you refer to is basically about making T* -> bool a warning due to bugs and weird typesystem holes you fall into with the implicit cast floating about your generic code.

The 5.7 kernel is out

Posted Jun 1, 2020 20:37 UTC (Mon) by quotemstr (subscriber, #45331) [Link] (5 responses)

> Yup. Simply put, C++ is a high-level language. It is not designed for resource-constrained environments.

I have to completely disagree with this perspective. C++ lets you control the machine as precisely as C does. There's nothing in the language, nothing at all, that prevents your writing low-level and efficient code. C++ isn't Python. Is your position just that people writing C++ can't avoid the temptation to use inefficient patterns? That's a social problem, not a technical one.

The 5.7 kernel is out

Posted Jun 2, 2020 0:24 UTC (Tue) by Wol (subscriber, #4433) [Link] (3 responses)

There's nothing in the language that prevents you - correct.

But how many programmers actually have a clue about which features are efficient, and which are not? The other massive problem with the question "which features are efficient", is probably that the answer is "it depends on the compiler".

If you *need* a program to be efficient, giving programmers a compiler that can be inefficient may be a social problem, but stopping those programmers from using those features is probably an intractable problem ... I don't want a Ryzen 7 to be the minimum recommended processor for running linux ...

Cheers,
Wol

The 5.7 kernel is out

Posted Jun 2, 2020 0:48 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (2 responses)

The criticisms you mention all apply to C too. I don't see C++ being special here --- to write good code, you have to know what you're doing, and if you're a bozo, you're going to wreck things in either C or C++. That's why we do code review.

The 5.7 kernel is out

Posted Jun 2, 2020 8:21 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

And how much - even kernel code - is code-reviewed? And of those reviewers, how many have the *experience* to know what is good or bad?

You only need some badly written and poorly written driver to start evicting L1 cache and the whole system suffers.

I think it's a case of "C: if it looks efficient it probably is. C++: If it looks efficient, who knows what the hell is going on behind the scenes ..."

Now if you apply C++ discipline to C code that's a whole 'nother ball game!

My expertise is databases. And I like Pick because there is a consistent model right through from hardware to application (at least, there is if the programmer knows what they're doing! :-) Just like C, there's plenty of rope to hang yourself.

Relational - C&D to be precise - is a whole pile of poo. Firstly, there's the logical inconsistency within the rules themselves. Then there's the model second-guessing you to try and protect you from yourself. Then there's the implementation - severely hamstrung by the model itself if it tries to implement it faithfully. Pascal, SQL, C++, ... great for novices, and quite good languages, but expensive in wasted computer power as it tries to protect you from yourself.

Cheers,
Wol

The 5.7 kernel is out

Posted Jun 2, 2020 12:21 UTC (Tue) by adobriyan (guest, #30858) [Link]

Inefficiency of the language can be trivially demonstrated by absence of multiple return values.

Given

int f(const char *str, int *val);

int val;
int rv = f(str, &val);
if (rv < 0)
return rv;
[use "val"]

C ABI and single return value forces to allocate data on a stack and a write.
Now top of stack is optimized so it doesn't matter for performance, but the act of writing to [rsp+] has second order effects.
Stack protector sees that function modifies memory and starts placing canaries, bloating code and issuing reads and adding
mandatory branch for stack smashing.

Could this be solved in C? Yes, by using 2-value structure which fully fits into 2x8-byte registers.
C ABI even has provision for this by referring to RDX as a second return value.
Which of course nobody uses because there is no syntax for destructuring.

The 5.7 kernel is out

Posted Jun 2, 2020 2:04 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Is `-fno-exceptions` really part of C++ or just a mechanism that Linux would have to disable? I guess Linux would have to avoid `new` anyways as it does `malloc`, so maybe it wouldn't be *that* far off. But without `std::optional` and some nice wrapper around `std::variant` to act as Haskell's `Either` or Rust's `Result`, the algorithms aren't that useful. I don't know. At that point, you may as well just adopt some Golang `defer`-like C extension rather than try and strip C++ down since that's mostly what would be wanted from what's left anyways. Sure templates for data structures would be nice, but if what you get is just a bit more rigor than what the macros are already doing, unit tests solve most of that problem too (which you'd want *anyways*).

The 5.7 kernel is out

Posted Jun 1, 2020 20:44 UTC (Mon) by adobriyan (guest, #30858) [Link] (1 responses)

The only noticeable resource constraint is small stack with a warning for every even smaller stack frame.

The 5.7 kernel is out

Posted Jun 2, 2020 0:27 UTC (Tue) by Wol (subscriber, #4433) [Link]

And L1/2/3 cache, and and and ...

Cheers,
Wol

The 5.7 kernel is out

Posted Jun 1, 2020 20:38 UTC (Mon) by adobriyan (guest, #30858) [Link]

> vector<bool>, unordered_set perf pessimizations

This should be fixed by disabling standard library.

> the language itself (operator overloading, ADL, etc.) that is unlikely to be allowed beyond RAII and some better typing behaviors.

This is more than enough. Just check out the horror show called latest incarnation of min()/max() macros.

Kernel was reinventing C++ for quite some time already:
TMP in kfifo.h, macroified bsearch and interval trees (include/linux/interval_tree_generic.h),
function overloading -- grep for __builtin_choose_expr()),
destructors and unique_ptr<>-- devm_alloc_*().

The real losses are compilation slowdown, mangled names and a _lot_ of casts from void * (at least initially).