-
Notifications
You must be signed in to change notification settings - Fork 230
Reduce deepcopy #254
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
Reduce deepcopy #254
Conversation
|
HMC on LDA before cache was 429s (https://travis-ci.org/yebai/Turing.jl/jobs/231713149) and after is 369s (https://travis-ci.org/yebai/Turing.jl/jobs/231726143). Cache saves 1 run of gradient if the previous step is not rejected. |
|
218s after setting chunksize to 60 (https://travis-ci.org/yebai/Turing.jl/jobs/231734804) |
Yes, we can do that first.
Nice! |
|
I think appveyor fails because the cache dict uses |
|
UPDATE: Collecting 1000 samples for LDA: Turing.HMCDA takes 58.7 seconds. |
…into reduce-deepcopy
|
@yebai I guess I will leave the vectorization of assume for future. The reason is that the vectorization is only make things faster if all of Shall we merge this PR then? |
|
Another related issue I was stuck is the convention of matrix, i.e. default functions all treat thing as matrix and we now write things as vector of vector because of our chain interface issue (https://github.com/yebai/Turing.jl/issues/207). |
|
Can we merge this to master? |
Address #237
Also fix #245
Almost done. But I also want to implement a cache of gradient - we can actually cache some of the gradient for leapfrog. The gradient used in NUTS is especially low-efficient because our leapfrog also re-compute grad in the beginning and the recursion of NUTS calls the leapfrog by only 1 step each time:
I think it's fine to just cache the gradient by a dictionary inside spl.info?