-
-
Notifications
You must be signed in to change notification settings - Fork 213
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
Type instability with structs #1094
Comments
This is, unfortunately, a known issue. There's a PR that's been open for a long time to try and fix the problem, but no progress has been made recently: #909 In the mean time, you can work around (provided that you're using the default Specifically, see the docstring for You have to do this for every type for which you want |
Will beat me to it, but yes #909 will fix this. @simeonschaub should we revive it? I think it would be the right fit for such use cases |
That would be nice. Every time I try and do anything performant I have to write more code than I would like. |
Thanks for the answers, and for working on this! I did not think of searching for this issue among the pull requests... It would be very useful if this could be mentioned in the Performance section of the docs. I'm pretty sure the workaround can be included as a simple macro similar to |
Counterpart PR to the ZygoteRules one: #1091 :) |
@willtebbutt This does render the code I'm using fully type-stable again under |
@DhairyaLGandhi what are your thoughts about properly documenting a work-around vs convincing @simeonschaub to finish up his PR? |
Would it be possible to figure out which method of |
IIUC that's essentially what #909 is doing. I still don't fully understand how reliable a strategy it is, because the docs for generated functions suggest it's a bad idea to depend on mutable global state inside of generated functions (the method table being mutable global state). That being said, Zygote does this kind of thing to interop with ChainRules and it seems to work (up to the need to call (I think what I've said is broadly correct -- if someone knows better, please do correct my misunderstanding :) ) |
I largely prefer the direction of #909 and it seems to not hurt existing overrides. I should give the workaround a shake too. |
Agreed -- I'd prefer 909, I just wonder if it will ever get finished. |
#909 has just been merged. @kaandocal when you can get a copy of v0.6.27, could you check that your code is performant without the workaround? |
It seems to work now, thanks! By the way it turns out |
Zygote seems to lose type stability (unnecessarily?) when it is used with
struct
s likeFlux.Dense
.yields
On the other hand, with Zygote,
yields
It seems like the culprit is that
Zygote.literal_getproperty
defaults toBase.getproperty
which is type-unstable. Pay attention to the presence ofUnion{typeof(identity), Array{Float32, N} where N}
which is exactly the generic type of an element ofDense
.Is this intended behaviour? I am trying to optimise a training routine using Flux and I've noticed that profiling shows a lot of type-instability and GC when Zygote is involved, which might cause a certain slowdown. Is there any way to avoid this, or to "precompile" the loss function (assuming no dynamic branching etc.) for better performance?
The text was updated successfully, but these errors were encountered: