Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow statically typed variables #71

Open
cscherrer opened this issue May 29, 2022 · 3 comments
Open

Allow statically typed variables #71

cscherrer opened this issue May 29, 2022 · 3 comments

Comments

@cscherrer
Copy link
Collaborator

cscherrer commented May 29, 2022

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,

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):

function abmult2(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?

This is related to cscherrer/Soss.jl#337

@cscherrer
Copy link
Collaborator Author

I made a simple change to play with this in
https://github.com/JuliaStaging/GeneralizedGenerated.jl/tree/unboxed

It's just for exploration, from from some quick tests it seems to work well for my use case. I'll use this for development until there's a better fix

@thautwarm
Copy link
Member

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.

@cscherrer
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants