V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
find456789
V2EX  ›  问与答

一门语言的编译器,可以由其他任何语言实现,那解释器呢?如果用 Python 这种性能差的语言写一门新的解释性语言,是不是性能就差了?

  •  1
     
  •   find456789 · 2020-12-09 14:05:17 +08:00 · 1281 次点击
    这是一个创建于 1445 天前的主题,其中的信息可能已经有所发展或是发生改变。

    经过探索,

    我大概知道了, 编译器是 把代码 翻译成 汇编,

    那么理论上 任何语言都行,

    因为生成的汇编代码, 是独立于语言的, 最后,执行程序,是直接执行 汇编代码的

    所以,用 c 和 python 同时开发一个编译器, 在编译程序的时候,python 会比 c 慢, 但编译完成 后, 执行 2 个目标程序, 性能应该是一样的,因为 2 个目标程序都是二进制的,和 原本的 c 、python 是无关的

    类比就是 请了 2 个翻译,把一篇英语文章,翻译成中文, 翻译员 c 翻译的快,翻译员 python 翻译的慢,但如果我是等他们翻译完毕才看, 那么,他们的翻译速度对我来说,并没有什么影响

    以上就是我对编译器的理解



    而解释器,就不一样了, 用 c 和 python 同时开发一门语言的解释器, 那么, 用 c 开发的解释器,速度应该更快,

    因为, 假设一段新语言的源代码, 同时传给 2 个 解释器(用 python 和 c 分别开发的解释器), 其工作原理如下:

    解释器用自身的代码,做词法分析,语法分析,生成 ast,然后用自身的代码调用自身的函数,就达到了解释的目的

    就好比用 python 写了一个解释器, 把一段代码传递给解释器后,解释器自身的逻辑是 python 写的,由于 python 自身有动态类型等特性,导致运行效率不如 c 这样的编译型语言效率高

    而,c 写的解释器,当收到传入的代码后,解释器自身用 c 语言分析传入的文本代码,那么速度自然比 python 所写的解释器快很多

    用 python 和 c 写解释器,本质和翻译也一样,不过这次是同声传译,即把英文文章实时翻译成中文,念给我听,c 翻译的快,我听得顺畅, python 翻译的慢,让我听的着急

    假设我以上的理解正确

    那么,如果我要实现一门解释性的脚本语言,类似 python 这种语言, 是否选择 c 这样的静态语言会比选 python,在性能上有更大的优势?

    谢谢

    12 条回复    2020-12-09 15:12:59 +08:00
    echo1937
        1
    echo1937  
       2020-12-09 14:07:14 +08:00
    这不是 Babel 吗
    find456789
        2
    find456789  
    OP
       2020-12-09 14:08:34 +08:00
    @echo1937

    我没有研究过 babel,好想是 js 里的东西
    kaneg
        3
    kaneg  
       2020-12-09 14:11:56 +08:00 via iPhone   ❤️ 1
    楼主理解得一点都没错。
    xpresslink
        4
    xpresslink  
       2020-12-09 14:19:05 +08:00   ❤️ 1
    还有一种叫 JIT 的东东,楼主可以了解一下,比如 Pypy
    namelosw
        5
    namelosw  
       2020-12-09 14:21:55 +08:00   ❤️ 1
    取决于上下文有时候这两种都叫解释器, 特别是字节码再加进来就变得更乱了.

    不过你理解的没错, 在 Python 的基础上再解释就会更慢了. 跟 SICP 最后一样, 用 Scheme 重新写一个 register machine, 然后再给这个 register machine 发明一个 Scheme 汇编, 然后再把 Scheme 编译回这个汇编上…… 最后慢成狗.

    然后比较微妙的一点是, 纯解释脚本比编译出来的机器码慢很多, 是因为解释器里面直接用的是解释器语言的数据结构, 所以现代处理器的 cache 等等优化起不到作用, 进一步加大了这个差距. 这也是为什么某些不带 JIT 的字节码虚拟机, 在纯解释字节码的时候, 比不带字节码的解释器快很多, 且只比 C 慢一些的原因.
    murmur
        6
    murmur  
       2020-12-09 14:23:49 +08:00   ❤️ 1
    性能差问题不大,当你的东西牛逼到一定程度,我可以堆硬件,如果还不行我就等,只要你节省的时间能弥补本身的速度不足
    ipwx
        7
    ipwx  
       2020-12-09 14:55:41 +08:00   ❤️ 1
    这不就是昨天的那个帖子的楼主嘛。我昨天就写了你这个问题的答案,估计你没看见。
    ----

    现代的完整解释型语言有 JIT 的。比如 V8,比如 JVM 和 .NET Runtime 。比如 PyPy 。JIT 的原理是在运行某个需要解释的程序时,动态的在后台把所用的程序段翻译成本机代码。而且 JIT 可以针对某种输入参数进行深度优化,有些时候可能比 C 语言写的程序还快。

    顺便补充一点,Java 编译成的是 JVM 字节码而不是本机代码; C# 编译成的是 .NET 字节码而不是本机代码。某种意义上这两种也是解释性语言 2333
    tabris17
        8
    tabris17  
       2020-12-09 14:57:13 +08:00
    跟这门语言的特性也有关,动态类型语言解释执行慢,可以通过 inline caching 之类的方式进行优化,但是 Python 并没有做到这种优化,另外就是 JIT 编译
    northisland
        9
    northisland  
       2020-12-09 15:01:44 +08:00   ❤️ 1
    看的不仔细,后面解释器不理解

    但让我想起《 llvm cookbook 》,llvm 可以把 python 编译成 IR 中间码,能做到 c 和 python 一视同仁。



    没有严格求证过,拍脑袋认为,python 解释器,就是一个边跑边生成机器码的 jvm 。。。
    chocovon
        11
    chocovon  
       2020-12-09 15:06:46 +08:00   ❤️ 1
    个人觉得如果想实现一门语言,先用自己最熟悉的语言(这里假定 LZ 并不熟练使用 C )将它快速实现出来,看看能不能满足你的需求,然后再考虑性能优化的事情也不迟。
    Jooooooooo
        12
    Jooooooooo  
       2020-12-09 15:12:59 +08:00
    可以 jit
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2662 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 03:27 · PVG 11:27 · LAX 19:27 · JFK 22:27
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.