-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Bump MAX_TYPE_DEPTH #10230
Bump MAX_TYPE_DEPTH #10230
Conversation
@timholy, any idea why this breaks the subarray tests? |
This seems to be related to staged functions getting invoked on approximate types. There's a good chance we should just not do that. For one thing, we haven't yet taken steps to ensure monotonicity. For example, I tested this by adding
to |
IIRC @Keno had argued that this is useful. I also think it's fishy to invoke staged functions on approximate types. |
Admittedly, I haven't yet found a specific use case for staged functions on approximate types. The basic area where I could see it being useful is to generate code for say an array where you know the number of dimensions, but not the type. Might also help with some of the concerns around staged functions in static compilation. I'm fine with disallowing this use case until somebody finds a concrete one though (easier going this way than the other). |
Unfortunately I already found a problem with this plan. Some functions do not use the types of some arguments. E.g. |
Is this an example of the issue you're talking about, Jeff? julia> stagedfunction f(A, idxs...)
quote
R = sub(A, idxs...)
println(ndims(R), "-dim ", typeof(R))
R
end
end
f (generic function with 1 method)
julia> A = reshape(1:32,2,2,2,2,2);
julia> f(A, 1:2, :, :, :, 1)
2-dim SubArray{Int64,2,Array{Int64,5},(UnitRange{Int64},Union(Colon,Int64)...),1}
2x2x2x2 SubArray{Int64,4,Array{Int64,5},(UnitRange{Int64},Colon,Colon,Colon,Int64),1}:
[:, :, 1, 1] =
⋮ |
Sorry, I meant #8504. Keno didn't like #8973 before, but maybe it's OK now? It's a lot easier than #8504 (comment). |
The good news is that in this case the method cache seems ok; there are only concrete types in the cache for |
I'm fine with this plan. Jeff, I know how to make @mlubin: I'm sorry I didn't see this when you first asked it. Buried in the pile of julia-related email. |
Increasing the max depth now works, but seems to make the compiler slower (as measured by the test suite). |
this is a bit drastic, but otherwise there is too much risk of type unsoundness. fixes #8504
@timholy great, it would be good to have fewer staged functions, used only when really necessary. |
Is it actually making the compiler slower? Or is it simply compiling more specialized methods? |
Some individual tests were taking significantly longer. Later I noticed a few tests were slightly faster. Clearly some objectivity was needed, so I looked at the total time and overall the tests took 4% longer. So maybe not that big an effect after all. |
Currently failing on 64-bit appveyor:
Is this unrelated? |
Okay to merge then? |
Bump. Rebased and passing now. |
Bump? (ref #12289 (comment)) |
Bumping
MAX_TYPE_DEPTH
enables efficient use of types parameterized byGenericGraph
objects from the Graphs package. See JuliaAttic/OldGraphs.jl#171.CC @JeffBezanson