Re: is C necessarily faster than C++

bill@amber.ssd.hcsc.com (Bill Leonard)
Tue, 16 May 1995 13:44:09 GMT

          From comp.compilers

Related articles
[17 earlier articles]
Re: is C necessarily faster than C++ jplevyak@pink-panther.cs.uiuc.edu (1995-04-29)
Re: is C necessarily faster than C++ tmb@netcom.com (1995-04-29)
Re: is C necessarily faster than C++ jdean@pysht.cs.washington.edu (1995-05-09)
Re: is C necessarily faster than C++ calder@mumble.cs.Colorado.EDU (1995-05-09)
Re: is C necessarily faster than C++ schow@bnr.ca (stanley (s.t.h.) chow) (1995-05-09)
Re: is C necessarily faster than C++ mike@vlsivie.tuwien.ac.at (1995-05-04)
Re: is C necessarily faster than C++ bill@amber.ssd.hcsc.com (1995-05-16)
Re: is C necessarily faster than C++ itcp@praxis.co.uk (1995-06-23)
Re: is C necessarily faster than C++ jplevyak@violet-femmes.cs.uiuc.edu (1995-06-23)
Re: is C necessarily faster than C++ bill@amber.ssd.hcsc.com (1995-06-30)
Re: is C necessarily faster than C++ bill@amber.ssd.hcsc.com (1995-06-30)
| List of all articles for this month |

Newsgroups: comp.compilers
From: bill@amber.ssd.hcsc.com (Bill Leonard)
Keywords: C, C++, performance
Organization: Compilers Central
References: 95-04-202
Date: Tue, 16 May 1995 13:44:09 GMT

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
--


Post a followup to this message

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