为什么没有更多的Java软件本地编译？

Question

我意识到benefits字节码与本机代码（可移植性）。

但是说你总是知道你的代码将在x86架构上运行，为什么不编译为x86并获得性能优势呢？

请注意，我假设本机代码编译有性能提升。有些人回答说实际上可能没有任何收获对我来说是新闻......

Answer 1

因为性能提升（如果有的话）不值得麻烦。

此外，垃圾回收对性能非常重要。有可能JVM的GC比嵌入在已编译的可执行文件中的更好，比如使用GCJ。

及时编译甚至可以带来更好的性能，因为JIT在编译时有更多的信息可用于优化编译，而不是编译时的编译器。请参阅JIT上的维基百科页面。

Answer 2

“Solaris”是一种操作系统，而不是CPU架构。安装在实际机器上的JVM将编译为本机CPU指令。 Solaris可以是SPARC，x86或x86-64体系结构。

此外，JIT编译器可以根据您拥有的实际CPU系列进行特定于处理器的优化。例如，Intel CPU上的不同指令序列比AMD CPU上的指令序列更快，并且针对您的确切平台的JIT编译器可以利用这些信息来生成高度优化的代码。

Answer 3

字节码在Java虚拟机中运行， 为（例如）Solaris编译。它将像该操作系统一样进行优化。

在实际情况中，您会看到在运行时通常会看到Java代码具有相同或更好的性能，因为它构建了虚拟机的内存管理代码 - 这些代码将在不断发展和成熟多年。 / p>

构建JVM的好处不仅仅是可移植性 - 例如，每次发布新的JVM时，编译的字节码都会获得业务中最好的优化，算法改进等。另一方面，一旦你编译了C代码，那就是它。

Answer 4

因为使用Just-In-Time编译，所以可以获得微不足道的性能优势。

实际上，JIT实际上可以做得更快。

Answer 5

运行后，JIT已经将其编译为Solaris本机代码。如果您在上传目标站点之前进行编译，则无法获得任何其他好处。

Answer 6

您可能会，也可能不会获得绩效优势。但更有可能你会受到性能损失：静态编译不可能实现JIT优化，因此性能只会与编译器“蒙上眼睛”一样好（没有实际分析程序并相应地优化它，这就是像HotSpot这样的JIT编译器确实如此。

直观地说，廉价（资源方面）编译是多么令人惊讶，以及通过观察正在运行的程序可以自动优化多少。黑魔法，但对我们有好处： - ）

Answer 7

关于JITs的所有这些谈论都是大约七年过时的BTW。现在所关注的技术称为HotSpot，它不仅仅是一个JIT。

Answer 8

“为什么不编译x86”

因为那样你就无法利用它运行的特定cpu的特定功能。特别是，如果我们要将“compile for x86”读作“生成可以在386及其后代上运行的本机代码”，那么生成的代码就不能依赖于与mmx指令一样古老的代码。

因此，最终结果是您需要针对它将运行的每个确切体系结构进行编译（那些尚不存在的体系结构），并让安装程序选择要放置的可执行文件。或者，我听说intel C ++编译器将生成相同函数的多个版本，仅在使用的cpu功能上有所不同，并根据CPU报告的可用内容在运行时选择正确的版本。

另一方面，您可以将字节码视为“半编译”源，类似于本机编译器（除非要求）实际写入磁盘的中间格式。然后，运行时环境可以进行最终编译，确切地知道将使用哪种体系结构。这就是为什么一些C＃/ .net代码在一些基准测试中稍微优于某些cpu密集型任务上的c ++代码的原因。

字节码的“最终编译”还可以进行额外的优化假设（从静态编译角度来看）明显不安全*，如果以后发现这些假设错误，则重新编译。

Answer 9

我猜是因为JIT（及时）编译非常先进。