为什么没有更多的 Java 软件本地编译？
我意识到字节码与本机代码的好处（可移植性） ）。
但是假设您始终知道您的代码将在 x86 架构上运行，为什么不针对 x86 进行编译并获得性能优势呢？
请注意，我假设本机代码编译会带来性能提升。有些人回答说实际上可能没有任何收获，这对我来说是新闻。
I realize the benefits of bytecode vs. native code (portability).
But say you always know that your code will run on a x86 architecture, why not then compile for x86 and get the performance benefit?
Note that I am assuming there is a performance gain to native code compilation. Some folks have answered that there could in fact be no gain which is news to me..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
因为性能提升（如果有的话）不值得这么麻烦。
此外，垃圾收集对于性能也非常重要。 JVM 的 GC 很可能比编译后的可执行文件中嵌入的 GC 更好，例如 GCJ 。
而且及时编译甚至可以带来更好的性能，因为与编译时的编译器相比，JIT 在运行时拥有更多可用于优化编译的信息。请参阅 JIT 上的维基百科页面。
Because the performance gain (if any) is not worth the trouble.
Also, garbage collection is very important for performance. Chances are that the GC of the JVM is better than the one embedded in the compiled executable, say with GCJ.
And just in time compilation can even result in better performance because the JIT has more information are run-time available to optimize the compilation than the compiler at compile-time. See the wikipedia page on JIT.
“Solaris”是一个操作系统，而不是CPU架构。实际机器上安装的 JVM 将编译为本机 CPU 指令。 Solaris 可以是 SPARC、x86 或 x86-64 架构。
此外，JIT 编译器可以根据您拥有的实际 CPU 系列进行特定于处理器的优化。例如，不同的指令序列在 Intel CPU 上比在 AMD CPU 上更快，并且适合您的平台的 JIT 编译器可以利用此信息来生成高度优化的代码。
"Solaris" is an operating system, not a CPU architecture. The JVM installed on the actual machine will compile to the native CPU instructions. Solaris could be SPARC, x86, or x86-64 architecture.
Also, the JIT compiler can make processor-specific optimisations depending on which actual CPU family you have. For example, different instruction sequences are faster on Intel CPUs than on AMD CPUs, and a JIT compiler for your exact platform can take advantage of this information to produce highly optimised code.
字节码在 Java 虚拟机中运行，该虚拟机是为（例如）Solaris 编译的。它将针对该操作系统进行优化。
在现实世界中，您经常会看到 Java 代码在运行时具有相同或更好的性能，这是由于在虚拟机代码上构建了诸如内存管理之类的内容 - 该代码将已经发展和成熟多年。
为 JVM 进行构建不仅仅具有可移植性，还有更多好处 - 例如，每次发布新的 JVM 时，您编译的字节码都会获得来自业内最佳技术的优化、算法改进等。另一方面，一旦编译了 C 代码，就完成了。
The bytecode runs in a Java Virtual Machine that is compiled for (example) Solaris. It will be optimised like heck for that operating system.
In real-world cases, you see often see equal or better performance from Java code at runtime, by virtue of building on the virtual machine's code for things like memory management - that code will have been evolving and maturing for years.
There's more benefits to building for the JVM than just portability - for example, every time a new JVM is released your compiled bytecode gets any optimisations, algorithmic improvements etc. that come from the best in the business. On the other hand, once you've compiled your C code, that's it.
因为通过即时编译，性能优势微乎其微。
事实上，很多事情 JIT 实际上可以做得更快。
Because with Just-In-Time compilation, there is trivial performance benefit.
Actually, many things JIT can actually do faster.
运行后它已经被 JIT 编译成 Solaris 本机代码。如果您在上传到目标站点之前对其进行编译，您将无法获得任何其他好处。
It's already will be compiled by JIT into Solaris native code, after run. You can't receive any other benefits if you compile it before uploading at target site.
您可能会也可能不会获得性能优势。但更有可能的是，您会受到性能损失：静态编译无法进行 JIT 优化，因此性能只能与编译器“蒙住眼睛”一样好（无需实际分析程序并相应地对其进行优化，这就是JIT 编译器（例如 HotSpot）就是如此）。
直观上令人惊讶的是，编译的成本（资源方面）是多么便宜，并且仅通过观察正在运行的程序就可以自动优化多少。黑魔法，但对我们有好处:-)
You may, or may not get a performance benefit. But more likely you would get a performance penalty: JIT optimization is not possible with static compilation, so the performance would be only as good as the compiler can make it "blindfolded" (without actually profiling the program and optimizing it accordingly, which is what JIT compilers such as HotSpot does).
It's intuitively quite surprising how cheap (resource-wise) compiling is, and how much can be automatically optimized by just observing the running program. Black magic, but good for us :-)
顺便说一句，所有关于 JIT 的讨论都已经过时了七年。现在涉及的技术称为HotSpot，它不仅仅是JIT。
All this talk of JITs is about seven years out of date BTW. The technology concerned now is called HotSpot and it isn't just a JIT.
“为什么不针对 x86 进行编译”
因为这样您就无法利用它所运行的特定 cpu 的特定功能。特别是，如果我们将“为 x86 编译”理解为“生成可以在 386 及其后代上运行的本机代码”，那么生成的代码甚至不能依赖于像 mmx 指令这样古老的东西。
因此，最终结果是您需要针对它将运行的每个确切架构进行编译（那些尚不存在的架构又如何），并让安装程序选择要安装的可执行文件。或者，我听说英特尔 C++ 编译器会生成同一函数的多个版本，仅在使用的 CPU 功能上有所不同，并根据 CPU 报告的可用功能在运行时选择正确的版本。
另一方面，您可以将字节码视为“半编译”源，类似于本机编译器（除非要求）实际上不会写入磁盘的中间格式。然后，运行时环境可以进行最终编译，确切地知道将使用什么架构。这就是为什么在不久前的一些基准测试中，某些 C#/.net 代码在某些 CPU 密集型任务上的性能可能略胜于 C++ 代码的原因。
字节码的“最终编译”还可以做出额外的优化假设（从静态编译的角度来看）明显不安全*，并且如果以后发现这些假设错误，则重新编译。
"why not then compile for x86"
Because then you can't take advantage of the specific features of the particular cpu it gets run on. In particular, if we are to read "compile for x86" as "produce native code that can run on a 386 and its descendants", then the resulting code can't rely on even something as old as the mmx instructions.
As such, the end result is that you need to compile for every exact architecture it'll run on (what about those that does not exist yet), and have the installer select which executable to put into place. Or, I hear the intel C++ compiler will produce several versions of the same function, differing only on cpu features used, and pick the right one at run-time based on what the CPU reports as available.
On the other hand, you can view bytecode as a "half-compiled" source, similar to an intermediate format a native compiler will (unless asked) not actually write to disk. The runtime environment can then do the final compilation, knowing exactly what architecture will be used. This is the given reason why some C#/.net code could slightly outperform c++ code on some cpu-intensive tasks in some benchmarks a while ago.
The "final compilation" of bytecode can also make additional optimalization assumptions that are (from a static compilation perspective) distinctly unsafe*, and just recompile if those assumptions are found wrong later.
我想是因为 JIT（及时）编译非常先进。
I guess because JIT (just in time) compilation is very advanced.