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

Unifying thread syntax across samplers #996

Open
saudiwin opened this issue Jun 13, 2024 · 3 comments
Open

Unifying thread syntax across samplers #996

saudiwin opened this issue Jun 13, 2024 · 3 comments
Labels
feature New feature or request

Comments

@saudiwin
Copy link

Is your feature request related to a problem? Please describe.
This isn't a big deal, but now that we have multiple sampling algorithms, it would be nice if we could condense the syntax for specifying multi-threading. Currently, the sample method has threads_per_chain, pathfinder has num_threads, and laplace has threads. Especially as some of the utility of the variational methods is in using them as testing or initialization for MCMC, it would be nice if we could unify this syntax.

Describe the solution you'd like
Perhaps just a single argument like num_threads or perhaps for compatibility with sample the others could all use threads_per_chain.

Describe alternatives you've considered
Perhaps the other variational methods could also take threads_per_chain as an additional argument if threads or num_threads isn't specified.

Additional context
This is mainly for using cmdstanr in a pre-compiled model context in which switching from one sampling method to another may be done for the same data/model.

@saudiwin saudiwin added the feature New feature or request label Jun 13, 2024
@karimn
Copy link

karimn commented Jun 19, 2024

This tripped me up recently. I switched from variational to pathfinder and was confused why my threads = 12 didnt' work anymore.

@SteveBronder
Copy link
Collaborator

I think we should have threads for all of them. The samplers should be using the multi-threading across chains available in cmdstan. So then the user just specifies how many chains they want and stan internally does thread management for within and across chain parallelization

@SteveBronder
Copy link
Collaborator

We have not done that yet because it is a pretty big rewrite of some internals of cmdstanr

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

3 participants