键入闭包列表的稳定性

Question

我正在尝试在Julia中设计一些代码，它将获取用户提供的函数列表，并基本上对它们应用一些代数运算。

如果它们是闭包，那么这个函数列表的返回值似乎不会被推断，导致根据@code_warntype的类型不稳定的代码。

我尝试提供带闭包的返回类型，但似乎无法找到正确的语法。

这是一个例子：

functions = Function[x -> x]

function f(u)
    ret = zeros(eltype(u), length(u))

    for func in functions
        ret .+= func(u)
    end

    ret
end

运行这个：

u0 = [1.0, 2.0, 3.0]
@code_warntype f(u0)

并获得

Body::Array{Float64,1}
1 ─ %1  = (Base.arraylen)(u)::Int64
│   %2  = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Array{Float64,1}, svec(Any, Int64), :(:ccall), 2, Array{Float64,1}, :(%1), :(%1)))::Array{Float64,1}
│   %3  = invoke Base.fill!(%2::Array{Float64,1}, 0.0::Float64)::Array{Float64,1}
│   %4  = Main.functions::Any
│   %5  = (Base.iterate)(%4)::Any
│   %6  = (%5 === nothing)::Bool
│   %7  = (Base.not_int)(%6)::Bool
└──       goto #4 if not %7
2 ┄ %9  = φ (#1 => %5, #3 => %15)::Any
│   %10 = (Core.getfield)(%9, 1)::Any
│   %11 = (Core.getfield)(%9, 2)::Any
│   %12 = (%10)(u)::Any
│   %13 = (Base.broadcasted)(Main.:+, %3, %12)::Any
│         (Base.materialize!)(%3, %13)
│   %15 = (Base.iterate)(%4, %11)::Any
│   %16 = (%15 === nothing)::Bool
│   %17 = (Base.not_int)(%16)::Bool
└──       goto #4 if not %17
3 ─       goto #2
4 ┄       return %3

那么，我如何使这种代码类型稳定？

Answer 1

如果你想要任意函数的类型稳定性，你必须将它们作为元组传递，这允许julia事先知道哪个函数将应用于哪个阶段。

function fsequential(u, fs::Fs) where Fs<:Tuple
    ret = similar(u)
    fill!(ret, 0)
    return fsequential!(ret, u, fs...)
end

@inline function fsequential!(ret, u, f::F, fs...) where F
    ret .+= f(u)
    return fsequential!(ret, u, fs...)
end
fsequential!(ret, u) = ret

julia> u0 = [1.0, 2.0, 3.0]
3-element Array{Float64,1}:
 1.0
 2.0
 3.0

julia> fsequential(u0, (identity, x-> x .+ 1))
3-element Array{Float64,1}:
 3.0
 5.0
 7.0

如果你用@code_warntype检查它，你会发现它是可以推断的。

fsequential!是有时被称为“lispy元组编程”的示例，其中您一次迭代地处理一个参数，直到所有vararg参数都已用尽。它是一个强大的范例，它允许比带有数组的for循环更灵活的推理（因为它允许Julia为每个“循环迭代”编译单独的代码）。但是，它通常仅在容器中的元素数量相当小时才有用，否则最终会导致编译时间过长。

类型参数F和Fs看起来不必要，但它们旨在强制Julia专门为您传入的特定函数设置代码。

Answer 2

您的代码中存在多个层问题（不幸的是类型稳定性）：

1. functions是一个全局变量，所以从根本上说，你的代码不会是类型稳定的
2. 即使你在函数定义中移动functions并且它将是一个向量，代码仍然是类型不稳定的，因为容器将具有抽象eltype（即使你在Function之前删除了[前缀，如果你有多个不同的话，这仍然是正确的功能）
3. 如果你将一个向量更改为元组（那么集合functions将是类型稳定的），该函数仍然是类型不稳定的，因为你使用的循环无法在内部推断func(u)的返回类型

解决方案是使用@generated函数将循环展开为func(u)的连续应用程序序列 - 然后您的代码将是类型稳定的。

但是，总的来说，我认为，假设func(u)是一个昂贵的操作，你的代码中的类型不稳定应该不是很成问题，因为最后你将func(u)的返回值转换为Float64。

编辑一个@generated版本与Tim Holy提出的比较。

@generated function fgenerated(u, functions::Tuple{Vararg{Function}})
    expr = :(ret = zeros(eltype(u), size(u)))
    for fun in functions.parameters
        expr = :($expr; ret .+= $(fun.instance)(u))
    end
    return expr
end