Re: Will C++ compilers ever be better than C compilers?

Mayan Moudgill <mayan@watson.ibm.com> wrote:
>Some of us were having an argument about the performance of C++
>vs. C programs, and I made the statement that C programs would
>be faster than C++ programs,


Nope. To back this up, let us investigate a reasonable C compiler and
a reasonable C++ compiler. For my case study, I'll choose gcc and
g++. Specificly they are from egcs from early may, though this fact
won't matter I suspect. I choose gcc and g++ because they are widely
available, compile code for anything, they represent reasonable and
straightforward implementations. While they have advantages and
disadvantages I don't qualify them as significantly better technology
wise, nor worse than what I would call run of the mill quality
implementations.


If you take your favorite C code (I choose expr.c from gcc), and
compile it up with -O9 on both, (after hammering the code to be C++
ready), and then examine the resulting assembly, you'll find virtually
identical results, right down to which register a variable was
allocated in. There are some trivial differences, like function names
being mangled, and some labels being different, as well as register
allocation. And, there were _some_ differences that hurt performance
when compiled with g++, they are:


a few missed delay slot fills
some compare sequences shorter by an insn or two
a couple extra move reg,reg


In general, these types of things are a clock cycle or so. All of
them appeared to be easy enough to squeeze back out, if someone wanted
to. Now, if your entire application is five lines of code, and in
one loop, and that loop has 5 instructions in it, and we got unlucky
and miss by one instruction, that might be a 20% slowdown to the user,
however, we are luckier than that, most applications are larger than
this.


>My claim was that one would have to compile such programs with a C++
>compiler, and the compiler would not be as "optimizing" as a C compiler.


I don't know of a single instance where this is true, if you find one,
let us know.


>My reasons were:
>1) In practice the ultimate size of a compiler is constrained, either
> by the man-power available to code, test and debug the compiler, or
> even given unlimited resources, by the fact that one can only
> add so much to a program (compiler) before it starts breaking
> under the weight of the cumulative changes.
>
> Given that C++ has more features than C, more (most?) of a C++
> compiler will be devoted to "getting the features right" than
> to optimizations - more work will be needed in the front-end
> than in the back-end.


In g++, almost all our time (the people that work on the C++ front
end) _is_ spent on the C++ frontend, and almost 0% (1-2% maybe) on the
backend, or classical optimization issues. By classical, I mean
things unrelated to optimizations involving things like using thunks
or vtable layout.


So we certainly are proof of your assertion that C++ implementors
won't spend any time on the backend or backend issues, the fact is
performace of the g++ compiler compares _equally_ to gcc, in direct
contradiction to your original claim.


Why are we able to get someting for nothing? Easy. Don't reinvent
the wheel. If someone has a code generator, don't throw it out, reuse
it. If someone has a register life time rearranger, just use it. If
someone has a scheduler wire it up. This is _the science of
engineering_. `You just win, and you always win', is another way that
I would like to put it. Are we (gcc/g++) alone? No, all major C++
implementor do this. (Are there any exceptions?)


>2) The effort of implementing an optimization may be higher in C++, because
> it has to work correctly in more contexts


Nope. We extend the semantics of the backend in ways that are needed.
If we fail to do this, there are serious code gen errors. We have
done this for brief periods in the past with very new features (EH) in
g++. Yes, we need to spend some time on it, but not all that much
time, in my experience (g++ maintainer, exception handling
implementor).


> (what happens if there is an exception?


Valid concern.


> what if it is multiply inherited?


Invalid concern.


> The effort of testing the optimization is definitely higher in
> C++; lots more test cases have to be run in C++ to check the
> correctness of an optimization than in C.


Exact opposite in my experience. All the optimization heads are
starting with C usually, and do up their code with C testcases, and
put their work in. After they do, g++ just works better. I don't
even notice sometimes, though I can recompile, notice the change in
the .s files, benchmark it and notice it is faster (or sometimes
slower, if they didn't do a complete enough job).


In practice I usually only have to check language features and mapping
issues, though everyonce in a while, we'll get an -O type problem.
For example, there are 9 -O related problems I put into the g++
testsuite, out of 353 testcases total (that I put in). This is a 2.5%
rate, fairly low.


> Consequently, for the same amount of effort, fewer optimizations
> will be implemented in C++ than in C.


I do zero work and get tons of optimizations.


>3) To get "OO"-ish written in C++ programs to work efficiently requires
> optimizations that are irrelevant in C (consider inter-procedural
> type propagation to convert virtual function calls to function
> calls).


Valid. However, totally irrelevant to the issue at hand. For
example, consider that new takes 1 minute for each call, or that a
virtual dispatch takes a second for each call, pretty slow, however,
when we recompile that C application with the C++ compiler, there are
no calls to new, there are no virtual dispatches, so no matter how
slow any C++ only feature is, it just doens't affect the speed of the
recompiled C code.


> Consequently, the optimizations that are written may be irrelevant
> to the performance of "C subset" C++ code.


True, but it doesn't matter.


>Do you agree?


Nope.


>Can you provide concrete examples?


Yes.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.