[comp.lang.c++] Efficiency of C++ relative to C??

dvadura@watdragon.waterloo.edu (Dennis Vadura) (09/19/89)

I have the following question:

	Has anyone performed a study comparing the execution time cost
	of C++ language features compared to C?  In particular I am
	interested in the following problem.  Given a particular program,
	code it in C and code it in C++ using the full power of C++.
	Time the execution speed of both programs on the same input
	data.

	Then ask how much of the cost of the C++ program is due to the
	use of virtual functions, and what is the call overhead for
	a virtual function when compared to the call overhead for a
	normal call in C?

This may not be the best way to determine what I am after, but I want
a feel for how much of a penalty (if any, although I suspect it's there
and may be quite large) using C++ is going to incur if I switch from using C
to using C++ for large software projects because I want to use the
enhanced expressive power of C++ over C.

As an example there exist companies that spend 100's of thousands a year
to improve the efficiency of their code by 5%.  If on average C++ language
features incur high overhead then the cost in efficiency
for them to switch to a language like C++ with its enhanced expressive
power is too prohibitive.  Such a move would represent a large
step backward in their product.

So I am looking for paper references to such studies, or even anecdotal
experience, as I don't think many such studies exist.

ie. what is the net consensus on this?  If I care about the efficiency
    of my code and want to keep it as efficient as it is presently but
    switch to C++, is this a realistic expectation.  If not, then why
    is my expectation unrelistic, and how do I address a solution?
    Is a clever optimizer sufficient?

Send mail and I will collect the responses and summarize to the net.

-thanks
-dennis
-- 
--------------------------------------------------------------------------------
The only happy people are Single MEN   |Dennis  UUCP,BITNET:    dvadura@water
and Married WOMEN.                     |Vadura  EDU,CDN,CSNET:  dvadura@waterloo
================================================================================

pierson@multimax (Dan Pierson) (09/19/89)

In article <16493@watdragon.waterloo.edu>, dvadura@watdragon (Dennis Vadura) writes:
>	Then ask how much of the cost of the C++ program is due to the
>	use of virtual functions, and what is the call overhead for
>	a virtual function when compared to the call overhead for a
>	normal call in C?

To paraphrase one of Danny Bobrow's comments when people raise the
analogous question about the Common Lisp Object System:

It isn't realistic to compare the cost of a virtual mentod with the
cost of a normal function call; if all you wanted was a normal
function call you would use one.  A relevant question is: what is cost
of a virtual function call compared to the cost of the C code you
would use to do the same thing the virtual function call is trying to
do?  Such code might look like:

void print (object *thing)
{
    switch (thing->type) {
      case OBJ_PICTURE:
    	print_picture(thing);
        break;
      ...
    }
}

In this case, a virtual function call should be compared to:
    C call + structure reference via pointer + switch statement

I suspect that you will find that C++ virtual methods compare rather
well to the above.

Caveat: Of course it is possible to write C++ code that uses virtual
methods when normal methods would do the job.  It's also possible to
write C++ code that uses normal methods when inline methods would be
more appropriate.  It's possible to write poor code in C too, but that
shouldn't be the point of a language comparison.
-- 
                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax,ihnp4}!encore!pierson
Internet: pierson@multimax.arpa

shopiro@alice.UUCP (Jonathan Shopiro) (09/19/89)

In article <16493@watdragon.waterloo.edu>, dvadura@watdragon.waterloo.edu (Dennis Vadura) writes:
> I have the following question:
> 
> 	Has anyone performed a study comparing the execution time cost
> 	of C++ language features compared to C?  In particular I am
> 	interested in the following problem.  Given a particular program,
> 	code it in C and code it in C++ using the full power of C++.
> 	Time the execution speed of both programs on the same input
> 	data.
> 
> 	Then ask how much of the cost of the C++ program is due to the
> 	use of virtual functions, and what is the call overhead for
> 	a virtual function when compared to the call overhead for a
> 	normal call in C?
> 
Yes, virtual functions are more expensive than ordinary functions
(about 4 or 5 more memory references per call), but you don't have to
use virtual functions if they aren't needed.  Typically a virtual
function call in C++ replaces a switch statement in C.  If the cases of
the switch each call functions, then the C++ version will certainly
win.  If the cases each execute a single line of code then it will
depend the efficiency of the code generated by the compiler for the
switch.

