There was a find.exe with windows. Before I hacked cmder to use unix style find, but I found m2-findutils which probably means everything can be installed with conda.
Steps with conda:
Download and install miniconda3 x64 (I recommend python3)
Open anaconda prompt (or cmd if miniconda is found in PATH)
Create conda environment
#optional step - creates "isolated" environment
conda create -n cmdstan python=3.7
# activate env - this is needed everytime you
# open commandline, unless you skip creating the conda env
conda activate cmdstan
conda install make m2w64-toolchain m2-findutils -c msys2
cd to cmdstan folder and use gnumake as make. There is also mingw32-make which came with the toolchain, it works too.
gnumake build -j4
If needed, edit makefile and add CC=gcc and CXX=g++ (or/and CPP=g++). These might be needed if msvc was installed on your computer, not sure if this is true.
I can confirm that this works. However, I had to do everything in the Anaconda prompt since a lot of paths (e.g. to mingw binaries) are not set otherwise, even if the “normal” Anaconda paths are set.
Also, gnumake does not seem to be installed through the packages. Using mingw32-make, as you noted @ahartikainen, works perfectly fine.
In the Wiki it should maybe also be noted that even the model has to be build from the same prompt, to ensure the same build environment.
EDIT: Using mingw32-make and the anaconda prompt, the only change to the makefiles I had to make was to add CXXFLAGS += -DSTAN_THREADS. Btw, @wds15, does this change have to be made for each sub-repository or is it enough to make it in stan-math?
this change only needs to made to whatever repository you use. So if you run a threaded test in stan-math, then do it there. In case you run a threaded cmdstan model, then you only need to edit cmdstan/make/local (but an entry for the nested stan_math won’t hurt nor be useful).
My bad. I had an old version of Anaconda installed. I uninstalled it, installed the newest miniconda and now that part works great. In cmd in any case, not in PowerShell, what I usually use. But I see that is a general condaissue.
If I install everything as you describe above (so not installing gnumake for now) I get some weird error messages when I try to use make
1 [main] make 12488 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to
the public mailing list cygwin@cygwin.com
and then a bunch of complains about not finding /bin/sh. Afterwards it starts compiling though. This makes it necessary to use mingw32-make. I wonder why you install make at all, in the instructions above. You maybe meant to write gnumake?
EDIT: Sometimes I should try stuff on the command line first before writing. So installing the package make from the channel conda-forge gives you gnumake and that works fine as well. So the difference is maybe that in your miniconda you prefer conda-forge over the standard base channel and that is why get gnumake?
Good to know! That actually seems to break it again though… During my last test I had only added CXXFLAGS += -DSTAN_THREADS in the stan-math sub-module while compiling from the cmdstan repository. Now that I set the flag in make/local directly in the cmdstan main folder, I get the old behaviour. I compiled cmdstan like @ahartikainen describes, I compiled your example model from above, @wds15, but then it only prints the cmdstan config and exits before sampling.
Did you set the respective compile flags, @ahartikainen?
# CmdStan users: if you need to customize make options,
# you should add variables to a new file called
# make/local (no file extension)
As far as I can see it the Stan Makefile reads in a file called local in the folder make if it exists. There you can simply add your own modifications. Files without an extension are a big thing once you leave the Windows world ;-)
When you clone a fresh copy of cmdstan the file make/local isn’t there. So I created it and added exactly one line to it
CXXFLAGS += -DSTAN_THREADS
This way it works great on Ubuntu.
On Windows the compilation still seems to work, but not the sampling.
@ahartikainen I really like your way to set up a mingw toolchain though. It’s convenient and fast.
Yes to 1 and 2. I can compile @wds15’s sample model without a problem. The Bernoulli example compiles and samples as expected.
I cleaned everything with gnumake clean-all . I tried to abide to the Windows \ / quirks. Like gnumake ../model-path/model.exe to build the model. I know that \ makes problems here.
Well… this is black magic, isn’t it? Now it samples :-D I could swear I didn’t do anything different. It is also quite a bit slower as before, which might be expected with the added overhead. So maybe this toolchain really is the way to go. Thanks @ahartikainen
Well… this isn’t over yet :-D Motivated by the success with @wds15’s test model, I wanted to compile and sample from one of my own models involving ODEs. I did a proper cleanup of old executables and headers and the model builds fine. However, it exits before sampling.
I am quite sure that the model is correct as it compiles and samples with threading support on Ubuntu and a cluster running CentOS.
If I find time soon I’ll try to break it down to a smaller model to isolate the issue a bit. (Or to see that it works. Then the problem is somewhere in the size of my model maybe, we’ll see)
Thank you, @Cyianor. Looks like I get the same result as you - i.e. it just exits when STAN_NUM_THREADS is greater than 1.
Edit: I used the model and data above, and have created the make/local file with CXXFLAGS += -DSTAN_THREADS in the cmdstan-folder. Apart from that followed the instructions here.