Skip to content

generate_quantities, alternative approach to parallel compute #1073

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

Open
ssp3nc3r opened this issue Mar 31, 2025 · 3 comments
Open

generate_quantities, alternative approach to parallel compute #1073

ssp3nc3r opened this issue Mar 31, 2025 · 3 comments
Labels
feature New feature or request

Comments

@ssp3nc3r
Copy link

generated quantities is embarrassingly parallel over sampling iterations; but the current implementation of parallel compute in cmdstanr method function generate_quantities is limited to the same chains and threads_per_chain argument as is helpful in a reduce sum calculation.

Here's how I've been changing its use to employ as many available cores as available.

  1. repeat posterior::split_chains on the fitted object until these equal to the number of cores wanted
  2. in generate_quantities set parallel_chains = nchains(x) with threads_per_chain equal 1 (if used for reduce sum): e.g.,
# pull draws and split chains to = cores 
x <- split_chains( f$draws() )
x <- split_chains( x )
# ... split until you have enough for each core

# uncomment generated quantities, recompile
# cpp_options aren't always needed, but to demonstrate when used
m <- cmdstan_model('fit.stan', cpp_options = list(stan_threads = TRUE))

# use the new draws object
q <- m$generate_quantities(
              fitted_params = x, 
              data = dat, 
              parallel_chains = nchains(x), 
              threads_per_chain = 1)

Since cmdstanr already requires posterior, I thought it may be possible to bake in something like the above to make better use of parallel compute natively without manually splitting.

Otherwise, maybe this will serve as a tip. :)

@ssp3nc3r ssp3nc3r added the feature New feature or request label Mar 31, 2025
@andrjohns
Copy link
Collaborator

This is probably a better issue to raise against cmdstan itself, since changes to parallelism will be much more efficient at the c++ level than the R wrapper (plus will be more widely beneficial)

@WardBrian
Copy link
Member

embarrassingly parallel over sampling iterations

Note that this is morally true for a lot of use cases, but care must be taken when you want reproducibility.

The chain level parallelism provided by the current cmdstan is such that a given seed will always provide the same results for a given program regardless of the threading environment.
I believe for the generate_quantities method specifically, it is even currently the case that standalone GQ will produce the same results as if you had originally run the full model with this GQ block, if you use the same seed.

@jgabry
Copy link
Member

jgabry commented Apr 7, 2025

Alternatively, if this doesn't make it into CmdStan itself, another option could be to demonstrate this technique in a Stan case study or CmdStanR vignette. I can imagine people finding it useful.

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

No branches or pull requests

4 participants