Rstan 2.26 - threads_per_chain always set to max even with rstan_options( threads_per_chain = 1 )

Hello,

a strange behaviour I find now is that threads_per_chain is always set to max even with rstan_options(threads_per_chain = 1), and the model got very slow (I’m not sure the reason being that tries to saturate all the cores).

> system("gcc --version")
gcc (GCC) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> sessionInfo()
R version 4.1.2 (2021-11-01)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS:   /stornext/System/data/apps/R/R-4.1.2/lib64/R/lib/libRblas.so
LAPACK: /stornext/System/data/apps/R/R-4.1.2/lib64/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8      
 [8] LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] tictoc_1.0.1       cellsig_0.0.0.9000 forcats_0.5.1      stringr_1.4.0      dplyr_1.0.7        purrr_0.3.4        readr_2.1.1        tidyr_1.1.4        tibble_3.1.6       ggplot2_3.3.5     
[11] tidyverse_1.3.1    rstan_2.26.6       StanHeaders_2.26.6

loaded via a namespace (and not attached):
 [1] httr_1.4.2           foreach_1.5.1        jsonlite_1.7.2       modelr_0.1.8         RcppParallel_5.1.4   assertthat_0.2.1     posterior_1.1.0      distributional_0.2.2 stats4_4.1.2        
[10] tensorA_0.36.2       ggdist_3.0.1         cellranger_1.1.0     pillar_1.6.4         backports_1.4.1      lattice_0.20-45      glue_1.6.0           arrayhelpers_1.1-0   checkmate_2.0.0     
[19] rvest_1.0.2          colorspace_2.0-2     pkgconfig_2.0.3      broom_0.7.10         svUnit_1.0.6         haven_2.4.3          scales_1.1.1         processx_3.5.2       tzdb_0.2.0          
[28] generics_0.1.1       farver_2.1.0         ellipsis_0.3.2       withr_2.4.3          cli_3.1.0            magrittr_2.0.1       crayon_1.4.2         readxl_1.3.1         ps_1.6.0            
[37] data.tree_1.0.0      fs_1.5.2             fansi_0.5.0          xml2_1.3.3           pkgbuild_1.3.1       tools_4.1.2          loo_2.4.1            prettyunits_1.1.1    hms_1.1.1           
[46] lifecycle_1.0.1      matrixStats_0.61.0   V8_3.6.0             munsell_0.5.0        reprex_2.0.1         callr_3.7.0          compiler_4.1.2       tidybayes_3.0.1      rlang_0.4.12        
[55] grid_4.1.2           iterators_1.0.13     rstudioapi_0.13      gtable_0.3.0         codetools_0.2-18     abind_1.4-5          inline_0.3.19        DBI_1.1.1            curl_4.3.2          
[64] R6_2.5.1             gridExtra_2.3        rstantools_2.1.1     lubridate_1.8.0      utf8_1.2.2           stringi_1.7.6        parallel_4.1.2       Rcpp_1.0.7           vctrs_0.3.8         
[73] dbplyr_2.1.1         tidyselect_1.1.1     coda_0.19-4 

Makevars

CXX14FLAGS += -O3
CXX14FLAGS += -DSTAN_THREADS
CXX14FLAGS += -pthread
CXX14FLAGS += -march=native -mtune=native -fPIC
CXX14FLAGS += -DUSE_STANC3
CXX14=g++

MAKEFLAGS = -j8

Can you test the experimental version?

remove.packages(c("StanHeaders", "rstan"))
remotes::install_github("stan-dev/rstan/StanHeaders@experimental", upgrade = "always", force = TRUE)
remotes::install_github("stan-dev/rstan/rstan/rstan@experimental", upgrade = "always", force = TRUE)

Also, make sure that STAN_NUM_THREADS is not defined in your environment, or set it to 1:

Sys.getenv("STAN_NUM_THREADS")
Sys.setenv("STAN_NUM_THREADS" = 1)

Thanks,

this happened when I create a clean rstan package, rather than create the model and call it outside projects and packages.

Now I have abandoned that effort, and back to the environment is working (fast and running the cores that it should). But I will try.

A possible problem could be my messy gcc environment, in case I compile with a GCC version and run with an old one (perhaps?).

Thanks for the tip.