You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If captured variables are used in a performance-critical section of the code, then the following tips help ensure that their use is performant. First, if it is known that a captured variable does not change its type, then this can be declared explicitly with a type annotation (on the variable, not the right-hand side):
functionabmult2(r0::Int)
r::Int= r0
if r <0
r =-r
end
f = x -> x * r
return f
end
Annotations like r::Int = r0 sometimes lead to problems if GG also decides to box that variable. Could a type declaration like this be taken by GG as an assertion that the variable is unboxed?
Removing boxing means the free variables are immutable. I think you could just change push!(block, :($name = Core.Box($name))) to push!(block, :($name = $Ref($name))), it will be as performant if the free variable is set when being captured.
Just to be sure I'm understanding, when you say "Removing boxing means the free variables are immutable"... Does this mean variables that are assigned in one scope and then passed to an "inner" scope?
Aside from performance, I was having the problem that the boxing was "leaking" - My generated code included the boxing, so some of my code broke. I'd think Refs might have the same issue, not sure yet
The Julia docs recommend that in some cases, variables can be type-annotated (LHS, not RHS). The section
https://docs.julialang.org/en/v1/manual/performance-tips/#man-performance-captured
says,
Annotations like
r::Int = r0
sometimes lead to problems if GG also decides to box that variable. Could a type declaration like this be taken by GG as an assertion that the variable is unboxed?This is related to cscherrer/Soss.jl#337
The text was updated successfully, but these errors were encountered: