4 ms·

Also C++ is generally as fast as C. If anything, it's faster thanks to increased opportunities for inlining. Whoever says C++ is slower than C is misinformed a

Also C++ is generally as fast as C. If anything, it's faster thanks to increased opportunities for inlining. Whoever says C++ is slower than C is misinformed and/or overgeneralizing. Professional C++ programmers know this already though.

raphaelj 11y ago
Don't forget about the templates too. A generic collection is usually faster when implemented using templates instead of void*.
- jakub_h 11y ago
  Unless you use a DataDraw-like approach, I presume. I can't see templates doing similar amounts of data rearrangements.
  - Kristine1975 11y ago
    You'd be surprised: http://bannalia.blogspot.de/2015/09/c-encapsulation-for-data-oriented.html http://bannalia.blogspot.de/2015/09/c-encapsulation-for-data...
    - jakub_h 11y ago
      Setting aside the cringe I experience whenever supposed principles of "OOP" are mentioned by the author, that page painfully reminds me of the that old joke about bolting four extra legs onto a dog... Furthermore, both a broader comparison (for more complex data and processing) and the technique I mentioned seems to be absent. However, I suppose it shows how to reclaim at least some benefits of better data arrangement even if the language isn't a good fit.
  - Rexxar 11y ago
    Did you speak of this "datadraw.sourceforge.net" ? It's the first time I heard of it. Have you used it ?
    - jakub_h 11y ago
      For a number of reasons, I'm not particularly fond of this specific implementation but I'm seriously considering porting its principles into something else (where they might work even better).
hellofunk 11y ago
Well, much of C++ involves virtual function calls, and those are indeed slower than non-virtual calls. C doesn't have virtual calls, so that is perhaps one reason why C is generally assumed to be faster. That doesn't mean you must use virtual functions in C++; in fact, I don't use inheritance in my own code whatsoever, therefore I avoid the virtual calls but more importantly the restrictions that can creep into a tight OO hierarchy. And std::function, from what I understand, is generally not as fast as a function pointer, a stored lambda, a function object, since it must do some run-time checks to see how to call what it is storing.
- mike_hock 11y ago
  The only virtual call that you necessarily get with polymorphism is the destructor call. Whenever you need to make a function virtual in C++, you'd need to store a function pointer in an equivalent C design, somehow.
  - hellofunk 11y ago
    Are you suggesting that C++ virtual functions have the same overhead as a C function pointer? I've never heard that; with the virtual call, there is the lookup + the invocation; perhaps a C app that stores function pointers in a hash map also has this sort of lookup, is that what you mean?
    - mikeash 11y ago
      Vtable lookup in a typical C++ implementation is just loading a fixed offset in an array. In C terms, it's basically doing object->vtable[42]. In C code with function pointers, you're typically performing that exact same operation. You can go slightly faster if you store the function pointer in the object directly, at the cost of increased memory consumption per object if you have more than one function pointer.
- kabdib 11y ago
  However, every sufficiently complex C program re-invents vtables (or has an even worse generic dispatching system), so you're often no worse off . . .
p0nce 11y ago
I'd even say it's generally faster because you can use integer as template arguments for enforced constant folding. Typically in video work: make a code path specialized when block width is 8, 16, 32 etc. Something that a C compiler can never do unless you use huge macros.
mikeash 11y ago
The only reason C++ has increased opportunities for inlining is because C++ often requires code to be placed in header files. If you wrote C in this style, you'd have the same opportunities for inlining, it's just that nobody writes it that way, because we generally prefer separately compiled libraries.

raphaelj 11y ago

Don't forget about the templates too. A generic collection is usually faster when implemented using templates instead of void*.

jakub_h 11y ago
Unless you use a DataDraw-like approach, I presume. I can't see templates doing similar amounts of data rearrangements.
- Kristine1975 11y ago
  You'd be surprised: http://bannalia.blogspot.de/2015/09/c-encapsulation-for-data-oriented.html http://bannalia.blogspot.de/2015/09/c-encapsulation-for-data...
  - jakub_h 11y ago
    Setting aside the cringe I experience whenever supposed principles of "OOP" are mentioned by the author, that page painfully reminds me of the that old joke about bolting four extra legs onto a dog... Furthermore, both a broader comparison (for more complex data and processing) and the technique I mentioned seems to be absent. However, I suppose it shows how to reclaim at least some benefits of better data arrangement even if the language isn't a good fit.
- Rexxar 11y ago
  Did you speak of this "datadraw.sourceforge.net" ? It's the first time I heard of it. Have you used it ?
  - jakub_h 11y ago
    For a number of reasons, I'm not particularly fond of this specific implementation but I'm seriously considering porting its principles into something else (where they might work even better).

hellofunk 11y ago

Well, much of C++ involves virtual function calls, and those are indeed slower than non-virtual calls. C doesn't have virtual calls, so that is perhaps one reason why C is generally assumed to be faster. That doesn't mean you must use virtual functions in C++; in fact, I don't use inheritance in my own code whatsoever, therefore I avoid the virtual calls but more importantly the restrictions that can creep into a tight OO hierarchy. And std::function, from what I understand, is generally not as fast as a function pointer, a stored lambda, a function object, since it must do some run-time checks to see how to call what it is storing.

mike_hock 11y ago
The only virtual call that you necessarily get with polymorphism is the destructor call. Whenever you need to make a function virtual in C++, you'd need to store a function pointer in an equivalent C design, somehow.
- hellofunk 11y ago
  Are you suggesting that C++ virtual functions have the same overhead as a C function pointer? I've never heard that; with the virtual call, there is the lookup + the invocation; perhaps a C app that stores function pointers in a hash map also has this sort of lookup, is that what you mean?
  - mikeash 11y ago
    Vtable lookup in a typical C++ implementation is just loading a fixed offset in an array. In C terms, it's basically doing object->vtable[42]. In C code with function pointers, you're typically performing that exact same operation. You can go slightly faster if you store the function pointer in the object directly, at the cost of increased memory consumption per object if you have more than one function pointer.
kabdib 11y ago
However, every sufficiently complex C program re-invents vtables (or has an even worse generic dispatching system), so you're often no worse off . . .

p0nce 11y ago

I'd even say it's generally faster because you can use integer as template arguments for enforced constant folding. Typically in video work: make a code path specialized when block width is 8, 16, 32 etc. Something that a C compiler can never do unless you use huge macros.

mikeash 11y ago

The only reason C++ has increased opportunities for inlining is because C++ often requires code to be placed in header files. If you wrote C in this style, you'd have the same opportunities for inlining, it's just that nobody writes it that way, because we generally prefer separately compiled libraries.