Julia vs Python 编译器/解释器优化

Posted 2023-02-16

【中文标题】Julia vs Python 编译器/解释器优化

【英文标题】：Julia vs Python compiler/interpreter optimization

【发布时间】：2014-08-11 17:10:00

【问题描述】：

我最近问了以下关于 Python 的问题： Interpreter optimization in Python

假设我在 x 中有一个字符串，Python 解释器是否足够聪明 知道：string.replace(x, x) 应该转换为NOP？

答案似乎是否定的（尽管 Python 解释器能够通过窥视孔优化器执行 some optimizations）。

我不知道 Julia 中的等效表达式是什么，但 Julia 是否能够优化这些相对明显的类型 声明？

【问题讨论】：

我认为答案是“有时”，因为它会传播常量并消除死代码。没有更具体的情况很难回答，因为在某些情况下很难为编译器推断（尽管它可能比 Python 更容易）

【参考方案1】：

依赖编译器

问题是 Julia 能否为 LLVM 提供足够的信息，以便编译器可以优化？

从您的示例中可以，您可以使用 code_native 进行验证。例如，答案是预乘的，对 x 的不必要赋值被优化掉，函数总是返回一个常量

julia> f()=(x=7*24*60*60)
f (generic function with 1 method)

julia> code_native(f,())
    .section    __TEXT,__text,regular,pure_instructions
Filename: none
Source line: 1
    push RBP
    mov  RBP, RSP
    mov  EAX, 604800
Source line: 1
    pop RBP
    ret

打字优化

有时它可以走得更远，因为可以从类型信息中获得更多知识。相反，如果可能，应避免使用 Any 类型和全局变量。

示例

在情况 I 中，需要进行比较，因为 y 可能大于 256，但在第二种情况下，由于它只有 1 个字节，它的值不能大于 256，并且函数将被优化为始终返回1.

案例一

julia> g(y::Int16)=(y<256?1:0)
g (generic function with 1 method)

julia> code_native(g,(Int16,))
    .section    __TEXT,__text,regular,pure_instructions
Filename: none
Source line: 1
    push RBP
    mov  RBP, RSP
    cmp  DI, 256
Source line: 1 
    setl  AL
    movzx EAX, AL
    pop   RBP
    ret

案例二

julia> g(y::Int8)=(y<256?1:0)
g (generic function with 2 methods)

julia> code_native(g,(Int8,))
    .section    __TEXT,__text,regular,pure_instructions
Filename: none
    Source line: 1
    push RBP
    mov  RBP, RSP
    mov  EAX, 1
Source line: 1
    pop  RBP
    ret