JIT编译器与离线编译器

是否存在JIT编译器比其他编译器(如C++)更快的情况？

您认为将来JIT编译器只会看到次要的优化,功能但是会遵循类似的性能,还是会有突破性的优势使其无限优于其他编译器？

看起来多核心范式有一些希望,但它不是普遍的魔力.

任何见解？

1> Craig Stuntz..：

---

是的,肯定有这样的场景.

JIT编译可以使用运行时分析来根据当前代码实际执行的特性的度量来优化特定情况,并且可以根据需要重新编译"热"代码.那不是理论上的; Java的HotSpot实际上是这样做的.

JITters可以针对程序正在执行的实际硬件上的特定CPU和内存配置进行优化.例如,许多.NET应用程序将以32位或64位代码运行,具体取决于它们的JIT位置.在64位硬件上,它们将使用更多寄存器,存储器和更好的指令集.

基于对引用类型的运行时知识,可以使用静态调用替换紧密循环内的虚方法调用.

我认为未来会有突破.特别是,我认为JIT编译和动态类型的组合将得到显着改善.我们已经在Chrome的V8和TraceMonkey的JavaScript空间中看到了这一点.我预计在不久的将来会看到类似幅度的其他改进.这很重要,因为即使是所谓的"静态类型"语言也往往具有许多动态特性.

---

正如我在帖子中明确指出的那样,HotSpot实际上进行了动态的,配置文件引导的重新编译,而.NET实际上进行了CPU特定的编译.我怀疑是否会影响启动速度一点(考虑一下).虚拟通话优化？看看V8.我同意两者都有优势.

---

JIT编译器不仅可以根据运行时观察所使用的代码来优化代码,还可以使用更积极("危险")的优化,因为当优化假设不再存在时,它可以通过丢弃编译的代码来优化代码.有效.Hotspot就是这么做的.

---

你只提到JIT编译器*可以*做什么,而不是它实际做什么.JIT'ing通常受限于必须快速.离线编译器可以花很长时间来优化代码,但JIT编译器最多只能在一两秒内完成.所以两者都有其优点.

---

虚拟方法调用不仅可以基于运行时特性替换为静态调用,还可以基于相同的运行时特性进行内联.

2> Bahaa Zaid..：

---

是的,JIT编译器可以生成针对当前环境优化的更快的机器代码.但实际上VM程序比Native程序慢,因为JITing本身消耗时间(更多优化==更多时间),对于许多方法,JITing它们可能比执行它们花费更多时间.这就是GAC在.NET中引入的原因

JITing的副作用是大量内存消耗.但是,这与计算速度无关,它可能会降低整个程序的执行速度,因为大量内存消耗会增加将代码分页到辅助存储的可能性.

对不起,我的英语不好.

---

@Bahaa:不,gacutil用于向GAC添加程序集.NGEN用于将程序集添加到本机映像缓存中.

---

GAC =全局汇编缓存http://en.wikipedia.org/wiki/Global_Assembly_Cache ngen是用于向其添加程序集的工具

3> David Thornl..：

---

JIT有优势,但我认为它没有完全接管.传统的编译器可以花费更多的时间进行优化,而JIT需要在过多的优化(花费的时间比优化节省的时间)和太少(在直接执行中花费太多时间)之间取得平衡.

显而易见的答案是使用每个优越的地方.JIT可以比传统优化器更容易地利用运行时分析(虽然有些编译器可以将运行时配置文件作为输入来指导优化),并且通常可以承担更多特定于CPU的优化(同样,许多常规优化)编译器执行此操作,但如果您希望在不同系统上运行可执行文件,则无法充分利用它.传统的编译器可以花费更多的时间,并以不同的方式进行.

因此,未来的语言系统将拥有良好的优化编译器,它们将发出专为优化JIT编译器而设计的可执行代码.(对于许多人来说,这也是现在的语言系统.)(未来的语言系统也将支持从现代Python/VB脚本到最丑陋的高速数字运算的所有内容.)

与许多事情一样,Lisp预示着这一点.很久以前,一些Lisp系统(实际上并不是很多,没有那么多Common Lisp实现)通过动态编译来解释Lisp函数.Lisp S表达式(编写的代码)是对解析树的相当直接的描述,因此编译可以非常快.与此同时,优化的Lisp编译器可能会破坏性能非常重要的代码.