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
Use SnoopPrecompile.jl #140
Conversation
A documentation preview has been successfully built, view it here: Documentation preview PR-140 |
I use it for Zygote in FluxML/Zygote.jl#1281, but didn't get nearly the same speedup because it seems to be bottlenecked by LLVM time. This is quite the improvement! |
So should I go ahead with this? I'm not sure how much of this actually comes from Flux.jl vs FluxTraining.jl. Maybe we should try this with Flux.jl as well. |
We should, though that seems like a much bigger project given the size of Flux's API. If you're able to |
Good to know. I just rebased the Zygote PR, are you able to test again with it? |
Yup, now testing with FluxTraining#master and Zygote#bc/precompile:
Safe to say that Zygote.jl is the culprit here :P . I think this implies the downstream improvements from #bc/precompile are more significant than for Zygote.jl itself. If that's the case, we should definitely merge that one. |
Finally, the one with precompilation in both Zygote and FluxTraining is even better:
So I will be merging this PR as well if it looks good to you Brian. |
This adds a basic precompile statement using SnoopPrecompile.jl.
This reduces the Time-to-first-
fit!
byMeasurements:
using FluxTraining
: 21s (this PR), 19s (master) -> 2s slowerfit!(testlearner(), 1)
: 14.5s (this PR), 30s (master) -> 15s fasterThis seems like a clear win for me, except for the longer precompilation time which will only occur once for regular package usage. Has anyone tried using SnoopPrecompile.jl for other packages in the FluxML org?