V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
shyrock
V2EX  ›  程序员

JIT 为什么比 interpretation 快呢?

  •  
  •   shyrock · 2014-09-22 14:06:43 +08:00 · 4597 次点击
    这是一个创建于 3739 天前的主题,其中的信息可能已经有所发展或是发生改变。
    按道理都是在执行期分析代码并执行,所有JIT能用到的优化也可以用在解释器中吧?
    有高手能科普一下吗?

    看到Livid发的Pyston,引发了此问题。
    16 条回复    2014-09-22 16:50:18 +08:00
    chengdujin
        1
    chengdujin  
       2014-09-22 14:28:00 +08:00
    JIT会编译部分代码,并对反复用到的代码段进行优化
    shyrock
        2
    shyrock  
    OP
       2014-09-22 14:30:53 +08:00
    @chengdujin 我的问题是,这种优化不能在解释器中使用吗?
    clino
        3
    clino  
       2014-09-22 14:36:10 +08:00
    @shyrock jit和解释执行不矛盾吧?jit版本一样也是解释执行吧?
    我的理解是,加上jit会和平台相关,所以jit一般都是另外去做,而不会放在一个语言的官方发布版本里面
    heiher
        4
    heiher  
       2014-09-22 14:59:04 +08:00
    JIT编译后基本可以做到每个运算都有与之对应的机器码,而解释执行的话会有很多指令周期花在解释翻译上。当然编译也是要花时间的,所以不是什么代码都JIT的,像 mozilla js、v8等等都是分级的,越热的代码越一次花大量的时间编译优化,不热的代码就解释执行,这样可以做到启动和执行效率多不错。
    shyrock
        5
    shyrock  
    OP
       2014-09-22 15:07:12 +08:00
    @clino 如果说jit的优势是根据运行期平台做特性优化,那么解释器为什么不能做呢?
    shyrock
        6
    shyrock  
    OP
       2014-09-22 15:08:52 +08:00
    @heiher 如果说jit是执行快,但是牺牲了启动时间的话,似乎可以解释得通。那按这么说,只执行一次的话,jit比解释要慢?
    clino
        7
    clino  
       2014-09-22 15:10:55 +08:00
    @shyrock 当然可以做啊,为什么不能做,只是这样做出来的解释器只能在某个平台上用,那如果有n个平台就要维护n份解释器,这个需要用钱去堆出来的吧
    shyrock
        8
    shyrock  
    OP
       2014-09-22 15:18:03 +08:00
    @clino 成本是另一回事,如果你说的是‘不管成本的话,解释器和JIT能做到相当的性能’,那我就明白了。
    clino
        9
    clino  
       2014-09-22 15:18:51 +08:00
    而且jit解释器可能会比不带jit的解释器bug更多,所以一般来说jit解释器出问题了可以找官方非jit解释器做对比,这样能知道是否是jit引入的,但如果都是jit可能就不好这样排除问题了
    clino
        10
    clino  
       2014-09-22 15:20:52 +08:00   ❤️ 1
    @shyrock 应该说带jit的解释器和不带jit的解释器吧
    我的理解是不带jit的是解释翻译成字节码然后字节码在虚拟机里运行
    带jit的解释器是直接解释翻译成机器码执行
    yyfearth
        11
    yyfearth  
       2014-09-22 15:24:38 +08:00   ❤️ 1
    JIT 不一定比解析快 但是如果是CPU繁重的工作 那肯定是JIT会更快
    JIT 本来就是要在 编译+执行 还是 解析执行 之间进行权衡
    由于动态脚本编译时类型推测和优化都很费时间 而且有可能编译后效果仍然不理想
    所以在做大量优化和调试前 很多JIT开发初期 可能都比成熟的解析器要慢


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

    不过我觉得现在还是AOT比较好 发布的时候可以预编译成字节码 然后下载安装的时候 编译成本地代码执行
    shyrock
        12
    shyrock  
    OP
       2014-09-22 15:26:29 +08:00
    @yyfearth 感觉有些明白了,谢谢。
    ant_sz
        13
    ant_sz  
       2014-09-22 15:34:54 +08:00   ❤️ 2
    解释器是解释执行的,一个表达式出来,解释器总是去先做字符串处理。如果是有字节码,也是先去分析字节码代表的含义,然后按照这个命令执行,距离机器更远一些。一条简单的加法指令,在解释器内可能要经过多条指令,而且每次遇到这个表达式需要这么多指令。

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

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

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

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

    另外,JIT 本身可以认为就是对单纯的解释器做出的优化。只集中编译热点代码也是考虑到JIT第一次编译需要一定的时间。当然现在还有 ART 技术,就是在安装程序的时候集中编译。
    shyrock
        14
    shyrock  
    OP
       2014-09-22 15:38:48 +08:00
    @ant_sz 很完整很清晰,谢谢。
    otakustay
        15
    otakustay  
       2014-09-22 16:16:28 +08:00
    还有一种情况,有些优化和执行的次数/频率有关,比如弱类型语言的类型推测,如果只运行一次,那做推测完全是多余的活,还不能保证第2次类型没变。但一段代码运行了1000次一个对象类型没变化过,那做一次类型推测后面再运行2000次就有收益
    shyrock
        16
    shyrock  
    OP
       2014-09-22 16:50:18 +08:00
    @otakustay 是这个意思。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5151 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 09:40 · PVG 17:40 · LAX 01:40 · JFK 04:40
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.