Very slow compilation / sampling, rstan, windows 10

General
1

‘Something’ has happened to a windows laptop I use that has resulted in very slow compiling and sampling. The laptop was out of action for a month or so, making me wonder if a recent update has done something, but perhaps it was a problem before also. I’ve tried reinstalling anything relevant I can think of (rtools, rstan), checked the makevars and system path… any suggestions for things I should try? rstan 2.17.3, windows 10, R 2.4.2, 64bit.

system(‘g++ -v’)
Using built-in specs.
COLLECT_GCC=c:\Rtools\mingw_64\bin\G__~1.EXE
COLLECT_LTO_WRAPPER=c:/Rtools/mingw_64/bin/…/libexec/gcc/x86_64-w64-mingw32/4.9.3/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: …/…/…/src/gcc-4.9.3/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/home/Jeroen/mingw-gcc-4.9.3/x86_64-493-posix-seh-rt_v3-s/mingw64 --with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-static --disable-shared --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-w64-mingw32-static --with-mpc=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-w64-mingw32-static --with-isl=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-w64-mingw32-static --with-cloog=/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion=‘x86_64-posix-seh, Built by MinGW-W64 project’ --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS=’-O2 -pipe -I/home/Jeroen/mingw-gcc-4.9.3/x86_64-493-posix-seh-rt_v3-s/mingw64/opt/include -I/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-zlib-static/include -I/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-w64-mingw32-static/include’ CXXFLAGS=’-O2 -pipe -I/home/Jeroen/mingw-gcc-4.9.3/x86_64-493-posix-seh-rt_v3-s/mingw64/opt/include -I/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-zlib-static/include -I/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-w64-mingw32-static/include’ CPPFLAGS= LDFLAGS=’-pipe -L/home/Jeroen/mingw-gcc-4.9.3/x86_64-493-posix-seh-rt_v3-s/mingw64/opt/lib -L/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-zlib-static/lib -L/home/Jeroen/mingw-gcc-4.9.3/prerequisites/x86_64-w64-mingw32-static/lib ’
Thread model: posix
gcc version 4.9.3 (x86_64-posix-seh, Built by MinGW-W64 project)

2

Hi, not an expert on this, but I guess you should have maximum optimization (-O3) in your makevars? I vaguely remember a thread with a similar problem (And a solution) somewhere here, but can’t find it quickly.

3

Yes, have tried with both 2 and 3… No noticeable difference.

4

I don’t know what all this 32 stuff is, but maybe it’s running a 32-bit compiler to produce 64-bit code? Is that what it was doing before?

You also want the -mtune=native flag to enable CPU-level vectorization.