-
Notifications
You must be signed in to change notification settings - Fork 83
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
feat: experiment for reusing allocated buffers for Dyn multivariate #278
feat: experiment for reusing allocated buffers for Dyn multivariate #278
Conversation
@FreezyLemon an alternative to #273, what are your thoughts? Noting as a tangential discussion, since #180 was referring to MCMC, perhaps there would also be a need for many more variables than |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #278 +/- ##
==========================================
- Coverage 93.75% 93.38% -0.37%
==========================================
Files 53 53
Lines 11801 11799 -2
==========================================
- Hits 11064 11019 -45
- Misses 737 780 +43 ☔ View full report in Codecov by Sentry. |
This seems like it will result in a nicer API than 273 for sure. Hm.. without |
I realized this morning all of this works because of Also, you mentioned how a distribution should be immutable, and I agree, so semantically it would make more sense to have |
takes approach of making a few fields `Option`, to use `take` since creating `nalgebra::Cholesky` requires ownership
e5ab085
to
e88c40b
Compare
redid this with I considered a type that represented this kind of "field that owns a data" that always logically stores a value, but is just a wrapper to an |
Have you benched this? I've tried implementing a builder pattern for some time and benches have always shown it's not really any faster than just reallocating. Unless the amount of variables (and thereby allocation size) is much larger than I've tested, I doubt this makes much difference at all performance-wise. Some napkin math (please double-check) reveals that for Even with 1000 variables, we're talking about ~24MiB which still isn't huge. |
I did a rudimentary profiling run for 1000 variables, just running https://share.firefox.dev/4enR0hX The code is basically: fn main() {
let (mean, cov) = create_mean_and_cov();
for _ in 0..40 {
MultivariateNormal::new_from_nalgebra(mean.clone(), cov.clone()).unwrap();
}
} If you look for allocating functions (mostly Edit: What I'm getting at is that, if anything, other optimizations should probably be targeted first. Or a switch away from nalgebra if that is the bottleneck here... Even if allocations are slower on other hardware, surely it can't be so much slower that it becomes a problem? |
Oh this is a smarter way to do preliminary benchmarks. I was going to check if this in-place mutation was faster 🙃. Thanks for doing this! What did you use to profile and view with Firefox profiler? Changing from nalgebra right now does seem a bit like it wastes effort, so I'm averse to it until we get some more feedback. I'll close this and share thoughts about something benefitting MCMC on the initial issue. |
I used samply, it's really easy to use after a bit of setup and does the firefox profiler stuff for you. |
takes approach of making a few fields
OnceCell
, allowing for init-ingprecomputed values while allow taking them out to modify without
reallocate
Implementing similar way to update location via
set
orset_with
would also be implemented.Would also implement nearly identical in StudentsT.