CmdStan 2.27.0 release candidate

General
21

I have easily reproduced this. See the Github issue @stevebronder

I now have a strong candidate now I think.

22

Great! And you are on Linux @rok_cesnovar ?

Here is the model with profiling stuff added

blrm_exnex-profile_stan.txt (28.5 KB)

(I used cmdstanr time() commandā€¦that is good, no?)

23

Yeah Ubuntu. Lets continue on Github. Else if any other issue pops up this thread will become hard to follow.

24

cmdstan is our most direct interface so Iā€™d rather look for regressions using it and bash. I also ran the above with nothing else running on my computer. Other stuff running can cause cache to be taken up etc.

@rok_cesnovar Iā€™m seeing the github issue, but honestly Iā€™m confused about what models and versions people are checking. Are you both using the exact same model as the one here?

That model doesnā€™t have profiling data in it so Iā€™m not sure which model yinz are using (and tbh Iā€™m not that worried about performance regressions with models that have profile statements as I donā€™t think models that have those are performance critical.)

Are both of your results running the same (not similar, same) scheme as what Iā€™m doing above? Iā€™m worried we are comparing apples and oranges in terms of time, it would seem very weird that my computer is faster with the new version while another has a 20% slowdown

25

Cmdstanr time() is just timing how long the process is alive. Its fine, especially for this huge regression.

26

For me itā€™s mostly that it adds another layer of complication and just using cmdstan gets us down to exactly what we want to measure before we spend a lot of time reverting things

27

Like @rok_cesnovar suggest, letā€™s move to github.

I have seen the regression with and without the profiling stuff in the model. I would also trust the cmdstanr reported ā€œtimeā€ reports as these come from cmdstan itself and these are wall time since 2.26 (as I recall).

I am not sure why you are not seeing a regression, but I am and @rok_cesnovar is as wellā€¦which sounds as if we are in the majority for now :D

28

Yeah agree to move over to github so we arenā€™t juggling two threads

29

I just synced and built after a make clean-all and get a lot of substitution failures.

Edit: I re-cloned and all is well!

1 Like
30

Does something like alpha1, alpha2, alpha3 ~ normal(0,100); in the model block make sense? Or there is already a way to apply the same prior to multiple parameters?

31

I think itā€™s (see 6.3 Vector, matrix, and array expressions | Stan Reference Manual)
[alpha1, alpha2, alpha3] ~ normal(0,100);

4 Likes
32

This is indeed the way to do it right now.

Supporting the syntax in @nipnipjā€™s example was also suggested (https://github.com/stan-dev/stanc3/pull/670#issuecomment-702840841) by @rybern in his PR, so it issomething that might eventually get supported as well.

2 Likes
33

What about something like target += normal_lpdf(alpha1, alpha2, alpha3 | 0, 100).

34

I would strongly prefer

target += normal_lpdf([alpha1, alpha2, alpha3] | 0, 100).

to make it clear that thereā€™s only one argument on the left of the vertical bar.

4 Likes
35

That should already work now. No?

2 Likes
36

Yes, this model compiles fine:

parameters {
    real y;
    real x;
    real z;
}
model {
    target += std_normal_lpdf([x,y,z]);
    // tilde statement equivalent of the above (ignoring constants)
    [x,y,z] ~ std_normal();
    // tilde statement exact equivalent
    target += std_normal_lupdf([x,y,z]);
}
2 Likes
37

For anyone following along with this we sorted out the performance bug in the issue below

5 Likes