Just to be clear, because this confused me at first:
- 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.
Most of C++ devs think that C is part of C++. Even in this document it is stated something like: C subset of C++ vs C. Why? Because current C is not subset of C++, C++ is compatible with C89 or C90.
This can look like nitpicking, but it's really annoying to again and again hear such things from mouth of C++ gurus.
You just demonstrated another difference in C vs C++ mindset.
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, evenfor 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.
I was under the impression that people were complaining about compilation speed AND the optimizations available to a C++ compiler (even if it was targeting the C subset). I wish the article gave some information about the runtime difference.
The article is about the runtime difference. In this case, the "run" is using gcc's compiled in both languages (via gcc and g++) to build the Linux kernel. Both gcc's show about the same runtime performance when executing this task.
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.
"AND the optimizations available to a C++ compiler (even if it was targeting the C subset). I wish the article gave some information about the runtime difference."
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)
> 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++.
> What optimizations are available to the C subset of C++ that are not also available to 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.
I actually haven't done a comprehensive test yet, but with debugging symbols turned off, are the same set of optimizations performed in gcc and in g++ compiling C code ?
The answer to that question probably depends on what optimization passes are in the language frontend (as opposed to the language-agnostic backend).
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++).
- 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.