Got some promising results. Using RStan 2.21 from CRAN, I get the TBB errors just from example(stan_model, run.dontrun=T). But when I install the github version from the syntax above, the example model runs fine as well as a larger factor analysis model of mine.
I can test this on a couple of other windows machines tomorrow (itās midnight here), so let me know if there are other models or configs to test
The linker error should be fixed on GitHub by setting the LOCAL_LIBS environmental variable. But the known unknown is the problems that @MauritsM (the OP) and other Windows users (on other threads) have had with models that compile, link, and subsequently fail with something that looks like a stackoverflow.
@MauritsM this HMM seems to be work in serial or in parallel on @mike-lawrenceās Windows computer, so we need to figure out what the difference is. Can you do
and then tell me if you spot a material difference in the Compilation argument compared to:
after installing StanHeaders and rstan from the thread you posted the model suddenly seems to sample fine. Iām not sure whatās different now, unfortunately.
I noticed that, when running with cores > 1 I can no longer see the progress of the chains in RStudio. When I click on the Viewer tab I get the following message:
The process cannot access the file because it is being used by another process
The second thing I noticed is that print(fit) is now very slow. It takes minutes to print the summary of the samples, where this used to be a couple of seconds.
I captured the compilation argument when compiling the model (see below). Hopefully this is still useful to you. This seems to be pretty much the same as Mike except for some small changes in Makevars.
I definitely could see the progress in the Viewer tab. All the chains write to the same file but I donāt know why it couldnāt be read. Is print(fit) slow on all models? I noticed it took a little while but figured that was due to having 10000 iterations.
Is it the case that -march=native is necessary and sufficient for the crash? This would suggest that it is processor-dependent in addition to Windows-dependent.
The March thing is not working ok on mingw. People should avoid using it on windows. The link I posted above is what can be used according to a colleague of mine.
I can confirm that removing -march=native and following your advice from above solves the issue for me, at least when using the winbuilder binaries Ben posted in Rstan on Windows
When I remove -march=native I have a -march=core2 in my build and the model runs.
I think you can get segfaults trying to execute instructions your cpu doesnāt support. I wonder if thereās a way to scan the object file to figure this out?
I think we just have to avoid -march=native on Windows for now. With g++-4.9 I assumed the processor tuning was due to having processors that were not in production when g++-4.9 had its final release, but perhaps there is something that messes up processor identification on Windows more generally.
I have encountered the -march=nativeissue before. It is a longstanding bug in MinGW.
If a CPU supports AVX instruction set -march=nativeallows use of these instuctions. Eigen than uses certain AVX instructions that require 32-bit aligment of memory locations they touch. Windows provides stack that is 16-bit aligned and compiler does not do any extra alignment, so executing these instructions crashes.
I also found a workaround that works for me, even if I have no idea why. If I skip the make and compile by invoking g++ manually, so that everything is compiled in a single invocation and no object files are generated things work for me. No idea how portable this workaround is. Other options are to use either clang or Linux.
The viewer also doesnāt seem to work for other models either. Do you have any idea what could cause that?
print(fit) was quick for the 8 schools model and some other models over here - it might be that for the HMM model I posted there is simply a lot more data to print (and as you mentioned, 10K iterations surely slows that down as well).
EDIT: after some more testing on different machines I get the feeling that this model has always been slow to print and I simply remembered incorrectly. Itās quicker on my Mac but my Mac is way more powerful than my Windows machine. On my Windows machine at work (which runs 2.19) the model is also slow to print, so please donāt spend any more time on this.