In your question you assume ``the full power of C++.''  Clearly if you
use every feature wherever it could fit (for example, make every
function and base class virtual), you could take a performance hit,
but if you use the power of the language appropriately, I think you
will come out ahead.  Note that it will take some time to learn the
performance implications of the various C++ features, and to develop
good judgement about when to use which.  Also, when you're thinking
about getting the last iota of performance, remember that the C++
translator generates C, so you could always have written the same
program in C, and any compiler generates machine code, so you could
always have written the same program in assembler.  That is to say, if
you're considering higher level languages at all, performance is not
your only criterion, you're also concerned about programmer productivity.

So, if you're using C now and you're unhappy with it because even
though you are a very good C programmer, your programs don't run fast
enough, C++ is unlikely to help you much (or at all).  Try assembly
language or a better optimizer.  If you're unhappy with C because
programming large applications is too expensive, then try C++.  You
will be able to build more complicated applications than you could
before, and, if you program carefully, you will not incur any
performance penalty.
-- 
		Jonathan Shopiro
		AT&T Bell Laboratories, Warren, NJ  07060-0908
		research!shopiro   (201) 580-4229

oz@yunexus.UUCP (Ozan Yigit) (09/20/89)

In article <16493@watdragon.waterloo.edu> dvadura@watdragon.waterloo.edu (Dennis Vadura) writes:
>I have the following question:
>
>	Has anyone performed a study comparing the execution time cost
>	of C++ language features compared to C?  In particular I am
>	interested in the following problem.  Given a particular program,
>	code it in C and code it in C++ using the full power of C++.
>	Time the execution speed of both programs on the same input
>	data.

See Univ. of Illinois Tech report UIUCDCS-R-88-1461 "A C++ Interpreter for
Scheme" (I believe this was presented on a C++ Conference) which
essentially describes a re-write of a subset scheme interpreter in C++.
The result, according to the authors, is a faster interpreter with
improved internal structure, increased modularity and decreased effort to
maintain and extend it. The paper contains a detailed comparison of
performance. Take it for what it is worth. 

oz
-- 
The king: If there's no meaning	   	    Usenet:    oz@nexus.yorku.ca
in it, that saves a world of trouble        ......!uunet!utai!yunexus!oz
you know, as we needn't try to find any.    Bitnet: oz@[yulibra|yuyetti]
Lewis Carroll (Alice in Wonderland)         Phonet: +1 416 736-5257x3976

psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (09/20/89)

> In article <16493@watdragon.waterloo.edu>, dvadura@watdragon.waterloo.edu
(Dennis Vadura) asks how efficient C++ is.  C++ has virtual functions,
which are less efficient that C functions (but more efficient than a
switch and a function call), and inline functions, which are more
(time) efficient than C functions.  A "normal" C++ function call, or a
non-virtual member function call, is exactly as efficient as a C
function call.

I think some studies were done (don't ask me for references) where
someone re-wrote a C program in C++; the result was a faster program.
This isn't a particularly good experiment (you need to have someone
re-write the same application in C, to see what the effects of
re-writing are, as opposed to the effects of C++).

Certainly C++, like C, was written so a good programmer can write
small, fast programs.

In article <9924@alice.UUCP>, shopiro@alice.UUCP (Jonathan Shopiro) writes:
> So, if you're using C now and you're unhappy with it because even
> though you are a very good C programmer, your programs don't run fast
> enough, C++ is unlikely to help you much (or at all).  Try assembly
> language or a better optimizer.

Rather, try applying "the two laws of program efficiency":

(1)  Make it right before you make it fast.

(If you don't care if it's right, replace it with "Hello, world"; that
runs *much* faster!-)

(2)  Measure it, and only work on the parts of the program that take up
the most time.

(That is, profile your program, find the ten percent of the code the
program spends most of its time in, and work on that part.)

If there's a third law, it's to pick a fast algorithm, rather than
twiddling a slow one.  I recommend Jon Louis Bentley's WRITING
EFFICIENT PROGRAMS (1982, Prentice-Hall, ISBN 0-13-970244-X) for lots
of insight into this topic.

(Or buy faster hardware, if you can afford it.)

> Jonathan Shopiro, research!shopiro

Paul S. R. Chisholm, AT&T Bell Laboratories
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.

johnson@p.cs.uiuc.edu (09/20/89)

