Re: is C necessarily faster than C++

jplevyak@pink-panther.cs.uiuc.edu (John B. Plevyak) writes:
> OO programs are not inherently inefficient. C++, however, has
> certain features which can inhibit optimization.
> optimizations.


> class A {
> int a;
> virtual int foo() { a++; bar(); return a++; }
> };


> The variable "a" is scoped, but it could be an aliased heap location.
> Without information about bar(), the compiler must spill "a" to memory
> before the call (and similarly around writes through many pointers and
> arrays in C).


How is this different from a global variable in C? You are certainly
correct that "a" may be aliased, but I fail to see how this makes C++ any
worse than C.


> Object-oriented programs tend to have very small functions and to make
> lots of function calls. Virtual functions are both more expensive
> than regular function and *more importantly* prevent inlining


This point seems to get raised a lot, but very seldom does anyone tell the
*whole* story. First of all, one should not make a function virtual in C++
unless you really need different implementations for different classes.
But in that case, you would have needed some sort of decision structure if
you were writing the code in C -- probably a switch statement. So one
should NEVER compare virtual functions in C++ to ordinary functions in C;
they can only be properly compared to code selected by a switch statement.


This is not to say that John's point has no validity, because even
comparing to a switch statement, a virtual function might lose because,
with a switch, the selected code may be inline (either by the programmer or
by the compiler). However, the comparison, to be fair, *must* include the
tradeoff of a switch versus the virtual function call mechanism.


In other words, one should never say that the virtual function call
mechanism adds overhead -- rather, it trades one form of decision mechanism
for another.


Also, I would make the point that writing small functions is generally
regarded as good programming technique in *any* language, not just C++. If
one were to write the branches of a switch statement as separate functions,
then one has exactly the same situation as a set of virtual functions in C++.


Lastly, note that not all C compilers inline functions either. Those that
do don't always do such a hot job.


> -- Specialiation (Customization/Cloning): replicate methods for
> particular situations:


> class A {
> virtual int bar() { ... this->foo() .. }
> virtual int foo() { ... code block 1 .. }
> ...


> class B : A {
> virtual int foo() { ... code block 2 .. }
> ...


> If we replicate bar() into class B we can now inline A::foo()
> into A::bar() and B:foo() into B:bar().


Are you suggesting that the programmer do this, or the compiler?


> It follows that separate compilation of C++ programs can (fundamentally)
> inhibit these optimizatins.


Not if the compiler keeps a program database.


I do agree with John that C++ compilers need to push harder for
optimization. However, I do not believe that fundamentally new techniques
are needed. For instance, Ada compilers have long maintained a program
database from whence information to aid optimization can be extracted. I
also believe that the template feature of C++ cries out for a program
database, so I fully expect this to become the norm.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--

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