Skip to content
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

Compare performance of brmp (pyro/numpyro) and brms #12

Open
null-a opened this issue Sep 30, 2019 · 4 comments
Open

Compare performance of brmp (pyro/numpyro) and brms #12

null-a opened this issue Sep 30, 2019 · 4 comments
Milestone

Comments

@null-a
Copy link
Collaborator

null-a commented Sep 30, 2019

No description provided.

@null-a null-a added this to the v0.0.1 milestone Oct 10, 2019
@null-a
Copy link
Collaborator Author

null-a commented Oct 10, 2019

Including both CPU and GPU (#14).

@neerajprad
Copy link
Member

@null-a : We were running some benchmarks here - pyro-ppl/numpyro#470, and are mostly concluding that right now. From what we can see, it seems very likely that you will observe good performance on all your models. Let us know if there are any particular models that you would like to test out, or have observed some things to be slower than expected. We are also going to be doing a minor release tomorrow which should fix the memory issue, and the issue of model code being recompiled when we run MCMC.

For the latter, recompilation can be avoided by simply calling .run on the same MCMC instance, but the data shape needs to be the same too (XLA will recompile the code if the input data shape changes). I am not sure if the current brmp code is set up to take advantage of avoiding recompilation this way, but if this seems important, we should set up the backend to take advantage of this.

@null-a
Copy link
Collaborator Author

null-a commented Dec 3, 2019

I am not sure if the current brmp code is set up to take advantage of avoiding recompilation this way

No, not yet. (Now #79)

but if this seems important

FWIW, the use case I have involves repeatedly performing inference on a model every time a new data point arrives, so it sounds like this particular case might not benefit from caching.

@fehiepsi
Copy link
Member

fehiepsi commented Dec 4, 2019

this particular case might not benefit from caching

This is tricky... I think the proposal from @neerajprad to embed the current data into a holder and provide data_size information to mask out data will work here. The pattern will be something like

data = np.zeros(LIMIT_SIZE)
# assume that currently, data has size `size`
# when a new data point comes
size = size + 1
data[size] = new_data_point
mcmc.run(rng_key, data, size)

and for the model

def model(data, size):
   ...
   current_data = data[:size]  # probably use lax.dynamic_slide_in_dim here
   sample("obs", dist.Normal(mu, sigma), obs=current_data)

WDYT about it? I think this will work for regression cases, but caching won't work if there is a latent variable having shape depend on size...

Probably this will be easier if XLA supports caching with dynamic data size in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants