Is C faster than C++

Discussion in 'C++' started by zhaoyandong, Sep 19, 2005.

  1. zhaoyandong

    zhaoyandong Guest

    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.
     
    zhaoyandong, Sep 19, 2005
    #1
    1. Advertisements

  2. zhaoyandong

    Old Wolf Guest

    It isn't faster.
    Go to different interviews.
     
    Old Wolf, Sep 19, 2005
    #2
    1. Advertisements

  3. * zhaoyandong:
    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!).
     
    Alf P. Steinbach, Sep 19, 2005
    #3
  4. 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.
     
    Gianni Mariani, Sep 19, 2005
    #4
  5. zhaoyandong

    David White Guest

    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
     
    David White, Sep 19, 2005
    #5
  6. 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
     
    Dave Rahardja, Sep 19, 2005
    #6
  7. zhaoyandong

    Greg Guest

    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
     
    Greg, Sep 19, 2005
    #7
  8. 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.
     
    Karl Heinz Buchegger, Sep 19, 2005
    #8
  9. 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.
     
    Walter Bright, Sep 19, 2005
    #9
  10. 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.
     
    Gianni Mariani, Sep 19, 2005
    #10
  11. zhaoyandong

    Ganesh Guest

    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, Sep 19, 2005
    #11
  12. zhaoyandong

    Ganesh Guest

    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, Sep 19, 2005
    #12
  13. zhaoyandong

    Kai-Uwe Bux Guest

    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().]

    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
     
    Kai-Uwe Bux, Sep 19, 2005
    #13
  14. 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.
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Sep 19, 2005
    #14
  15. zhaoyandong

    Greg Guest

    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, Sep 20, 2005
    #15
  16. zhaoyandong

    Greg Guest

    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
     
    Greg, Sep 20, 2005
    #16
  17. zhaoyandong

    David White Guest

    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
     
    David White, Sep 20, 2005
    #17
  18. zhaoyandong

    Jack Klein Guest

    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.
     
    Jack Klein, Sep 20, 2005
    #18
  19. zhaoyandong

    Ganesh Guest

    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
     
    Ganesh, Sep 20, 2005
    #19
  20. zhaoyandong

    Kai-Uwe Bux Guest

    (a) If you refer to something, please quote it. So here is a relevant part
    of our discussion:
    (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]

    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
     
    Kai-Uwe Bux, Sep 20, 2005
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.