# Addressing Stan speed claims in general

**URL:** <https://discourse.mc-stan.org/t/addressing-stan-speed-claims-in-general/14021>\
**Category:** Stan Governance\
**Created:** [April 2, 2020, 4:48pm UTC](https://discourse.mc-stan.org/t/addressing-stan-speed-claims-in-general/14021 "2020-04-02T16:48:20Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![adlauretig](https://avatars.discourse-cdn.com/v4/letter/a/9e8a1a/32.png) [@adlauretig](https://discourse.mc-stan.org/u/adlauretig)\
**Post date:** [April 3, 2020, 3:06am UTC](https://discourse.mc-stan.org/t/addressing-stan-speed-claims-in-general/14021/17 "2020-04-03T03:06:59Z")

</div>

> [@Bob\_Carpenter](#):
>
> That’s the current source of our problem.
> 
> 1. We thought we’d just translate the models from BUGS verbatim, gamma(epsilon, epsilon) priors and all so we could compare apples-to-apples on sampling speed.
> 2. We thought we’d write the simplest possible code for each model (pretty much a direct translation), then provide optimized versions.
> 
> But as soon as we provide simple code that’s slow, it’s going to get picked up and reused.

I will say that, when I’ve presented code, I’ve usually tried to only show “optimized” versions publicly (vectorized, non-centered parameterization, etc), since my thought has been that some will want the “default” version of a model to “just work,” and as a result, the first thing they should see should be the best (defined however you want). This may be tougher to read initially, but will also work better, which might be helpful. One caveat might be that there are, say, 3 versions of a model: single thread, multithreaded, and GPU, but that’s a clearer decision for the end user.

---

_[View the full topic](https://discourse.mc-stan.org/t/addressing-stan-speed-claims-in-general/14021)._