谁能量化C ++和Java之间的性能差异？ [英] Can anyone quantify performance differences between C++ and Java?

问题描述

Java最初在​​JIT之前很慢，但今天的性能非常接近C ++。我想知道是否有人在两种语言之间做了可衡量的性能比较？ 与C ++相比，Java在哪里不足？ Java为开发人员提供了许多生产力提升，因为他们可以更快地编写应用程序，因为垃圾学院，缺乏指针等等。应用程序，如Firefox，Webkit和Open例如，如果使用100％的Java编写，可能是因为2，但是开发人员仍然选择C / C ++来提高性能。有人可以证明Java不能像C ++那样在我提到的应用程序中执行得那么好。

让我只是补充说，许多应用程序工作还在进行中。在C ++中的一个原因。这不仅仅是一个主观的问题。具有较高抽象级别的语言通常会造成性能损失。如果这种惩罚不存在，我们都将使用更高级别的语言。与C ++相比，Java在哪里支付？具体。

解决方案

对于许多单独的代码结构，JIT编译器可以更快，因为它们可以利用代码的运行时分析。 / p>

例如，VonC在这个问题的答案中提到了所有对象的堆分配。这实际上不是真的：JIT可以在堆栈上分配对象，如果它可以通过转义分析证明对对象的引用不会超过堆栈框架。这样，编译器可以获得堆栈分配的性能优点，而程序员可以放心地假定GC堆分配的安全性。

类似地，Uri提到虚拟函数（在大多数非C ++语言中称为虚拟方法）。这是另一种情况，JIT编译器具有几乎从来不可用于提前（AOT）编译器的优点：JIT可以插入内联的廉价类型检查（解引用字比较），并且实际上内联虚拟方法调用if该特定呼叫站点恰巧是单形的（即实际类型在实践中总是相同的）。事实证明，直到 95％的所有虚拟方法调用在实践中是单态的，所以这可能是一个很大的胜利 - 这是一个很难为AOT编译器利用的胜利，因为运行时代码加载可能动态改变运行时特性。

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.

这篇关于谁能量化C ++和Java之间的性能差异？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！