为什么字节码可能比本机代码运行得更快 [英] Why is it that bytecode might run faster than native code
问题描述
Java运行缓慢.
这不仅仅是一个城市传奇"，这似乎是事实.由于延迟，您不将其用于实时编码，也不将其用于集群/并行计算.有成千上万的基准测试，特别是"Java vs C#vs C ++".
That's more than an "urban legend", it seems to be a fact. You don't use it for live-coding because of latency and you don't use it for clusters/parallel computing. There are thousands of benchmarks out there, specially "Java vs C# vs C++".
http://benchmarksgame.alioth.debian.org/
根据上述站点，不仅Java性能几乎与C一样好(远远没有C)，而且Scala和Clojure(两种在JVM上运行的功能语言)都具有比OCaml，Erlang更好的性能.
According to the above site, not only is Java performance almost as good as C (far from the rest), but Scala and Clojure (both functional languages which runs on the JVM) both have a better performance that OCaml, Erlang.
And there are a lot of "Java is faster then X" out there, also (for instance, a question here on SO: Java Runtime Performance Vs Native C / C++ Code?).
因此，在某些情况下，Java似乎很快.有人可以解释为什么吗?
So Java seems to be fast, for certain cases. Can someone explain why?
在给定动态代码(Scala，Clojure)和垃圾回收的情况下，为什么字节码运行速度可能比本地代码快?怎么会更快，仍然有延迟?
Why is it that bytecode might run faster then native code, in some cases, given dynamic code (Scala, Clojure) and garbage collection? How come if it is faster, there is still latency?
这似乎是一个矛盾，有人可以阐明吗?
It seems to be a contradiction here, can someone shed light?
推荐答案
詹姆斯·高斯林(James Gosling)在编程大师中解释道:
In the book masterminds for programming, James Gosling explained:
詹姆斯:是的.这些天我们 击败真正优秀的C和C ++ 编译器几乎总是如此.当你 转到动态编译器，您将获得 编译器的两个优势 在最后一刻运行.一 你确切知道什么芯片组吗 你在继续.这么多次 人们正在编译一块C 代码，他们必须对其进行编译才能运行 在普通的x86上 建筑学.几乎没有 你得到的二进制文件特别好 为其中任何一个进行了调整.您下载 Mozilla的最新副本，它将 几乎可以在任何英特尔上运行 体系结构CPU.有很多 一个Linux二进制文件.非常通用 它是由GCC编译的 不是一个很好的C编译器.
James: Exactly. These days we’re beating the really good C and C++ compilers pretty much always. When you go to the dynamic compiler, you get two advantages when the compiler’s running right at the last moment. One is you know exactly what chipset you’re running on. So many times when people are compiling a piece of C code, they have to compile it to run on kind of the generic x86 architecture. Almost none of the binaries you get are particularly well tuned for any of them. You download the latest copy of Mozilla,and it’ll run on pretty much any Intel architecture CPU. There’s pretty much one Linux binary. It’s pretty generic, and it’s compiled with GCC, which is not a very good C compiler.
运行HotSpot时，它确切知道 您正在使用哪种芯片组.它 确切知道缓存的工作方式.它 确切知道内存层次结构 作品.它确切地知道所有 管道互锁在CPU中工作. 它知道什么指令集 该芯片具有的扩展.它 精确地针对什么机器进行优化 轮到你了.然后另一半 是它实际上看到了 运行中的应用程序.可以 拥有知道哪个的统计信息 事情很重要.它能够 内联C编译器可以执行的操作 永远不会做.得到的东西 内联在Java世界中很漂亮 惊人的.然后，你坚持 存储管理的工作方式 现代垃圾收集器.用 现代垃圾收集器，存储 分配非常快.
When HotSpot runs, it knows exactly what chipset you’re running on. It knows exactly how the cache works. It knows exactly how the memory hierarchy works. It knows exactly how all the pipeline interlocks work in the CPU. It knows what instruction set extensions this chip has got. It optimizes for precisely what machine you’re on. Then the other half of it is that it actually sees the application as it’s running. It’s able to have statistics that know which things are important. It’s able to inline things that a C compiler could never do. The kind of stuff that gets inlined in the Java world is pretty amazing. Then you tack onto that the way the storage management works with the modern garbage collectors. With a modern garbage collector, storage allocation is extremely fast.
这篇关于为什么字节码可能比本机代码运行得更快的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
