Under what circumstances is Java much slower than C++?

Question: Under what circumstances is Java much slower than C++?

Answer: Ben Maurer:

In order to answer this question, we need to first divide the problem into several possible causes of slowness:

Garbage collector. This is a "double-edged sword." If your program follows the "most objects die in the young generation" model, the garbage collector is very beneficial (less fragmentation, better cache locality). However, if the program does not follow this model, the JVM will spend a lot of resources reclaiming heap memory.

　Large objects. In Java, all objects have a vtable pointer, while in C++ there is no additional overhead using the POD structure. In addition, all Java objects can be locked. Its implementation depends on the JVM, which may require adding additional fields to the object. Large objects == cache fewer objects == slower. (On the other hand, Java 7 records compressed pointers with 64 bits, which is part of the problem.

Lack of inline objects. In Java, all classes are pointers. In C++, objects can be Allocate other objects together, or on the stack. This can improve the locality of the cache, thereby reducing the overhead of dynamic memory allocation. In Java, JNI calls or compiling objects into local code will cause. Not a small overhead. If you need to call client C++ code frequently, it will add a lot of overhead. For example, if you want to write an XML parser in Java. , you only use String objects (without char[]), it will be slow because of the need to allocate additional space. Virtual function calls are increased. In JVM, almost all function calls are virtual function calls. Try to avoid virtual function calls, but in many cases, the JVM cannot solve this problem. This hinders the inlining of the code and makes the code slower. It lacks advanced compilation features and the ability to convert to assembly. Code that benefits from assembly may not perform well in Java

In my opinion, the biggest problem is garbage collection, which is the most common problem between Java and C++ when forcing multiple full GCs on large memory. One of the reasons for the gap between the two. In addition, if the working set of the program is placed outside the L2 cache, problems such as large objects and lack of inline objects will also lead to huge differences between the two. Inefficient forced abstractions and platform functions can also cause slowdowns, but this usually only occurs because of low-level code, which is usually not a big problem if you use a well-written Java code base. Todd Lipcon

I basically agree with Ben Maurer's (hey Ben!) answer with a few minor differences:

In the latest JVM, when this allocation is never done from (a) a local function or (b) a local. When a thread escapes, escape analysis can effectively determine a fixed allocation. That is, when the allocation does not require locking, it is usually performed on its own stack space. In both cases, it is a simple ". "Bump the pointer" allocation, which is equivalent to stack allocation in C.

Translator's Note:

Escape Analysis is a compilation optimization technology that refers to the method of analyzing the dynamic range of pointers. In layman's terms , when an object pointer is referenced by multiple methods or threads, we say that the pointer escapes.

Pointer collision (bump the point) Assume that the memory in the Java heap is absolutely regular, and all used memory is buffered. Put it on one side, the free memory is placed on the other side, and a pointer is placed in the middle as an indicator of the dividing point. The allocated memory is just to move the pointer to the free space by a distance equal to the size of the object. This This allocation method is called "pointer collision".

Even without escape analysis, the allocation of the young generation is done in the thread local allocation buffer (TLAB) through pointer collision, and no synchronization is required. Therefore, the allocation of small objects in Java is sometimes faster than the malloc() method implemented in C language. Better malloc methods like Google's tcmalloc take a similar approach. However, because the C language cannot reallocate allocated objects in memory, it is limited in some aspects.

Although there are problems with inlining and virtual functions, in fact, Java can even do better than C in some cases. In particular, C cannot implement inlining through dynamic linking because inlining is done at compile time, not run time. Java can dynamically inline a function across the boundaries of different classes or libraries, even if the actual implementation of the class is not available during compilation. In many jobs, this approach is more efficient than C++ virtual function calls, which always require calls to virtual tables. The JIT compiler, if previously dynamic attributes have been lost (such as a new class has been loaded), can intelligently cancel inline optimization.

The new version of GCC provides some optimizations in this area, called "whole-program optimization" or "link-time optimization", which allows inlining across object files within the project scope. However, it is basically not allowed to implement inlining through dynamic linking (such as calling zlib through inlining, etc.). Many large projects are implemented by copying the functionality of the standard library into their code.