yes but the point was the title is ambiguous because almost all people will care about the speed of the binary it outputs not it itself. Indeed that is something people spend a lot of time on
It's measuring the speed of the GCC-compiled-as-C compiler against the GCC-compiled-as-C++ compiler by measuring how long each of those takes to compile the Linux kernel. It's not measuring how long it took to compile GCC itself.
Yeah, people seem confused by this. You can build the last release of gcc either with a C++ compiler or with a C compiler. I did both, and benchmarked the results.
Sorry, I missed the sentence: "With this in mind, and Ian Taylor’s bold assertion that "The C subset of C++ is as efficient as C", I wanted to test what had changed with some actual measurements."
To test a compiler's performances, you use it to compile stuff don't you? That's what TFA does: it builds GCC 4.7 using both a C compiler and a C++ compiler, then looks how the results perform, by compiling stuff with them.
TFA did not bench how long the original compilation (whether through C or through C++) took, that would have been pointless and irrelevant.
> So would not both gcc versions be expected to be very similar on instruction level?
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.
I guess I just assumed that considering that both compilers are part of the same compiler collection that their output, while not guaranteed to be the same, can be expected to be somewhat similar. And that the divergences should not have all that much of an impact on execution speed. But I guess I did jump to a conclusion there.
The backend should do the same thing, but if the C++ frontend gives complete garbage to the backend, I guess there's only so much the backend can do to fix the mess.
Comments
Why? It is measuring the difference between a compiled-as-C GCC and a compiled-as-C++ GCC.
i think the point is largely it is irrelevant. people care abut the speed of their process, not the time it took to generate (within reason)
In this case the process is "GCC" and the way to measure its speed to measure how long it takes to compile something else.
yes but the point was the title is ambiguous because almost all people will care about the speed of the binary it outputs not it itself. Indeed that is something people spend a lot of time on
Difference in compilation times.
It's measuring the speed of the GCC-compiled-as-C compiler against the GCC-compiled-as-C++ compiler by measuring how long each of those takes to compile the Linux kernel. It's not measuring how long it took to compile GCC itself.
Yeah, people seem confused by this. You can build the last release of gcc either with a C++ compiler or with a C compiler. I did both, and benchmarked the results.
Hope that helps! Rusty.
Sorry, I missed the sentence: "With this in mind, and Ian Taylor’s bold assertion that "The C subset of C++ is as efficient as C", I wanted to test what had changed with some actual measurements."
To test a compiler's performances, you use it to compile stuff don't you? That's what TFA does: it builds GCC 4.7 using both a C compiler and a C++ compiler, then looks how the results perform, by compiling stuff with them.
TFA did not bench how long the original compilation (whether through C or through C++) took, that would have been pointless and irrelevant.
Which is indicative of performance.
But isn't GCC still written mostly in C? So would not both gcc versions be expected to be very similar on instruction level?
> So would not both gcc versions be expected to be very similar on instruction level?
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.
I guess I just assumed that considering that both compilers are part of the same compiler collection that their output, while not guaranteed to be the same, can be expected to be somewhat similar. And that the divergences should not have all that much of an impact on execution speed. But I guess I did jump to a conclusion there.
The backend should do the same thing, but if the C++ frontend gives complete garbage to the backend, I guess there's only so much the backend can do to fix the mess.