Is C faster than C++

[zhaoyandong]

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.

I can't find the answer in the web.

I'll appreciate any suggestion on this.
Thank you.

 

[Old Wolf]

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.
I can't find the answer in the web.

It isn't faster.

I'll appreciate any suggestion on this.

Go to different interviews.

 

[Alf P. Steinbach]

* zhaoyandong:

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.

I can't find the answer in the web.

I'll appreciate any suggestion on this.

Probably they wanted to check whether you understood the difference between C
and C++. And if you did, you would have answered that every C program can
also be expressed in C++ with just minor cleaning up of syntax and
declarations, and that very often the same compiler is used for C and C++. So
that given a fast C program, you also have a just as fast C++ program.

And then you might have gone on to talk about how some of that performance
could be traded for shorter development time and general maintainability, in
C++, but not in C.

And concluded that neither language is inherently faster than the other, but
that C++ gives you a much wider range of practical development techniques: all
of C, plus plus (ah, _that_'s what the "++" stands for!).

 

[Gianni Mariani]

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.

I can't find the answer in the web.

The question is like asking "which is faster, a Lamborghini or a
Ferrari". The answer should be, they're only as fast as it's driver
skill can make them go.

 

[David White]

In one of my interview, some people asked me why C is faster C++, and
tell me to illustrate at least two reasons.

It's a stupid question. C++ is mostly a superset of C. There's no reason why
a C program compiled by a C compiler should be faster than the same program
compiled by a C++ compiler. And if you use features that exist only in C++,
such as virtual functions, you would have to simulate the dynamic dispatch
in C somehow to do a comparison, and C shouldn't be able to do it any
faster. Or you might need a completely different design in C, and you can't
generalize about the performance comparison of functionally equivalent
programs of different design. The interviewers are either clueless about C++
or they expected you tell them they were talking nonsense.

DW

 

[Dave Rahardja]

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.

I can't find the answer in the web.

I'll appreciate any suggestion on this.
Thank you.

The idea that C is inherently faster than C++ is a myth, but one that I
encounter regularly, especially with ex-C programmers who don't really
understand the C++ language.

I'd go to a different interview if you want to use C++ in your daily work, or
else prepare to regularly fight an uphill battle against people who hold on to
that unfounded prejudice.

-dr

 

[Greg]

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.

I can't find the answer in the web.

I'll appreciate any suggestion on this.
Thank you.

Never be reluctant to ask for clarification or to disagree with the
premise of a question, particularly an interview question. After all,
the question may designed specifically to test for those traits. In
other words, how the candidate handles the loaded question is being
assessed and not the content of the answer given.

In this case, asking for clarification would be in order:

"By what measurement have you found C++ to be slower than C?"

If the response is "average dipatch time per function call." you could
then explain how virtual functions differ from directly called
routines. But you could also note that the overhead is minimal and is
rarely an issue.

Otherwise, feel free to question the premise of the question,,
particularly a loaded question:

"Not having any specific measurements, I would not be able
to conclude that C++ is slower than C."

Greg

 

[Karl Heinz Buchegger]

[snip]
In this case, asking for clarification would be in order:

"By what measurement have you found C++ to be slower than C?"

If the response is "average dipatch time per function call." you could
then explain how virtual functions differ from directly called
routines. But you could also note that the overhead is minimal and is
rarely an issue.

In fact it is *never* an issue, because it isn't slower. Not if you
compare a virtual function call with the *equivalent* functionality
in C. And that is all that matters: virtual function calls in a code
are there for a reason. So you need to satisfy that reason in C or C++.
When doing so, one figures out, that C++ virtual functions are the fastest
possible way to satisfy that reason. Plus there is one benefit: maintainability.

Other then that, I agree to everything else you said.

 

[Walter Bright]

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.

I can't find the answer in the web.

I'll appreciate any suggestion on this.
Thank you.

Tell them that performance bottlenecks are usually lurking in unanticipated
locations in the code, so you use a profiler and attempt to identify where
any bottlenecks are before wasting time optimizing the non-bottlenecks.

 

[Gianni Mariani]

Greg wrote:
....

If the response is "average dipatch time per function call." you could
then explain how virtual functions differ from directly called
routines. But you could also note that the overhead is minimal and is
rarely an issue.

Bzzt - wrong.

It is NOT a given that virtual calls are slower than non-virtual. On
some architectures, they may even be faster than regular function calls.

Performance is one of those things that depends on the situation at hand.

 

[Ganesh]

C++ leads to a very generic code. But it may be the case that you do
not use such genericity always. For instance, you can have generic sort
function in C++. But if you always just use a specific 'quicksort on
doubles', may be a naive C or Fortran program written specifically for
this would be faster. My opinion is that C++ may introduce some hidden
costs, that may be visible only to an experienced programmer. Lower the
level of programming, (maybe) lower the overheads. This is IMHO.

 

[Ganesh]

C++ leads to a very generic code. But it may be the case that you do
not use such genericity always. For instance, you can have generic sort
function in C++. But if you always just use a specific 'quicksort on
doubles', may be a naive C or Fortran program written specifically for
this would be faster. My opinion is that C++ may introduce some hidden
costs, that may be visible only to an experienced programmer. Lower the
level of programming, (maybe) lower the overheads. This is IMHO.

 

[Kai-Uwe Bux]

C++ leads to a very generic code. But it may be the case that you do
not use such genericity always. For instance, you can have generic sort
function in C++. But if you always just use a specific 'quicksort on
doubles', may be a naive C or Fortran program written specifically for
this would be faster.

The sorting thing is a very poor example: A native C program would use qsort
and be slower since the call to the comparison function is not inlined
whereas the use of templates will allow the compiler to inline and optimize
the whole instantiation of sort for the particular type.

In order to actually beat C++ std::sort() you would have to roll your own
sorting code for, say, doubles in C. Now, when you do that, you could as
well just do it in C++ and provide a new sorting template. [Also, every
once in a while I try to beat the sorting and nth_element routines in the
STL of my compiler. It is *very* hard to just get even. I assure you:
implementing quick-sort for some built in data type is not going to beat
std::sort().]

My opinion is that C++ may introduce some hidden
costs, that may be visible only to an experienced programmer. Lower the
level of programming, (maybe) lower the overheads. This is IMHO.

In C++ you can program as low-level as you can in C. Also, not every level
of abstraction incurs overhead at run-time. Templates incur overhead at
compile time but can considerably improve performance during run time.


Best

Kai-Uwe Bux

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

My opinion is that C++ may introduce some hidden costs, that may be
visible only to an experienced programmer. Lower the level of
programming, (maybe) lower the overheads. This is IMHO.

What overhead? I don't call overhead something so minimal that nobody but a
expert can measure it. And the cost of programming at a lower level is
usually very visible.

And by the way, there are no hidden costs. You can take the object code and
inspect it, supposed you have that experienced programmer at hand.

 

[Greg]

[snip]
In this case, asking for clarification would be in order:

"By what measurement have you found C++ to be slower than C?"

If the response is "average dipatch time per function call." you could
then explain how virtual functions differ from directly called
routines. But you could also note that the overhead is minimal and is
rarely an issue.

In fact it is *never* an issue, because it isn't slower. Not if you
compare a virtual function call with the *equivalent* functionality
in C. And that is all that matters: virtual function calls in a code
are there for a reason. So you need to satisfy that reason in C or C++.
When doing so, one figures out, that C++ virtual functions are the fastest
possible way to satisfy that reason. Plus there is one benefit: maintainability.

Other then that, I agree to everything else you said.

I would agree that the difference in dispatch time between a virtual
function call and a direct call should not be an issue in a
well-written C++ program; but that statement is not the same as saying
the difference is always negligible in any C++ program, no matter how
it is written. Or that a C++ programmer need not be aware of the
difference.

For instance, one could imagine that adding a virtual method to a class
like std::string would have a measurable negative effect on the
performance of a C++ program with many stack-based strings. Now clearly
a virtual method in this case is no doubt a bad idea. But that fact may
not be readily apparent to a C programmer. In other words, a C++
programmer has to be aware that virtual function calls are not
completely free; and as a consequence, methods should not be declared
virtual indiscriminately.

C++ is obviously a more complex language than C. Greater complexity
does not necessarily imply less efficiency. But it does require more
care at times to recognize inefficiency when it arises. I believe this
is true if for no other reason than that there are simply more ways to
make such mistakes in C++. Now, just to be clear: I am not arguing that
C++ is too dangerous a language in which to write programs. On the
contrary - I'm not really stating anything other than the benefits of
C++ greater expressiveness cannot be realized in the absence of a solid
understanding of the language itself.

Greg

 

[Greg]

Greg wrote:
...

Bzzt - wrong.

It is NOT a given that virtual calls are slower than non-virtual. On
some architectures, they may even be faster than regular function calls.

Performance is one of those things that depends on the situation at hand.

But it is not impossible either.

And remember the scenario. In response to our challenge, the
interviewer produces a huge stack of highly detailed profiling data
that conclusively shows that for the program profiled, calls dispatched
to virtual functions required more cycles than direct calls.

So what is the candidate to do now?

One approach would be to angrily denounce the data as a pack of lies,
while slamming his or her first on the table. This approach is a
surefire way to be hired if the intent of the question was to assess
the candidate's passion for C++. If that was not the intent of the
question, though, this technique may have mixed results.

The problem with the "angry denunciation" response though, is that the
data could very well be accurate. It cannot be dismissed.

Next, there is the approach that you are advocating: for the candidate
to argue that this data can be ignored since there are other programs
in which virtual function calls are not slower. But that response is
not well connected to the situation on hand. And it is of little
comfort here, if the program that the company sells happens not to be
one of those programs for which virtual function calls are faster than
direct calls. Again, the candidate appears to skirt the issue or be
unwilling to accept facts.

The best approach is head on: -Yes, there may be additional overhead
when calling a virtual function but that overhead is a good investment.
And here's why - and then rattle off the reasons.

Making excuses or saying that there may be exceptions in some cases is
simply "lame". It only makes the candidate look like an apologist.

Greg

 

[David White]

I would agree that the difference in dispatch time between a virtual
function call and a direct call should not be an issue in a
well-written C++ program; but that statement is not the same as saying
the difference is always negligible in any C++ program, no matter how
it is written. Or that a C++ programmer need not be aware of the
difference.

I didn't think KHB was talking about the difference in dispatch time between
a virtual call and a direct call. I think he was saying that you have a
virtual function for a reason, which is that at run-time the same call can
end up in different places at different times. Therefore, you cannot simply
replace a virtual call in C++ with a direct call in C. You would have to
somehow replicate the C++ virtual call in C, e.g., with a function pointer,
switch, etc.

DW

 

[Jack Klein]

In one of my interview, some people asked me why C is faster C++, and tell
me to illustrate at least two reasons.

I can't find the answer in the web.

I'll appreciate any suggestion on this.
Thank you.

You can definitely type "C" in one-half to two-thirds of the time it
takes to type "C++".

In the hands of the type of programmer who asks questions like this
(although the people interviewing you might not have been
programmers), each is worser and slower than the other.

 

[Ganesh]

By C++ I mean {C++} - -{C}. That is, those features exclusively meant
for C++. I wouldn't consider a program that just uses main + some plain
functions as a real C++ program. You can write a C program in C++. But
a real C++ program should have all those OO features - templates,
virtual methods, inheritance and some design patterns. We have to
compare such a C++ program and its equivalent C counterpart to show
the relative merits. This is also MHO. A better comparison is C++ vs
FORTRAN.

Ganesh

 

[Kai-Uwe Bux]

By C++ I mean {C++} - -{C}. That is, those features exclusively meant
for C++. I wouldn't consider a program that just uses main + some plain
functions as a real C++ program. You can write a C program in C++. But
a real C++ program should have all those OO features - templates,
virtual methods, inheritance and some design patterns. We have to
compare such a C++ program and its equivalent C counterpart to show
the relative merits. This is also MHO.

(a) If you refer to something, please quote it. So here is a relevant part
of our discussion:

The sorting thing is a very poor example: A native C program would use
qsort and be slower since the call to the comparison function is
not inlined whereas the use of templates will allow the compiler to inline
and optimize the whole instantiation of sort for the particular type.

(b) Your response completely misses the point [which is not apparent since
you snipped it].

As you can see from the quotation, I was specifically talking about
*idiomatic* ways of doing your example (sorting) in C versus C++. As it
turns out, the {C++} - {C} features involved (in this case, templates)
actually *improve* performance in idiomatically written programs. This, one
can actually measure. For a detailed discussion of sorting efficiency, see:

B. Stroustrup: Learning C++ as a New Language (page 6ff).
[http:://www.research.att.com/~bs/new_learning.pdf]

A better comparison is C++ vs FORTRAN.

In which sense would that be a "better" comparison? And would you choose
number crunching programs, network protocoll implementations, or GUI-driven
programs for the comparison?


Best

Kai-Uwe Bux