Comment by jey | Hacker News Reader

Comment by jey | Hacker News Reader

Parent Full thread

No, C++ is not slower than C. Both C and C++ are effectively macro assembler languages, and if you know what the 'macro' expands to, you can gauge the performance. You could implement everything that's in C++ using just pure C and get the same effect, but I surely do not want to manually lay out my vtables nor do I want to replace my C++ templates with C preprocessor macros. :-)

It should also be no surprise that Java, with its runtime dynamic optimization, is able to more strongly optimize code based on runtime performance characteristics than compile time optimizations performed by traditional C and C++ compilers. This is just a guess, but it's also possible that the Java JIT compiler is able to more aggressively optimize the generated code by having more insight into pointer aliasing, whereas you'd need to do whole program compilation to get the same effect with C++. (Plug: LLVM can do whole program compilation. http://www.llvm.org )

As tx said in a sibling post: Because good (performance-minded) C++ programmer has very good idea what kind of assembly instructions his code will turn to. This is why performance-critical code is still written in C++.

LLVM is outstanding, but little known. One example, a C program that uses a malloc-per-node linked list implementation might be compiled into an executable that uses an array, saving the space occupied by the pointers, and improving locality, because LLVM can analyse the whole program.

http://llvm.org/pubs/2005-06-12-MSP-PointerComp.html

http://llvm.org/pubs/2005-05-21-PLDI-PoolAlloc.html

Yeah, everyone please go contribute code to LLVM! LLVM is very pleasant to hack on with a genuinely clean design, unlike GCC, which is just a big nasty mess. Hacking on LLVM is fun, hacking on GCC is a chore.

"Reload is the GCC equivalent of Satan." http://gcc.gnu.org/wiki/reload

GCC's internal garbage collector. Yes, they really wrote a garbage collector for a C app, and dealing with it is just as pleasant as you'd imagine. http://gcc.gnu.org/wiki/Memory_management

Yes, C++ is unquestionably slower than C when you use it to the full potential and when you program the C++ way! A lot of people still program in C++ using the C style. I've used C++ for 7 yeas and have plenty of experience with it and I've seen its slowness in many instances. Main thing to avoid with C++ is virtual methods. Once you understand how they're implemented, you will understand why (hint: vtables).

No offense, but did you carefully read what Jay said? C and C++ is essentially same language, extended with OO+templates. And you can implement virtual method call in C as well.

I would even argue that C++ is faster than C because latest compiler optimization techniques and modern approach to templatized designs yield very impressive performance not typical for ligher-level languages.

The biggest issue with C++ (as a language) in my opinion is it's total lack of modules. In the end, everything needs to be included into every cpp file.

Speed is certainly not an issue. The only language that gets a chance of beating C/C++ is probably OCaml since it gives more information about your intentions to an optimizer/code generator.

I agree with tx. With C++ you can often avoid what would be virtual method calls in Java / if statements in C by using templates. This lets you effectively inline every function call. It'd be hard to do this in a clean way in C.

Main thing to avoid with C++ is virtual methods. Once you understand how they're implemented, you will understand why (hint: vtables).

Why? Are you concerned by the additional pointer dereference? In a tight loop (or other performance critical repetetive code), the vtables for all the derived types and the target piece of code would be sitting in cache already, and the code pointed to by the vtable entry would also be in cache. You have to fetch the object/class/struct instance that you're operating on regardless of whether or not it has a vtable, so that's an unavoidable cost. So I don't see how it's all that expensive. It's just a freaking pointer dereference. I do agree that it can matter in some instances, but I generally have a long list of things to improve before I would try to minimize pointer dereferences on vtables. If you really are having to optimize on such a low level, you'd probably do better to worry about cache hits/misses and data layout in-memory first.

A pointer dereference can make all the difference in an inner loop. As usual, the answer is to profile, then to optimize.

No other dogma really applies.

I don't think it's the pointer dereference so much as the fact that you can't inline virtual methods.

Reply on news.ycombinator.com