口译员：简化到什么程度？答案

【问题标题】：Interpreters: How much simplification?口译员：简化到什么程度？
【发布时间】：2010-05-12 19:29:10
【问题描述】：

在我的解释器中，代码如下

x=(y+4)*z
echo x

解析和“优化”解释器执行的四个单一操作，几乎类似于汇编：

add 4 to y
multiply <last operation result> with z
set x to <last operation result>
echo x

在现代解释器（例如：CPython、Ruby、PHP）中，最终由解释器运行的“操作码”的简化程度如何？
尝试使解释器的结构和命令更复杂和更高级时，我能否获得更好的性能？那肯定会更难，或者？

【问题讨论】：

标签： interpreter

【解决方案1】：

在 Python 的情况下，您可以让它告诉您带有 dis 模块的给定函数的字节码。

from dis import dis
def foo():
    x=(y+4)*z
    print x

dis(foo)

给你：

2           0 LOAD_GLOBAL              0 (y)
            3 LOAD_CONST               1 (4)
            6 BINARY_ADD          
            7 LOAD_GLOBAL              1 (z)
           10 BINARY_MULTIPLY     
           11 STORE_FAST               0 (x)

3          14 LOAD_FAST                0 (x)
           17 PRINT_ITEM          
           18 PRINT_NEWLINE       
           19 LOAD_CONST               0 (None)
           22 RETURN_VALUE

其中一些是无关的（例如，末尾的 LOAD_CONST 和 RETURN_VALUE 用于 foo() 中的隐式 return None），但 Python 似乎将 y 和 4 压入堆栈、加法、压入 z、乘法和写信给 x。然后它推动 x 并打印

【讨论】：

非常有趣，感谢您的回复。我不知道 Python 的函数和方式：)

【解决方案2】：

关于最后一个结果：实际上，您创建了一个带有一个寄存器的register machine：“最后一个操作结果”。这阻碍了并行性。
Eval/assign 类型的操作码通常比你的低一层。看看Python opcodes。
更高级别的命令可以产生更高的性能，因为它们可以让您在（希望如此）快速解释器中花费更多时间。但它们也可能很痛苦，因为您需要另一个高级操作码来完成这个和那个。

试试看 :) 这真的取决于你没有提供的许多因素（而且领域和任务是如此巨大，如果你提供了足够的因素，它们将包含一些明显的答案）。其中一个主要因素是您是否（以及如何）实现某些语言功能（或者换句话说，如果您要使这些东西成为一流的），例如：

结构化编程。我的意思是，操作码会包含“函数调用”、“带有 N 个参数的函数调用”的概念，还是会是盲目的推送、推送、推送、调用、ret 序列。
lambdas（特别是 - 函数体，在其他函数中定义）。这将做出closure 的决定：函数是否应该“捕获”外部范围的变量，如果是，如何。

【讨论】：

【解决方案3】：

尝试对操作码进行建模，就像它们模仿解释器的内部工作方式一样。 This page 有一篇关于 .NET 如何从正则表达式生成解释语言的文章。在 .NET 中，正则表达式首先被编译为中间语言。然后将解释该中间代码。中间代码看起来很像特定的，呃，正则表达式引擎的内部数据结构。

【讨论】：

【解决方案4】：

经验法则：如果您的字节码中有重复的模式（例如，每个 GC 控制的堆分配都有一个通用模式），那么每个模式都应该有一个特殊的高级操作。

无论如何，如今，有了所有可用的 .NET、JVM、LLVM 东西，如果您真的对解释器的性能感兴趣，那么插入合适的 JIT 编译器真的很便宜也很容易。

【讨论】：