interpreter - 是什么让字节码解释器比 ast-walking 解释器更快?

标签 interpreter bytecode

就目前而言,这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持,但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开,visit the help center为指导。




8年前关闭。




我确实理解这两种设计背后的技术概念,但是是什么让字节码解释器通常更快?有什么好书,谁能指点一下?

最佳答案

最明显的原因是 AST 通常仍然太高级,而字节码语义对于执行来说可能是微不足道的。 AST-walking 解释器中最慢的事情通常是上下文查找:所有变量、参数等都通过它们的名称引用,而在字节码中,它们通常会被剥离,而将使用寄存器编号或堆栈操作来代替。

当然,字节码可以被认为是 AST 遍历的一个特例——具有扁平、简单的“AST”,可能还有优化的“walker”(例如,使用线程代码转换)。在临时 AST 和高度特化的字节码之间有许多可能的状态——例如,为了解释一种函数式语言,可以保留 AST 结构,但用 De Bruijn 索引替换变量名称。

关于interpreter - 是什么让字节码解释器比 ast-walking 解释器更快?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9863236/

相关文章:

java - 从内存中检索字节码以防止黑客攻击

compiler-construction - 为什么在实践中解释器比编译器要慢?

php - 在 PHP 中显示已处理的脚本计算步骤

scala - 如何将外部库添加到 Scala 解释器的类路径中?

c - 尝试掌握 C 字节码...GNU/gcc 是否/可以像 Clang/LLVM 一样生成 C 字节码?

java - 汇编 : Stateful Transformation

javascript - 为什么某些 JavaScript 语句开头的 "word:"不会抛出语法错误?

c++ - 如何使用 C++ 或其他一些 PL 构建 C 解释器

Java:使用 BCEL 添加调试调用到每个方法

java - 为什么Byte Buddy缺少与操作码ASTORE对应的StackManipulation实现?