为什么字节码可能比本机代码运行得更快？

Question

Java很慢。

这似乎不仅仅是一个“城市传奇”。由于延迟，您不将其用于实时编码，也不将其用于集群/并行计算。有成千上万的基准测试，特别是“ Java vs C＃vs C
++”。

http://benchmarksgame.alioth.debian.org/

根据以上站点，不仅Java性能几乎与C一样好（远远没有C），而且Scala和Clojure（两种在JVM上运行的功能语言）都具有比OCaml和Erlang更好的性能。

而且那里也有很多“ Java比X更快”。

因此，在某些情况下，Java似乎很快。有人可以解释为什么吗？

为什么在给定动态代码（Scala，Clojure）和垃圾回收的情况下，字节码为什么运行得比本地代码快？如果速度更快，仍然存在延迟，那怎么办呢？

这似乎是一个矛盾，有人可以阐明吗？

Answer 1

James Gosling在编程大师中解释了以下内容：

詹姆斯 ：好的。这些天，我们几乎总是在击败真正优秀的C和C
++编译器。当使用动态编译器时，当编译器在最后一刻正确运行时，您将获得两个好处。一是您确切知道要运行的芯片组。人们多次编译一段C代码时，必须将其编译为在通用x86架构上运行。您获得的二进制文件中几乎没有一个经过特别优化。您下载了Mozilla的最新副本，它几乎可以在任何英特尔架构CPU上运行。几乎有一个Linux二进制文件。它非常通用，并且是用GCC编译的，而GCC并不是很好的C编译器。

当HotSpot运行时，它确切知道您正在运行的芯片组。它确切知道缓存的工作方式。它确切知道内存层次结构是如何工作的。它确切地知道所有管线互锁在CPU中的工作方式。它知道该芯片具有哪些指令集扩展。它针对您正在使用的机器进行了优化。然后另一半是它实际上在运行时看到了该应用程序。它能够拥有知道哪些事情很重要的统计信息。它能够内联C编译器无法执行的操作。内联到Java世界中的东西真是太神奇了。然后，您可以确定存储管理与现代垃圾收集器一起工作的方式。使用现代垃圾收集器，存储分配非常快。