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
{{ message }}
Repository navigation
Invalidations from ChainRulesCore Tangent overload on Tail #576
This one has a lot of children and will hit a lot of packages, so it would be nice to fix it if possible. @oxinabox are you suggesting deleting the method?
The ones on * are not a concern.
They aren't affecting anything real that will ever matter. Though it might be nice to find out what actually causes them.
The one on convert is a bit of a worry, I would like to know where it came from. I.e. what changed in Base (I guess?), as that wasn't there before.
Or did SnoopCompile get smarter.
Re:tail. We should also be able to delete
So the remaining ones are on line 109.
I guess this is because now there exist multiple possible return types for Base.tail(::Any) still.
Rather than just Tuple/NamedTuple? Which I guess it was relying on via world splitting.
Since Base.tail isn't part of the exported API, maybe we shouldn't have overloaded it in the first place. @mcabbott you added that in #567
is it actually being used anywhere?
There's no overlap with Tangent. Why exactly is anything invalidated?
I believe it is a so called "world splitting" optimization.
Where even if we can't infer which method of Base.tail is going to be hit,
if we know that all methods of Base.tail return one of a small number of types,
then we can generate the code for all of them and just put in a if
(It's like the small union's optimization)
So every week the mental model you need grows more complex. I guess this is a strong argument against defining your own types, when you can avoid it. "Your struct is as good as Base's" isn't quite true, it seems.
So every week the mental model you need grows more complex.
Yeah, I miss the days before julia had an optimizer. It used to be easier to reason about.
Julia is IMO a very hard language to reason about these days, luckily we have good tools now; and this stuff only matters right at the pointy-end of micro-optimizations which is done by experts.
Apparently world-splitting was introduced at the same time as small-union splitting.
But possibly SnoopCompile couldn't recognize it til recently.
idk
I think it can also be totally independent of any of these optimizations. If anything is inferred only as Any in some code in base or the stdlibs before calling tail on it, the methods in question need to be re-inferred and re-compiled when loading this package introducing a new method for tail. So the best fix would be to hunt the type instabilities in Julia base/stdlibs and fix them there. But someone needs to spend some time on this.
I think it can also be totally independent of any of these optimizations. If anything is inferred only as Any in some code in base or the stdlibs before calling tail on it, the methods in question need to be re-inferred and re-compiled when loading this package introducing a new method for tail.
No, I don't think so.
Without this optimization that should result in a dynamic dispatch, whcih would avoid need to recompilation.
I wonder how much we'd have to change in Base to delete Tangent entirely. Being able to add them is the big virtue, what chance we could get these methods accepted?
Base.:+(x::NamedTuple{s}, y::NamedTuple{s}) where {s} = map(+, x, y)
Base.:+(x::Tuple{Vararg{Any,N}}, y::Tuple{Vararg{Any,N}}) where {N} = map(+, x, y)
Activity
oxinabox commentedon Aug 23, 2022
Hmm is this a weird kind of invalidation not because we are defining a more specific method,
but because we define the only method that doesn't error?
I think it would probably be fine for us to error in this case too.
It's a weird corner case: https://github.com/JuliaDiff/ChainRulesCore.jl/blob/main/src/tangent_types/tangent.jl#L110
sethaxen commentedon Sep 1, 2022
This one has a lot of children and will hit a lot of packages, so it would be nice to fix it if possible. @oxinabox are you suggesting deleting the method?
ranocha commentedon Sep 7, 2022
Current version:
Removing https://github.com/JuliaDiff/ChainRulesCore.jl/blob/main/src/tangent_types/tangent.jl#L110:
So there are still many invalidations left...
The code removing https://github.com/JuliaDiff/ChainRulesCore.jl/blob/main/src/tangent_types/tangent.jl#L110 lives in https://github.com/ranocha/ChainRulesCore.jl/tree/hr/fix_invalidations. Shall I make a PR? Or does anybody have time to hunt these invalidations?
oxinabox commentedon Sep 12, 2022
The ones on
*are not a concern.They aren't affecting anything real that will ever matter. Though it might be nice to find out what actually causes them.
The one on
convertis a bit of a worry, I would like to know where it came from. I.e. what changed in Base (I guess?), as that wasn't there before.Or did SnoopCompile get smarter.
Re:tail. We should also be able to delete
So the remaining ones are on line 109.
I guess this is because now there exist multiple possible return types for
Base.tail(::Any)still.Rather than just Tuple/NamedTuple? Which I guess it was relying on via world splitting.
Since
Base.tailisn't part of the exported API, maybe we shouldn't have overloaded it in the first place.@mcabbott you added that in #567
is it actually being used anywhere?
mcabbott commentedon Sep 12, 2022
Base has these methods for
tail:There's no overlap with
Tangent. Why exactly is anything invalidated?mcabbott commentedon Sep 12, 2022
IIRC the rule which uses it is https://github.com/JuliaDiff/ChainRules.jl/blob/39c2d17df672836659493d6adb7d4ad8593250a5/src/rulesets/Base/indexing.jl#L175-L178 , obviously that could be re-written if someone wants to.
oxinabox commentedon Sep 12, 2022
I believe it is a so called "world splitting" optimization.
Where even if we can't infer which method of
Base.tailis going to be hit,if we know that all methods of
Base.tailreturn one of a small number of types,then we can generate the code for all of them and just put in a
if(It's like the small union's optimization)
mcabbott commentedon Sep 12, 2022
Ah ok.
So every week the mental model you need grows more complex. I guess this is a strong argument against defining your own types, when you can avoid it. "Your struct is as good as Base's" isn't quite true, it seems.
oxinabox commentedon Sep 12, 2022
Yeah, I miss the days before julia had an optimizer. It used to be easier to reason about.
Julia is IMO a very hard language to reason about these days, luckily we have good tools now; and this stuff only matters right at the pointy-end of micro-optimizations which is done by experts.
Apparently world-splitting was introduced at the same time as small-union splitting.
But possibly SnoopCompile couldn't recognize it til recently.
idk
ranocha commentedon Sep 12, 2022
I think it can also be totally independent of any of these optimizations. If anything is inferred only as
Anyin some code in base or the stdlibs before callingtailon it, the methods in question need to be re-inferred and re-compiled when loading this package introducing a new method fortail. So the best fix would be to hunt the type instabilities in Julia base/stdlibs and fix them there. But someone needs to spend some time on this.oxinabox commentedon Sep 12, 2022
No, I don't think so.
Without this optimization that should result in a dynamic dispatch, whcih would avoid need to recompilation.
mcabbott commentedon Sep 12, 2022
I wonder how much we'd have to change in Base to delete Tangent entirely. Being able to add them is the big virtue, what chance we could get these methods accepted?
ranocha commentedon Sep 14, 2022
JuliaLang/julia#46762 helps a bit but does not fix all invalidations.
JamesWrigley commentedon Jan 28, 2026
I think that now that ChainRules doesn't have that
Base.tail()rule we can delete the overloads 🤞 I put up a PR in #703.