JIT 为什么比 interpretation 快呢？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3723 天前的主题，其中的信息可能已经有所发展或是发生改变。

按道理都是在执行期分析代码并执行，所有JIT能用到的优化也可以用在解释器中吧？
有高手能科普一下吗？

看到Livid发的Pyston，引发了此问题。

jit

Pyston

Livid

16 条回复 • 2014-09-22 16:50:18 +08:00

chengdujin

2014-09-22 14:28:00 +08:00

JIT会编译部分代码，并对反复用到的代码段进行优化

shyrock

2014-09-22 14:30:53 +08:00

@chengdujin 我的问题是，这种优化不能在解释器中使用吗？

clino

2014-09-22 14:36:10 +08:00

@shyrock jit和解释执行不矛盾吧？jit版本一样也是解释执行吧？
我的理解是，加上jit会和平台相关，所以jit一般都是另外去做，而不会放在一个语言的官方发布版本里面

heiher

2014-09-22 14:59:04 +08:00

JIT编译后基本可以做到每个运算都有与之对应的机器码，而解释执行的话会有很多指令周期花在解释翻译上。当然编译也是要花时间的，所以不是什么代码都JIT的，像 mozilla js、v8等等都是分级的，越热的代码越一次花大量的时间编译优化，不热的代码就解释执行，这样可以做到启动和执行效率多不错。

shyrock

2014-09-22 15:07:12 +08:00

@clino 如果说jit的优势是根据运行期平台做特性优化，那么解释器为什么不能做呢？

shyrock

2014-09-22 15:08:52 +08:00

@heiher 如果说jit是执行快，但是牺牲了启动时间的话，似乎可以解释得通。那按这么说，只执行一次的话，jit比解释要慢？

clino

2014-09-22 15:10:55 +08:00

@shyrock 当然可以做啊，为什么不能做，只是这样做出来的解释器只能在某个平台上用，那如果有n个平台就要维护n份解释器，这个需要用钱去堆出来的吧

shyrock

2014-09-22 15:18:03 +08:00

@clino 成本是另一回事，如果你说的是‘不管成本的话，解释器和JIT能做到相当的性能’，那我就明白了。

clino

2014-09-22 15:18:51 +08:00

而且jit解释器可能会比不带jit的解释器bug更多，所以一般来说jit解释器出问题了可以找官方非jit解释器做对比，这样能知道是否是jit引入的，但如果都是jit可能就不好这样排除问题了

clino

2014-09-22 15:20:52 +08:00

@shyrock 应该说带jit的解释器和不带jit的解释器吧
我的理解是不带jit的是解释翻译成字节码然后字节码在虚拟机里运行
带jit的解释器是直接解释翻译成机器码执行

yyfearth

2014-09-22 15:24:38 +08:00

JIT 不一定比解析快但是如果是CPU繁重的工作那肯定是JIT会更快
JIT 本来就是要在编译+执行还是解析执行之间进行权衡
由于动态脚本编译时类型推测和优化都很费时间而且有可能编译后效果仍然不理想
所以在做大量优化和调试前很多JIT开发初期可能都比成熟的解析器要慢

@shyrock 对于只执行一次也不一定时谁快如果使用了大量的动态特性或者只是简单的执行一些指令那么解析执行可能会更占优势但是如果有CPU繁重的工作比如很多循环和计算那么编译后执行会快

不过我觉得现在还是AOT比较好发布的时候可以预编译成字节码然后下载安装的时候编译成本地代码执行

shyrock

2014-09-22 15:26:29 +08:00

@yyfearth 感觉有些明白了，谢谢。

ant_sz

2014-09-22 15:34:54 +08:00

解释器是解释执行的，一个表达式出来，解释器总是去先做字符串处理。如果是有字节码，也是先去分析字节码代表的含义，然后按照这个命令执行，距离机器更远一些。一条简单的加法指令，在解释器内可能要经过多条指令，而且每次遇到这个表达式需要这么多指令。

JIT 是每次运行到一个表达式之后，就把他编译成机器码，放在内存中，下次遇到这个表达式，直接把机器码送入CPU。一条简单的加法指令除第一次需要编译之外，之后就跟机器码的加法运算没什么大的差别。所以速度更快。

但是问题是 JIT 编译需要的时间比解释器长，代码运行的时间要比解释器更短。带 JIT 的编译器实现更复杂，维护成本更高。所以很多编程语言都要做 TradeOff。

那为什么要 JIT 而不是直接集中编译运行呢。首先，集中编译本身需要的时间就比较多，跨平台比较麻烦。如果想用一个二进制文件在多个平台上都可以跑很不方便，要分别编译然后打包在一起，导致可执行文件很臃肿。此外，JIT因为可以访问运行时环境，有些时候能做出比静态编译更好的优化。

所以总体来说 JIT 可以看做介于解释运行和编译运行之间的一种技术，是一种性能和跨平台能力之间的平衡。

另外，JIT 本身可以认为就是对单纯的解释器做出的优化。只集中编译热点代码也是考虑到JIT第一次编译需要一定的时间。当然现在还有 ART 技术，就是在安装程序的时候集中编译。

shyrock

2014-09-22 15:38:48 +08:00

@ant_sz 很完整很清晰，谢谢。

otakustay

2014-09-22 16:16:28 +08:00

还有一种情况，有些优化和执行的次数/频率有关，比如弱类型语言的类型推测，如果只运行一次，那做推测完全是多余的活，还不能保证第2次类型没变。但一段代码运行了1000次一个对象类型没变化过，那做一次类型推测后面再运行2000次就有收益

shyrock

2014-09-22 16:50:18 +08:00

@otakustay 是这个意思。