GCC and C vs C++ Speed, Measured
rusty.ozlabs.org
rusty.ozlabs.org
- GCC recently switched from building their own code as C, to building as C++. At the moment they only use the subset of C++ which is C, but this affects compiler behaviour.
- People complained that C++ programs couldn't be compiled as efficiently as C programs, and this would make things slower.
- This post shows that compiling GCC as C, versus C++, does not result in an appreciable performance change. He benchmarks this by building the kernel using both versions of GCC.
I can see how this is a little confusing but it shouldn't be that hard. And yet there have been hours of comments on this story that miss this point.
To be absolutely explicit, because I realize my phrase wasn't clear, I was under the impression that C++ optimizations were expensive (say, under -O3 or -Os), so I wish that the same test were run under -O3 or -Os (comparing both the speed of compilation AND the optimizations)
What optimizations are available to the C subset of C++ that are not also available to C? The only thing I can think of offhand which would make compilation of C-with-C++ slower is the difference in symbol naming.
From what I understand of GCC, once the compilation has progressed to the optimization stage the code has already been converted to an intermediate language so the source frontend (gcc or g++) should not necessarily make available extra optimization passes. Again, this is speaking strictly of the subset of C which is common to both C and C++.
Of course, it's possible that some backend optimizations require proper annotations to be placed by the frontend. Either way though the GCC guys have been pretty good with their C support so I'd be very surprised if the C frontend didn't have the superior optimizer (if they are actually different on their support for the C subset supported by C and C++).
I thought C++ had some stricter rules about aliasing, allowing more room for optimization of the same code, but I'm having trouble finding out exactly what the difference was.
This can look like nitpicking, but it's really annoying to again and again hear such things from mouth of C++ gurus.
Now give it to me ;-)
Quote:
"Reality is, many of these C language features are cosmetic extensions introduced in C99 that are trivially emulated using classic C89 syntax."
C doesn't need so many changes like C++, that is the fact and advantage. C++ introduces huge bunch of new stuff, you know add, add, add, then fix, fix, fix. At the end you get overengineered buerocratic 'give me my 5%' language.
So, in C99 some stuff are very useful like variable length arrays, restrict keywords, variadic macros... these are not cosmetic. And btw, even for that you don't need C99 to c89 converter, if you want c89 compatibility use macros. But, hey, macros are ugly, right? They are ugly but they don't make my eyes bleed as some stuff in C++.
So yes, i'm twisting your arm, sorry about that, but it needs to be twisted ;-)
P.S. Your compiler is your choice, just don't force others to use it.
people make this mistake over and over again. there's no point in taking anything but the best time when talking about performance in a preemptive multiprocessing environment. the best time isn't an outlier, every time other than it is!
Benchmarks are only useful if they're indicative of what the likely outcome in a real-world scenario will be.
What you propose is much akin to those completely unrealistic "The Computer Language Benchmarks Game"-style benchmarks that show JavaScript (or Java, or PHP, or whichever slower language you prefer to use instead) as being as fast as C or C++. Perhaps that's true, but only when you discard reality almost completely. JavaScript only ends up performing decently because the benchmark is trivial, and the implementation has been highly tuned, often into a form that we'd never actually see in any real-world product. And predictably, JavaScript's performance ends up being much worse than C's or C++'s when it comes to real software, contrary to what the flawed benchmark suggests.
I've learned that it's unrealistic to expect someone to have actually looked at "The Computer Language Benchmarks Game" before pointing to it as an example for whatever point they wish to make ;-)
The only mystery here is why you think we wouldn't notice that "the implementation has been highly tuned" etc applies just as much to the C and C++ programs as to the JavaScript programs.
This isn't a practical benchmark, though. This is an experimental performance comparison. So to ensure that your results aren't influenced by other variables, it's a good idea to attempt to produce the ideal environment for best performance across both tests. So binding cores(to eliminate as much variance from Linux's thread scheduler) and running nothing else on the machine are actually good decisions to make here.
Comparisons to the Computer Language Benchmarks Game is somewhat irrelevant here, because the comparison being run is actually extremely simple: Using a GCC executable compiled as C versus a GCC executable compiled as C++. The traditional failings of the game aren't here(implementation issues, language-specific tuning issues, etc.) because the code that GCC is compiled from is identical, the compiler options should be identical(except for C vs C++ compile setting), and the test setup should be run on the same machine, with the same compiler options and tuning choices.
Nice to see him here - "ciao" from Italy:-)
Also, he used to poke fun at C++ (many older C devs did that) but more and more of them are coming around to C++. The last automobile systems programmers I worked with were switching to C++ as well. In ten years, C++ will be the new C.
But I like measurements, even if they don't confirm my baises.
What would be interesting is how long it now takes to compile GCC itself. For code that does not use C++ features, I also expect a very minor difference.
It's going to go through the g++ frontend, parsing and compiling it using C++ semantics. There's no guarantee that the C subset of C++ will yield the exact same result as that of an actual C compiler. And a decade or two ago, as TFA notes, it most definitely did not.
Hope that helps! Rusty.
TFA did not bench how long the original compilation (whether through C or through C++) took, that would have been pointless and irrelevant.
Saying that, 40 isn't very many times to draw statistical conclusions so you'd probably need more data.
This wasn't testing the speed of compiling a program as C++ versus compiling it as C; it was testing the speed of compiling the Linux kernel using GCC-compiled-as-C++ as the compiler versus using GCC-compiled-as-C as the compiler.
(And it concluded that the difference was insignificant anyway!)