gpt4 book ai didi

julia - 由于类型不稳定导致性能差异?

转载 作者:行者123 更新时间:2023-12-02 09:32:19 24 4
gpt4 key购买 nike

我正在 Julia 0.4-prerelease 中尝试以下代码,它以两种不同的方式执行矩阵求幂(精确与级数展开)。我尝试使用多种方法来获取数组维度 n 和设置单位矩阵 eye( n )

function test()
A = [ 1.0 -1.0 ; -1.0 1.0 ]

lam, U = eig( A ) # diagonalization: A U = U diagm(lam)

Bref = U * diagm( exp(lam) ) * U' # Bref = exp(A) (in matrix sense)

#[ Get the dimension n ]
n = length( lam ) # slow (1a)
# const n = length( lam ) # slow (1b)
# n::Int = length( lam ) # fast (1c)
# const n::Int = length( lam ) # fast (1d)
# n = size( A, 1 ) # fast (1e)

#[ Set unit matrices to B and X ]
B = eye( n ); X = eye( n ) # slow with (1a) (2-1)
# B = eye( 2 ); X = eye( 2 ) # fast (2-2)
# B = eye( n::Int ); X = eye( n::Int ) # fast (2-3)
# B::Array{Float64,2} = eye( n ); X::Array{Float64,2} = eye( n ) # fast (2-4)
# B = eye( A ); X = eye( A ) # fast (2-5)

#[ Calc B = exp(A) with Taylor expansion ]
@time for k = 1:20
X[:,:] = X * A / float( k )
B[:,:] += X
end

#[ Check error ]
@show norm( B - Bref )
end

test()

在这里,我观察到,当 n 是动态变量(没有类型注释)时,代码变得比其他情况慢得多。例如,(1a) 和 (2-1) 的组合给出下面的“慢”结果,而其他组合给出“快”结果(快 1000 倍以上)。

slow case => elapsed time: 0.043822985 seconds (1 MB allocated)
fast case => elapsed time: 1.1702e-5 seconds (16 kB allocated)

这是因为 for 循环内部发生了“类型不稳定”吗?我很困惑,因为 eye( n ) 始终是 Array{Float64,2} (仅在初始化中使用)并且似乎没有(隐式)类型更改。同样令人困惑的是,(1e) 和 (2-1) 的组合速度很快,其中动态 n 是使用 size() 而不是 length() 设置的。总的来说,为了获得良好的性能,显式注释数组维度变量是否更好?

最佳答案

我认为差异主要在于编译时间。如果我再放两个 test() ,我会得到以下结果:

使用2-11a:

  73.599 milliseconds (70583 allocations: 3537 KB)
norm(B - Bref) = 4.485301019485633e-14
15.165 microseconds (200 allocations: 11840 bytes)
norm(B - Bref) = 4.485301019485633e-14
10.844 microseconds (200 allocations: 11840 bytes)
norm(B - Bref) = 4.485301019485633e-14

使用2-21a:

   8.662 microseconds (180 allocations: 11520 bytes)
norm(B - Bref) = 4.485301019485633e-14
7.968 microseconds (180 allocations: 11520 bytes)
norm(B - Bref) = 4.485301019485633e-14
7.654 microseconds (180 allocations: 11520 bytes)
norm(B - Bref) = 4.485301019485633e-14

编译时间的差异来自于编译的不同代码。这以及剩余的一些时间上的微小差异实际上来自类型的不稳定性。查看 1a 版本的 @code_warntype test() 的这一部分:

  GenSym(0) = (Base.LinAlg.__eig#214__)(GenSym(19),A::Array{Float64,2})::Tuple{Any,Any}
#s8 = 1
GenSym(22) = (Base.getfield)(GenSym(0),1)::Any
GenSym(23) = (Base.box)(Base.Int,(Base.add_int)(1,1)::Any)::Int64
lam = GenSym(22)
#s8 = GenSym(23)
GenSym(24) = (Base.getfield)(GenSym(0),2)::Any
GenSym(25) = (Base.box)(Base.Int,(Base.add_int)(2,1)::Any)::Int64
U = GenSym(24)
#s8 = GenSym(25) # line 7:
Bref = U * (Main.diagm)((Main.exp)(lam)::Any)::Any * (Main.ctranspose)(U)::Any::Any # line 9:
n = (Main.length)(lam)::Any # line 11:
B = (Main.eye)(n)::Any # line 11:
X = (Main.eye)(n)::Any # line 13: # util.jl, line 170:

我读到这是因为类型推断无法找出 eig 的返回类型。然后传播到 B 和 X。如果添加 n::Int,最后几行将更改为

  n = (top(typeassert))((top(convert))(Main.Int,(Main.length)(lam)::Any)::Any,Main.Int)::Int64 # line 11:
B = (Base.eye)(Base.Float64,n::Int64,n::Int64)::Array{Float64,2} # line 11:
X = (Base.eye)(Base.Float64,n::Int64,n::Int64)::Array{Float64,2} # line 13: # util.jl, line 170:

因此 BX 的输入正确。 An issue about this exact subject was raised recently - 如果您想获得最大性能,除了自己注释之外,似乎没有太多选择。

关于julia - 由于类型不稳定导致性能差异?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31633153/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com