The use of basic classes can very quickly become a performance issue because of data locality issues, confusing the branch predictor, and generally using instructions where C wouldn’t need to.
They’re honestly insignificant compared to the value you get in return, especially with the better typing and application design, but they’re there.
If you stick to the builtin classes, no capturing lambdas, don’t use too many generics, and use const often enough, you should be able to produce code that’s as fast as C. At that point you may as well use C, though, especially because one mistake with semantics and you’re back to hitting C++ related performance issues anyway.
Compile time has got to be part of the convo esp when it comes to the kernel. The Linux kernel is one of the few bits where end-users are actively encouraged to compile from source. It is a feature!
Adding C++ compilitis is pain for what gain, from a kernel pov.
I am not a big fan of c++ overall however that is because other languages have emerged that are sweeter than C that gate some of the people issues with C++.
Anyone who has ever had a thing that was like a thing but not exactly the thing, in C, knows C ain’t great at that.
In this video, we’ll do a deep dive on what C++ Polymorphism is, what “virtual” does under the hood, and ultimately why it is SUCH a performance hit compared to languages like C and Rust.
That’s just plainly false. A std::sort() for examples beats a qsort() easily. C just doesn’t have the tools to handle that kind of thing without a lot of manual code duplication.
The reason for not using C++ is simply that it’s a huge monster of a language, that makes it difficult to find common ground for a programming style. In C that is much easier as you have much less features to worry about. It is more verbose and error prone, but also more predictable and easier to review, as the code you see is what you get in the binary. In C++ can have a mountain of stuff hidden behind operator overloading, exceptions and other stuff, which makes it very difficult to reason about.
Aside from that I think C is more performant than C++ (indeed when you use the bells and whistles that C++ offers), you are comparing the libraries with each other.
The fact that the implementation of one random std::Sort is faster than the implementation of qsort() is comparing libraries, not the languages. You are comparing the algorithm of the Rust Sort with quicksort (which is obviously the qsort you are referring to.
I am certain there are sort implementations in C which outperform Rust.
Having said that, I immensely enjoy Rust because it forces me to think about the error handling and it does not give me the quirks of C/C++ (index out of bounds, memory corruption).
It’s not the libraries that make the difference, but that C++ templates allow you to write generic code that is easy to use and easy to optimized for the compiler due to having all the real data types readily available, while C has to fiddle with void* and function pointer to get similar flexibility, which are much harder to optimize, as none of the type information is there.
while C has to fiddle with void* and function pointer to get similar flexibility, which are much harder to optimize, as none of the type information is there.
I thought we were discussing speed, not ease of use?
If you manually hand optimize every line of code, C and C++ are identical. That’s a worthless discussion to have. The point is that you can write in C++ high level code that would require substantial code duplication to match the speed in C, as C just doesn’t offer the tools for that level of abstraction.
How is C faster than C++? Unless you use virtual functions, it’s as performant as C. And you definitely wouldn’t use virtual functions in a kernel.
The use of basic classes can very quickly become a performance issue because of data locality issues, confusing the branch predictor, and generally using instructions where C wouldn’t need to.
They’re honestly insignificant compared to the value you get in return, especially with the better typing and application design, but they’re there.
If you stick to the builtin classes, no capturing lambdas, don’t use too many generics, and use
constoften enough, you should be able to produce code that’s as fast as C. At that point you may as well use C, though, especially because one mistake with semantics and you’re back to hitting C++ related performance issues anyway.C++ is only as fast as C if you use only the parts of C++ that are identical to C. In other words, C is faster than C++
You can use compile time polymorphism in C++ without any runtime performance cost.
Compile time has got to be part of the convo esp when it comes to the kernel. The Linux kernel is one of the few bits where end-users are actively encouraged to compile from source. It is a feature!
Adding C++ compilitis is pain for what gain, from a kernel pov.
I am not a big fan of c++ overall however that is because other languages have emerged that are sweeter than C that gate some of the people issues with C++.
Anyone who has ever had a thing that was like a thing but not exactly the thing, in C, knows C ain’t great at that.
Unfortunately, that’s not true
The description says:
This is not about compile-time polymorphism.
Here is an alternative Piped link(s): https://piped.video/watch?v=aq365yzrTVE
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
That’s just plainly false. A
std::sort()for examples beats aqsort()easily. C just doesn’t have the tools to handle that kind of thing without a lot of manual code duplication.The reason for not using C++ is simply that it’s a huge monster of a language, that makes it difficult to find common ground for a programming style. In C that is much easier as you have much less features to worry about. It is more verbose and error prone, but also more predictable and easier to review, as the code you see is what you get in the binary. In C++ can have a mountain of stuff hidden behind operator overloading, exceptions and other stuff, which makes it very difficult to reason about.
Aside from that I think C is more performant than C++ (indeed when you use the bells and whistles that C++ offers), you are comparing the libraries with each other.
The fact that the implementation of one random
std::Sortis faster than the implementation ofqsort()is comparing libraries, not the languages. You are comparing the algorithm of the Rust Sort with quicksort (which is obviously theqsortyou are referring to.I am certain there are sort implementations in C which outperform Rust.
Having said that, I immensely enjoy Rust because it forces me to think about the error handling and it does not give me the quirks of C/C++ (index out of bounds, memory corruption).
It’s not the libraries that make the difference, but that C++ templates allow you to write generic code that is easy to use and easy to optimized for the compiler due to having all the real data types readily available, while C has to fiddle with
void*and function pointer to get similar flexibility, which are much harder to optimize, as none of the type information is there.I thought we were discussing speed, not ease of use?
If you manually hand optimize every line of code, C and C++ are identical. That’s a worthless discussion to have. The point is that you can write in C++ high level code that would require substantial code duplication to match the speed in C, as C just doesn’t offer the tools for that level of abstraction.
…so now we are discussing not speed again but ease of use.
Not everything with an R in it is faster than C. Read up about it. Everyone says so.
I’m out.
Since C++ has Turing complete compiling, I guess technically it can go infinite compilation time