d c java 性能比较,谁能量化C ++和Java之间的性能差异？

Java was initially slow before the JIT but today performance is pretty close to C++. I want to know if someone has done measurable performance comparisons between the two languages? Where does Java fall short when compared to C++? Java provides many productivity gains to developers so they can write applications much quicker because of garbage college, lack of pointers, etc. Applications such as Firefox, Webkit and Open Office, for example, could be developed much more quickly and reliably if written in 100% Java, perhaps by a factor of 2, but developers still choose C/C++ for performance reasons. Can someone demonstrate where Java cannot be made to perform as well as C++ for applications like the ones that I mentioned.

Let me just add that much application work is still being done in C++ for a reason. This is meant to be more than a subjective questions. Languages with higher levels of abstraction frequently pay a performance penalty. We would all be programming in higher level languages if this penalty did not exist. Where does still Java pay in comparison to C++? Be specific.

解决方案

JIT compilers can be faster for many individual code constructs because they can take advantage of runtime profiling of code.

For example, VonC in his answer to this question mentions heap allocation for all objects. This is not actually true: the JIT can allocate objects on the stack if it can prove by escape analysis that references to the object will not outlive the stack frame. In this way, the compiler can get the performance benefit of stack allocation while the programmer can rest assured of the safety of assumed GC heap allocation.

Similarly, Uri mentions virtual functions (called virtual methods in most non-C++ languages). This is another case that JIT compilers have an advantage that is almost never available to ahead-of-time (AOT) compilers: the JIT can insert an inlined cheap type check (a dereferenced-word comparison) and actually inline a virtual method call if that particular call site happens to be monomorphic (i.e. the actual type is always the same in practice). It turns out that up to 95% of all virtual method calls are monomorphic in practice, so this can be quite a big win - and it's a win that is hard for AOT compilers to take advantage of, since runtime code loading may change runtime characteristics dynamically.