一尘不染

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

java

Java很慢。

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

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

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

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

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

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

这似乎是一个矛盾,有人可以阐明吗?


阅读 224

收藏
2020-12-03

共1个答案

一尘不染

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

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

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

2020-12-03