Here's an interesting link: http://kano.net/javabench/
"JVM startup time was included in these results. That means even with JVM startup time, Java is still faster than C++ in many of these tests."
Here's an interesting link: http://kano.net/javabench/
"JVM startup time was included in these results. That means even with JVM startup time, Java is still faster than C++ in many of these tests."
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++.
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.
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.
No other dogma really applies.
"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
And by the way, why is it always Java guys who's playing with these benchmarks? Looks like an "inferiority syndrome" to me, C++ hackers just don't seem to care. Do you know why? 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++.
Yes, the choice of a C++ compiler does make some difference in algo heavy functions/methods but the art of writing high performance C++ programs has a lot more to do with overall design (which is sometimes C++ specific) and your programming style. I left C++ programming but if that's your cup of tea, look into Meyer's books. They're the best.
Java guys care because of Java's history: it was always slower than compiled languages and Java dev got a lot of crap for not having fast runtime. That's all history but there's still a ton of people out there who refuse to download Java-based programs because of 'slowness' myth.