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

C++: "model of the hardware" vs. "model of the compiler" (2018)

ithare.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#11

Post by simonask »

TuxSH wrote: post #10
flohofwoe wrote: post #7

Earlier quoted context omitted.

Sort of fitting though, because C++ coroutines turned out quite the mess (are they actually usable in real world code by now?). I think in the end it's just another story of a C++ veteran living through the inevitable Modern C++ trauma and divorce ;) (I wonder what he's up to today, ITHare was quite popular in game dev circles in the 2010s for his multiplayer networking blog posts and books)

> C++ coroutines turned out quite the mess (are they actually usable in real world code by now?). They are, they are extensively used by software like ScyllaDB which itself is used by stuff like Discord, BlueSky, Comcast, etc. C++ coroutines and "stackless coroutines" in general are just compiler-generated FSMs. As for allocation, you can override operator new for the promise types and that operator new gets forwarde…

They are compiler-generated FSMs, but I think it's worth noting that the C++ design was landed in a way that precluded many people from ever seriously considering using them, especially due to the implicit allocation. The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble.

Rust gets it right, but has its own warts, especially if you're coming from async in a GC world. But there's no allocation; Futures are composable value types.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#12

Post by simonask »

gsliepen wrote: post #2

Early programming languages had to work with the limited hardware capabilities of the time in order to be efficient. Nowadays, we have so much processing power available that the compiler can optimize the code for you, so the language doesn't have to follow hardware capabilities anymore. So it's only logical that the current languages should work the limitations of the compilers. Perhaps one day those limitations wil…

It's not really about "limitations" of the hardware, so much as it is about the fact that things have crystallized a lot since the 90s. There are no longer any mainstream architectures using big-endian integers for example, and there are zero architectures using anything but two's complement. All mainstream computers are Von Neumann machines too (programs are stored; functions are data). All bytes are 8 bits wide, and native word sizes are a clean multiple of that.

Endianness will be with us for a while, but modern languages don't really need to consider the other factors, so they can take significant liberties in their design that match the developer's intuition more precisely.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#13

Post by pjmlp »

flohofwoe wrote: post #7
bluetomcat wrote: post #3

What a mess of an article. A pretentious mishmash of scattered references with some vague abstract claims that could be summarised in one paragraph.

Sort of fitting though, because C++ coroutines turned out quite the mess (are they actually usable in real world code by now?). I think in the end it's just another story of a C++ veteran living through the inevitable Modern C++ trauma and divorce ;) (I wonder what he's up to today, ITHare was quite popular in game dev circles in the 2010s for his multiplayer networking blog posts and books)

They have been always usable in the real world, as they were initially based on async model of doing C++ programming in WinRT, inspired by .NET async/await.

Hence why anyone that has done low level .NET async/await code with awaitables and magic peoples, will fell right at home in C++ co-routines.

Anyone using WinAppSDK with C++ will eventually make use of them.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#14

Post by gsliepen »

lmm wrote: post #4
gsliepen wrote: post #2

Early programming languages had to work with the limited hardware capabilities of the time in order to be efficient. Nowadays, we have so much processing power available that the compiler can optimize the code for you, so the language doesn't have to follow hardware capabilities anymore. So it's only logical that the current languages should work the limitations of the compilers. Perhaps one day those limitations wil…

Isn't that the tail wagging the dog? If you build the language to fit current compilers then it will be impossible to ever redesign those compilers.

Why would that be impossible? Most programming languages are still Turing complete, so you can build whatever you want in them.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#15

Post by gsliepen »

simonask wrote: post #12
gsliepen wrote: post #2

Early programming languages had to work with the limited hardware capabilities of the time in order to be efficient. Nowadays, we have so much processing power available that the compiler can optimize the code for you, so the language doesn't have to follow hardware capabilities anymore. So it's only logical that the current languages should work the limitations of the compilers. Perhaps one day those limitations wil…

It's not really about "limitations" of the hardware, so much as it is about the fact that things have crystallized a lot since the 90s. There are no longer any mainstream architectures using big-endian integers for example, and there are zero architectures using anything but two's complement. All mainstream computers are Von Neumann machines too (programs are stored; functions are data). All bytes are 8 bits wide, an…

I was thinking more about higher-order things, like a compiler being able to see that your for-loop is just counting the number of bits set in an integer, and replacing it with a popcount instruction, or being able to replace recursion with tail calls, or doing complex things at compile-time rather than run-time.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#16

Post by lmm »

gsliepen wrote: post #14
lmm wrote: post #4

