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

经过探索，

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

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

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

所以，用 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，在性能上有更大的优势？

谢谢

namelosw

2020-12-09 14:21:55 +08:00

取决于上下文有时候这两种都叫解释器, 特别是字节码再加进来就变得更乱了.

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

然后比较微妙的一点是, 纯解释脚本比编译出来的机器码慢很多, 是因为解释器里面直接用的是解释器语言的数据结构, 所以现代处理器的 cache 等等优化起不到作用, 进一步加大了这个差距. 这也是为什么某些不带 JIT 的字节码虚拟机, 在纯解释字节码的时候, 比不带字节码的解释器快很多, 且只比 C 慢一些的原因.

ipwx

2020-12-09 14:55:41 +08:00

这不就是昨天的那个帖子的楼主嘛。我昨天就写了你这个问题的答案，估计你没看见。
----

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

顺便补充一点，Java 编译成的是 JVM 字节码而不是本机代码； C# 编译成的是 .NET 字节码而不是本机代码。某种意义上这两种也是解释性语言 2333