-
-
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
improve inference for getproperty #909
Conversation
This is cool.
Could you elaborate a bit on this? Why is this necessary? I'm sure it could be ascertained from the PR itself, but I could use a helping hand 😂 |
I am still going through the pr, it'd be good to get an idea if the generated function is too low level for Julia ir so as to break with newer releases. |
Zygote's previous assumption was that |
Ohhh I see. This makes sense. Will comment on the PR itself. |
src/lib/lib.jl
Outdated
is_getfield_fallback = which(_pullback, pb_sig(x)) == which(_pullback, pb_sig(Any)) && | ||
which(getproperty, sig(x)) == which(getproperty, sig(Any)) | ||
|
||
if is_getfield_fallback |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another high-level question, what's the reason that this entire case can't be written as
# we've ensured that we're fine to short-circuit and call `getfield` directly,
return :(Zygote._pullback(cx, literal_getfield, x, f))
rather than pulling up the IR for that method and pasting it here as is currently proposed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main reason is that we can't (at least that I know of) manually attach backedges to regular expressions, so we need to return a CodeInfo object. We could return a CodeInfo that just contains that call, but if we already go to lengths like this, we might as well just directly inline the whole thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also makes sense to me.
It is definitely fairly low-level, so it is not impossible this might cause problems with future Julia versions. It is basically the same mechanism |
This is awesome. I have been tracking the regression. I was originally suspicious to Julia 1.6. and reported here This was my MWE
which on Zygote 0.5.17 with Flux 11.3 runs as
But on Zygote@0.6.3, Flux v0.11.6 it is fairly slow
and testing this PR with Flux v0.11.5 gives
So this is awesome. Can it be merged and tagged? |
Yes, sorry, I had other stuff to do and didn't come around to finishing this. I will try to finish this up some time later today. |
@simeonschaub how's this going? :) |
Please don't merge this yet, it currently breaks custom adjoints for |
Is there a chance of this being merged in the near future? :) |
Yes, feel free to bug me about it from time to time, which probably increases the chances of me eventually finishing it. 😄 I will try to get to it soon again but every time I work on it, I discover some new issue... |
bump :) |
1681: Support NamedTuples for Chain + Parallel r=mcabbott a=mcabbott Closes #1680, WIP. Todo list includes: - [x] add Parallel too - [ ] ~~worry about whether any of this will upset Zygote, like FluxML/Zygote.jl#909 or, kick that can down the road. - [x] add tests Co-authored-by: Michael Abbott <32575566+mcabbott@users.noreply.github.com>
1681: Support NamedTuples for Chain + Parallel r=DhairyaLGandhi a=mcabbott Closes #1680, WIP. Todo list includes: - [x] add Parallel too - [ ] ~~worry about whether any of this will upset Zygote, like FluxML/Zygote.jl#909 or, kick that can down the road. - [x] add tests Co-authored-by: Michael Abbott <32575566+mcabbott@users.noreply.github.com>
1681: Support NamedTuples for Chain + Parallel r=darsnack a=mcabbott Closes #1680, WIP. Todo list includes: - [x] add Parallel too - [ ] ~~worry about whether any of this will upset Zygote, like FluxML/Zygote.jl#909 or, kick that can down the road. - [x] add tests Co-authored-by: Michael Abbott <32575566+mcabbott@users.noreply.github.com>
@simeonschaub bump :) |
This has regressed quite a bit due to FluxML#848. With this PR, we should be able to get back the same performance as before, assuming there is no custom implementation or pullback for `getproperty`. Still need to add tests.
24bcd83
to
a3f8dc4
Compare
Ok, sorry for taking so long to getting around for this. I have pushed some more changes and now the only broken case left is the backedges for overloading |
Any ideas why the GH actions jobs are not running? |
I see they're going |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pushing this forward. A couple of test-related comments.
3d56f79
to
bdbb369
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fantastic work @simeonschaub . I think it just needs a patch bump, then it'll be good to go.
@simeonschaub can we bors this? |
Sure, please go ahead! |
bors r+ |
Build succeeded: |
This has regressed quite a bit due to #848. With this PR, we should be able to get back the same performance as before, assuming there is no custom implementation or pullback for
getproperty
. Still need to add tests.