# Evaluating parallelization performance

**URL:** <https://discourse.mc-stan.org/t/evaluating-parallelization-performance/10962>\
**Category:** Developers\
**Created:** [September 13, 2019, 9:47am UTC](https://discourse.mc-stan.org/t/evaluating-parallelization-performance/10962 "2019-09-13T09:47:32Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![yizhang](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/yizhang/32/15673_2.png) [@yizhang](https://discourse.mc-stan.org/u/yizhang)\
**Post date:** [September 13, 2019, 2:40pm UTC](https://discourse.mc-stan.org/t/evaluating-parallelization-performance/10962/3 "2019-09-13T14:40:59Z")

</div>

> [@Bob\_Carpenter](#):
>
> For task 1, parallelizing a single chain dominates. For task 2, running multiple chains dominates because MCMC is embarassingly parallel.

Similar thing hit me in a different context: if we can control the behavior of some math function according to where the sampler is, there are some performance gain can be made. Like in ODE models sometimes even if I know the problem is non-stiff I have to run it in stiff solver because the sampler stepped into regions the solution becomes stiff.

> [@Bob\_Carpenter](#):
>
> massively parallelize adaptation

Within-chain parallelization can be done in various flavors, and currently we are not designing it in a organized way(which is the point of the thread, I guess). There are things easier/better to be done in distributed level, and things better in thread level. Even in a same level we can have multiple tiers. Unless we can reach a design decision there are going to be many iterations in future designs.

---

_[View the full topic](https://discourse.mc-stan.org/t/evaluating-parallelization-performance/10962)._