Earlier quoted context omitted.

Isn't that the tail wagging the dog? If you build the language to fit current compilers then it will be impossible to ever redesign those compilers.

Why would that be impossible? Most programming languages are still Turing complete, so you can build whatever you want in them.

You said this was an efficiency issue, and Church-Turing says nothing about efficiency.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#17

Post by pjmlp »

simonask wrote: post #11
TuxSH wrote: post #10

Earlier quoted context omitted.

> C++ coroutines turned out quite the mess (are they actually usable in real world code by now?). They are, they are extensively used by software like ScyllaDB which itself is used by stuff like Discord, BlueSky, Comcast, etc. C++ coroutines and "stackless coroutines" in general are just compiler-generated FSMs. As for allocation, you can override operator new for the promise types and that operator new gets forwarde…

They are compiler-generated FSMs, but I think it's worth noting that the C++ design was landed in a way that precluded many people from ever seriously considering using them, especially due to the implicit allocation. The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble. Rust gets it right, but has its own warts, especially if you're com…

The C++ model is that in theory there is an allocation, in practice depending on how a specific library was written, the compiler would be able to elide the allocation.

It is the same principle that drives languages like Rust in regards to being safe by default, in theory stuff like bounds checks cause a performance hit, in practice compilers are written to elide as much as possible.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#18

Post by uep »

simonask wrote: post #11
TuxSH wrote: post #10

Earlier quoted context omitted.

> C++ coroutines turned out quite the mess (are they actually usable in real world code by now?). They are, they are extensively used by software like ScyllaDB which itself is used by stuff like Discord, BlueSky, Comcast, etc. C++ coroutines and "stackless coroutines" in general are just compiler-generated FSMs. As for allocation, you can override operator new for the promise types and that operator new gets forwarde…

They are compiler-generated FSMs, but I think it's worth noting that the C++ design was landed in a way that precluded many people from ever seriously considering using them, especially due to the implicit allocation. The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble. Rust gets it right, but has its own warts, especially if you're com…

I think you missed an important point in the parent comment. You can override the allocation for C++ coroutines. You do have control over details like allocation.

C++ coroutines are so lightweight and customizable (for good and ill), that in 2018 Gor Nishanov did a presentation where he scheduled binary searches around cache prefetching using coroutines. And yes, he modified the allocation behavior, though he said it only resulted in a modest improvement on performance.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#19

Post by rcxdude »

lmm wrote: post #4
gsliepen wrote: post #2

Early programming languages had to work with the limited hardware capabilities of the time in order to be efficient. Nowadays, we have so much processing power available that the compiler can optimize the code for you, so the language doesn't have to follow hardware capabilities anymore. So it's only logical that the current languages should work the limitations of the compilers. Perhaps one day those limitations wil…

Isn't that the tail wagging the dog? If you build the language to fit current compilers then it will be impossible to ever redesign those compilers.

Maybe, but if you don't consider the existing compilers you run the risk of making something that is unimplementable in one of the existing compilers, or perhaps at all. (C++ has had some issue with this in the past, which is I think why it's explicitly a consideration in the process now)

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#20

Post by flohofwoe »

gsliepen wrote: post #15
simonask wrote: post #12

Earlier quoted context omitted.

It's not really about "limitations" of the hardware, so much as it is about the fact that things have crystallized a lot since the 90s. There are no longer any mainstream architectures using big-endian integers for example, and there are zero architectures using anything but two's complement. All mainstream computers are Von Neumann machines too (programs are stored; functions are data). All bytes are 8 bits wide, an…

I was thinking more about higher-order things, like a compiler being able to see that your for-loop is just counting the number of bits set in an integer, and replacing it with a popcount instruction, or being able to replace recursion with tail calls, or doing complex things at compile-time rather than run-time.

At least the popcount example (along with some other 'bit twiddling hacks' inspired optimizations) is just a magic pattern matching trick that happens fairly late in the compilation process though (AFAIK at least), and the alternative to simply offer an optional popcount builtin is a completely viable low-tech solution that was already possible in the olden days (and this still has the the advantage that it is entirely predictable instead of depending on magic compiler tricks).

Basic compile time constant folding also isn't anything modern, even the most primitive 8-bit assemblers of the 1980s allowed to write macros and expressions which were evaluated at compile time - and that gets you maybe 80% to the much more impressive constant folding over deep callstacks that modern compilers are capable of (e.g. what's commonly known as 'zero cost abstraction').

Post reply on HN