Python解释器可以优化哪些功能? [英] Which things can the Python interpreter optimize?

问题描述

我认为是由于惰性评估这样的陈述:

I think due to lazy evaluation statements like:

if True and True (...):
    # do something

...应立即由Python解释器跳过True and部分.但是，与已编译的代码相反，我认为Python解释器无法像显式布尔比较那样优化不良样式，对吧?

...should be skipped right after the True and part by the Python interpreter. However, in contrast to compiled Code, I think the Python interpreter can not optimize bad style like explicit boolean comparisions, right?

if condition == True:
    # do something

编译器会对此进行优化并删除== True部分，但是解释器始终必须评估在condition ==部分之后等待哪些语句，从而对每个== True进行不必要的比较代码执行时间?！

A compiler would optimize this and delete the == True part, but the interpreter always has to evaluate which statements wait after the condition == part, thus doing the unnecessary comparison of == True every time the code is executed?!

在解释器无法优化代码的地方，是否存在更多此类陷阱?我知道最后一个问题很开放，但是我想确实有一些受欢迎的例子吗?

Do more of such pitfalls exist, where the interpreter can not optimize code? I know this last question is quite open, but I guess some popular examples do exist?

推荐答案

本身本身编译不多(CPython确实可以编译为字节码)，但是这种语言的极强动态性阻碍了传统"优化的实现，而这种优化受不变性的指导使用Python进行编译时很难检查这些代码，因为该语言的语义使得大多数有关代码实际功能的信息仅在运行时可用.

It's not much compilation per se (CPython does compile to bytecode), but the extremely dynamic nature of the language hampers "traditional" optimizations, which are guided by invariants which are difficult to check at compile time in Python, because the semantics of the language is such that most information about what the code is actually supposed to do is only available at runtime.

您的if condition == True:示例是一个很好的例子:只有在编译器可以证明condition始终为布尔值的情况下，才能优化比较，如果它不是从当前文字中派生出来的，则这是不平凡的任务作用域-并且如果可以证明在运行时没有人设法用其他内容覆盖True(仅在Python 2 IIRC中才可能).

Your if condition == True: example is a good one: that comparison could be optimized only if the compiler could prove that condition is always a boolean, which is a non-trivial task if it derives from anything but literals in the current scope - and if it could prove that, at runtime, nobody managed to overwrite True with something else (possible only in Python 2 IIRC).

请记住，一些类型推断是可能的，实际上这就是Jedi之类的代码完成工具的工作方式.但是，绝地可以采取一些捷径并假设某种标准环境，而解释器则必须应对语言所允许的对全局变量的最奇怪的修改.

Mind you, some type inference is possible, and it's actually how code completion tools like Jedi work; however, Jedi can take some shortcuts and assume e.g. some kind of standard environment, while the interpreter has to cope with the most bizarre modifications to the globals that the language do allow.

因此，一般而言，CPython不会尽力优化任何东西-实际上，它似乎并没有进行任何智能"代码分析，AFAICT他们大多尝试构建一种有效的但大多是原始的"解释器.因此，期望几乎完全按照您编写的代码付费，没有优化程序可以保存草率的代码.

So, in general CPython does not try very hard to optimize anything - actually, it doesn't seem to do any kind of "smart" code analysis, AFAICT they mostly try to build an efficient but "mostly vanilla" interpreter. So, expect to pay almost exactly for what you write, there's no optimizer to save sloppy code.

顺便说一句，您的and示例不是解释器完成的优化，而是定义运算符语义的方式(并且非常重要的一点是，指定and和or进行短路评估，而不是可选的优化"，因为如果右操作数有副作用，它可能会改变程序的可观察行为).

By the way, your and example is not an optimization done by the interpreter, it's just how the semantic of the operator is defined (and it's quite crucial that it's specified that and and or do short circuit evaluation and it's not an optional "optimization", since it could alter the observable behavior of the program if the right hand operand had side effects).

动态语言 的一种更好的方法是跟踪JIT 的一种更好的方法-解释器让代码运行一段时间，并观察似乎不变的变量.保持良好状态(例如，condition似乎始终是布尔值，True始终是True，某些变量始终是整数，...)，然后使用此信息来编译机器码的优化版本代码.只要上面的不变量确实成立，就可以运行该命令-但是，一旦用于编译优化版本的前提之一被破坏，执行将返回到解释模式，并且跟踪再次开始以确定是否有新的优化版本可以建造.

A better approach for a language that dynamic is instead that of a tracing JIT - the interpreter lets the code run for a while, and observes the invariants that seem to hold well (for example, condition seems to always be a boolean, True is always True, some variable is always an integer, ...), and then uses this information to compile to machine code an optimized version of the code. This is let run as long as the invariants above do hold - but as soon as one of the premises used to compile the optimized version is broken, the execution goes back into interpreted mode, and tracing begins again to find out if a new optimized version can be built.

因此，使用常规的优化技术可以很好地优化典型情况，但是每当发生某种奇怪的事情(但语言允许)时，运行时就会退回到常规的文字"字节码解释中.

Thus, the typical case is optimized well, applying the usual optimization techniques, but whenever something bizarre (but allowed by the language) happens, the runtime can fallback to the regular "literal" bytecode interpretation.

这是用于从大多数动态语言中压缩性能的方法(大多数现代JavaScript引擎使用此基本方法的某些变体)，在PyPy中使用Python.

This is the approach used to squeeze good performance from most dynamic languages (most modern JavaScript engines use some variation of this basic approach), and in Python is used in PyPy.

这篇关于Python解释器可以优化哪些功能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！