FastGaussQuadrature.jl
FastGaussQuadrature.jl copied to clipboard
JuliaApproximation
Extremely slow compilation time
On julia 0.6:
julia> @time gausslobatto(2);
7.649899 seconds (9.86 M allocations: 451.546 MiB, 4.05% gc time)
On 0.5 it is about 3.5 seconds. Some quick debugging with @code_warntype suggests the problem is in this method with the following return type as a result: Tuple{Union{Array{Complex{Float64},1}, Array{Float64,1}},Union{Array{Complex{Float64},1}, Array{Float64,1}}}
I'm guessing the issue is that eig called on a Matrix is not type stable.
This should be calling eig on a SymTridiagonal
Sent from my iPhone
On 5 Apr 2017, at 09:24, Fredrik Ekre [email protected] wrote:
On julia 0.6:
julia> @time gausslobatto(2); 7.649899 seconds (9.86 M allocations: 451.546 MiB, 4.05% gc time) On 0.5 it is about 3.5 seconds. Some quick debugging with @code_warntype suggests the problem is in this method with the following return type as a result: Tuple{Union{Array{Complex{Float64},1}, Array{Float64,1}},Union{Array{Complex{Float64},1}, Array{Float64,1}}}
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
I fixed the type stability, though it didn't improve the compilation time by much. But slow compilation is a known bug in the 0.6 betas.
Nice! Was about to push an update but you were faster :) Yea, the compilation time is still a problem. Digging a bit further:
julia> @time FastGaussQuadrature.JacobiAsy(101,1., 1.)
6.638096 seconds (5.96 M allocations: 270.349 MiB, 1.98% gc time)
Ah, given the other issue had been here for almost a year, I wasn't expecting it to be a race 😉
You’ll see in my code I needed to type assert ::Vector{Float64}, as cat wasn't type inferring correctly (in 0.5). There is also an unnecessary allocation, so a better solution may be
aa = Array{Float64}(n)
aa[1] = (b - a)/(2 + ab)
view(aa,2:n-1) .= (b^2 - a^2)./((abi - 2).*abi)
aa[end] = (b^2 - a^2)./((2*n - 2+ab).*(2*n+ab))
If you are looking into it further, I'll leave it to you to try that change.
Yea, I did it with a for-loop instead. I will try to fix some more later and make a PR if I can improve the compilation time
On 0.7.
julia> @time FastGaussQuadrature.JacobiAsy(101,1., 1.)
28.552633 seconds (61.87 M allocations: 2.746 GiB, 4.82% gc time)
Going deeper
julia> @time FastGaussQuadrature.asy1(101, 1.0, 1.0, 10)
26.084398 seconds (55.88 M allocations: 2.453 GiB, 4.57% gc time)
This is compile time right? Is it really an issue with this package, or with Julia’s compiler?
Yes, compile time; just posting an update. Seems the code here is written in a way that interacts badly with the compiler but yeah, indeed an issue with the compiler.
I think the large dotted expressions is a problem for the compiler. A workaround might be to not use the @. macro so much and use normal operators between scalars and only dot operators between arrays.
I also noticed a big increase in compilation time going from Julia 0.6 to Julia 0.7. Is there any remedy ahead?
Current master branch on Julia 1.5:
julia> using FastGaussQuadrature
julia> t = time(); gausslobatto(2); time() - t
7.010434865951538
julia> using FastGaussQuadrature
julia> t=time(); FastGaussQuadrature.jacobi_asy(101,1., 1.); time() - t
5.734845161437988
Not as much compilation time as on Julia 0.7, but there may be still a problem.
Note KristofferC seemed to think the issue is the large broadcasted line
https://github.com/JuliaApproximation/FastGaussQuadrature.jl/blob/5506f5fde7c7f3098c1007140af6eb8105c0f5ec/src/gaussjacobi.jl#L205
probably this whole function should be de-MATLABed so it doesn't allocate so much