The 1988 C++ conference has a paper by Russo and Kaplan in which
they took a C program (a Scheme interpreter), rewrote it in C++,
and it was faster.  It turns out that virtual functions are faster
than switch statements, at least for the machine they were using.

dvadura@watdragon.waterloo.edu (Dennis Vadura) (09/21/89)

In article <9924@alice.UUCP> shopiro@alice.UUCP (Jonathan Shopiro) writes:
>In article <16493@watdragon.waterloo.edu>, dvadura@watdragon.waterloo.edu (Dennis Vadura) writes:
>> questions deleted...
>> 
>Yes, virtual functions are more expensive than ordinary functions
>(about 4 or 5 more memory references per call), but you don't have to
>use virtual functions if they aren't needed.
>...
>In your question you assume ``the full power of C++.''  Clearly if you
>use every feature wherever it could fit (for example, make every
>function and base class virtual), you could take a performance hit,
Yes but..., The original motivation for my question was from the standpoint
of using a lot of general classes in my implementation (although I didn't
say that).

In this case if the class designer was opting for maximum flexibility,
generality and reusability then it is my feeling they end up
using virtual functions a lot.  Not only that, but it is my
understanding that you end up designing a lot of classes to use virtual
inheritance so that if you inherit a class twice you only get a single
copy of the class.  I'm not completely clear on this as yet, but this
appears to incur further costs.

>always have written the same program in assembler.  That is to say, if
>you're considering higher level languages at all, performance is not
>your only criterion, you're also concerned about programmer productivity.
I agree whole heartedly.  Infact I have a language in mind where
almost all expressions translate into function invocations and the
implementation mechanism forces these to be indirect references through
a pointer.  The implementation takes a pretty severe hit on performance,
but the great expressive power of the language outweighs this somewhat.
That is why I am curious how much of a performace hit people are willing
to live with.

>programming large applications is too expensive, then try C++.  You
>will be able to build more complicated applications than you could
>before, and, if you program carefully, you will not incur any
>performance penalty.
Sorry I disagree.

   Theorem:
   I can write in C anything I write in C++, it might just
   take longer.

   Proof:
   cfront generates C as output.  I can type it in :-)

-dennis
-- 
--------------------------------------------------------------------------------
The only happy people are Single MEN   |Dennis  UUCP,BITNET:    dvadura@water
and Married WOMEN.                     |Vadura  EDU,CDN,CSNET:  dvadura@waterloo
================================================================================

jonathan@hcr.UUCP (Jonathan Fischer) (09/26/89)

In article <4102@pegasus.ATT.COM> psrc@pegasus.UUCP writes:
>I think some studies were done (don't ask me for references) where
>someone re-wrote a C program in C++; the result was a faster program.
>This isn't a particularly good experiment (you need to have someone
>re-write the same application in C, to see what the effects of
>re-writing are, as opposed to the effects of C++).

	Yes indeed, the latest Usenix C++ conference proceedings has a
paper describing just the above.  (By latest (?) I mean early '89).  I've
lost the address & phone number, but you can order it from Usenix for
$20, I believe.  It seems to me that it was a pretty reasonable experiment,
in that they took a program, "objectified" it, even w/ virtual functions et al,
and compared the execution.  I don't think, therefore, that the effects of
rewriting the application are unwanted side effects in the experiment, since
the only changes, as far as I recall, were the objectificationalisming.

	I read the thing on the subway about 6 months ago, so I welcome any
corrections.
-- 
Jonathan Fischer			| "Break his little legs,
HCR, Toronto, Ontario, Canada		| will you honey?" 
					|		-- Calvin's Father

vinoski@apollo.HP.COM (Stephen Vinoski) (09/28/89)

I just finished reading

             "A C++ Interpreter for Scheme"
             Vincent F. Russo and Simon M. Kaplan
             Proceedings of the USENIX C++ Conference
             Denver, CO, October 1988
             pp. 95-108

which describes porting a Scheme interpreter written in C to C++ and comparing
the performance of the two.  They found that the C++ version was faster because
it used virtual functions instead of switch statements.

It is an excellent paper - check it out.


-steve


-- 
| Steve Vinoski       | Hewlett-Packard Apollo Div. | ARPA: vinoski@apollo.com |
| (508)256-6600 x5904 | Chelmsford, MA    01824     | UUCP: ...!apollo!vinoski |
| "...She's so cold, pure as the driven slush..."  -ZZ Top                     |