stan-dev / cmdstan

CmdStan, the command line interface to Stan
https://mc-stan.org/users/interfaces/cmdstan
BSD 3-Clause "New" or "Revised" License
212 stars 93 forks source link

Explore RTools 4v2 #1064

Closed rok-cesnovar closed 8 months ago

rok-cesnovar commented 3 years ago

Description:

RTools 4v2 offers the use of g++ 10.3 with UCRT (Universtal C Runtime) in addition to the mingw g++ 8.3, which we currently recommend. UCRT is what Visual Studio now uses by default as opposed to MSVCRT (Microsoft Visual C++ Runtime), which was the default before.

We know that Stan/Stan Math did not work with MSVCRT in the past and I dont think anyone has checked whether that is still true with the recent versions (at least no one has stated so publicly).

We should explore using UCRT to see whether it brings us any closer to the performance on Unix systems (if it works at all).

I have checked and mingw32-make is available for installation with UCRT, so theoretically, everything Stan needs is there.

Things to look at:

I rarely use Windows nowadays and not sure when I will be able to get to this, so if anyone has time and the energy to try this out, you are very welcome.

Current Version:

v2.28.2

WardBrian commented 3 years ago

I have access to a couple windows machines and can make time to do this. Do you have example models you'd like me to test? I can compare with an older RTools and the conda installation (uses slightly different mingw versions), and even WSL if we'd like

rok-cesnovar commented 3 years ago

Hmm, I don't really have a batch of tests to run that. Will gather a few models&data that were known to be a lot faster on WSL.

RTools 4v2 install both the MinGW and UCRT versions, so this will not require installing an older version of Rtools. The test should be something like:

Will prepare a script to make this easy. It should include:

WardBrian commented 2 years ago

A script isn't strictly necessary if you have the models and data already, but it might be a nice thing to have for future questions like this

WardBrian commented 2 years ago

I've tried this today and the basic stuff all seems to work out, but it chokes on TBB. I should note that I'm just trying to use the rtools version of make, there is no mingw32-make available in the distribution so far as I can tell

tjmahr commented 2 years ago

there is no mingw32-make available in the distribution so far as I can tell

Confirmed.

$ pacman -Ss make$
mingw32/mingw-w64-i686-bmake 20181221-8
    Portable version of the NetBSD make build tool
mingw32/mingw-w64-i686-cmake 3.23.0-1
    A cross-platform open-source make system (mingw-w64)
mingw32/mingw-w64-i686-dmake 4.12.2.2-1
    Dmake is a make utility similar to GNU make or the Workshop dmake (mingw-w64)
mingw32/mingw-w64-i686-make 4.3-1 (mingw-w64-i686-toolchain)
    GNU make utility to maintain groups of programs (mingw-w64)
mingw32/mingw-w64-i686-premake 5.0a16-1
    A simple build configuration and project generation tool (mingw-w64)
mingw32/mingw-w64-i686-xmake 2.6.4-1
    A cross-platform build utility based on Lua (mingw-w64)
mingw64/mingw-w64-x86_64-bmake 20181221-8
    Portable version of the NetBSD make build tool
mingw64/mingw-w64-x86_64-cmake 3.23.0-1
    A cross-platform open-source make system (mingw-w64)
mingw64/mingw-w64-x86_64-dmake 4.12.2.2-1
    Dmake is a make utility similar to GNU make or the Workshop dmake (mingw-w64)
mingw64/mingw-w64-x86_64-make 4.3-1 (mingw-w64-x86_64-toolchain)
    GNU make utility to maintain groups of programs (mingw-w64)
mingw64/mingw-w64-x86_64-premake 5.0a16-1
    A simple build configuration and project generation tool (mingw-w64)
mingw64/mingw-w64-x86_64-xmake 2.6.4-1
    A cross-platform build utility based on Lua (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-bmake 20181221-8
    Portable version of the NetBSD make build tool
ucrt64/mingw-w64-ucrt-x86_64-cmake 3.23.0-1
    A cross-platform open-source make system (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-dmake 4.12.2.2-1
    Dmake is a make utility similar to GNU make or the Workshop dmake (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-make 4.3-1 (mingw-w64-ucrt-x86_64-toolchain)
    GNU make utility to maintain groups of programs (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-premake 5.0a16-1
    A simple build configuration and project generation tool (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-xmake 2.6.4-1
    A cross-platform build utility based on Lua (mingw-w64)
clang64/mingw-w64-clang-x86_64-bmake 20181221-8
    Portable version of the NetBSD make build tool
clang64/mingw-w64-clang-x86_64-cmake 3.23.0-1
    A cross-platform open-source make system (mingw-w64)
clang64/mingw-w64-clang-x86_64-dmake 4.12.2.2-1
    Dmake is a make utility similar to GNU make or the Workshop dmake (mingw-w64)
clang64/mingw-w64-clang-x86_64-make 4.3-1 (mingw-w64-clang-x86_64-toolchain)
    GNU make utility to maintain groups of programs (mingw-w64)
clang64/mingw-w64-clang-x86_64-premake 5.0a16-1
    A simple build configuration and project generation tool (mingw-w64)
clang64/mingw-w64-clang-x86_64-xmake 2.6.4-1
    A cross-platform build utility based on Lua (mingw-w64)
msys/automake-wrapper 11-4
    Wrapper scripts for automake and aclocal
msys/cmake 3.22.1-2
    A cross-platform open-source make system
msys/colormake-git r8.9c1d2e6-1
    Colorized build output
msys/icmake 9.03.01-1
    A program maintenance (make) utility using a C-like grammar
msys/make 4.3-3 (base-devel) [installed]
    GNU make utility to maintain groups of programs
msys/remake 4.3+dbg1.5-2
    Enhanced GNU Make - tracing, error reporting, debugging, profiling and more
rok-cesnovar commented 2 years ago

To run CmdStan with Rtools42 you need to do the following (This assumes Rtools42:

  1. Add C:\rtools42\usr\bin and C:\rtools42\ucrt64\bin to the PATH
  2. Run pacman -Sy mingw-w64-ucrt-x86_64-make mingw-w64-ucrt-x86_64-gcc in a freshly opened Powershell
  3. Add the following two lines to the make/local:
CXXFLAGS += -Wno-nonnull
TBB_CXXFLAGS= -U__MSVCRT_VERSION__ -D__MSVCRT_VERSION__=0x0E00

And that should do it.

Explanation of the steps:

The second step installs ucrt64 versions of mingw32-make and g++ (11.2) that are not installed by default. RTools42 by default uses mingw32.static.posix for which we can not install mingw32-make.

The first line we need to add to make/local is to silence some warnings caused by TBB with g++ 11. Newer versions of TBB do not spit out this warning.

The second line to make/local is due to a bug in MinGW that incorrectly sets the version of MSVCRT which causes the compiler to think it does not have support for some functions, though it does have it - this mainly affects std::at_quick_exit and std::quick_exit. That causes errors like the one here. This had been fixed in MinGW as I can see here but seems to not make its way into Rtools42 I guess. We should report this to Rtools I think, though I am not sure where is the best place to do that.

jonaudet commented 2 years ago

Hi, sorry to resurrect an older issue, I recently upgraded to R 4.2 (& RTools 4.2) since I was a few versions behind. As was pointed out earlier, TBB appears to be the issue. It seems to fail at creating the version_string.ver file:

cmd /C cscript /nologo /E:jscript ../tbb_2020.3/build/version_info_windows.js gcc intel64 "g++ -O2 -DUSE_WINTHREAD -D_WIN32_WINNT=0x0502 -DMINGW_HAS_SECURE_API=1 -D__MSVCRT_VERSION__=0x0700 -msse -mthreads -m64 -mrtm  -Wall -U__MSVCRT_VERSION__ -D__MSVCRT_VERSION__=0x0E00 -DTBB_SUPPRESS_DEPRECATED_MESSAGES=1  -std=c++1y -I../tbb_2020.3/src -I../tbb_2020.3/src/rml/include -I../tbb_2020.3/include" > version_string.ver
The system cannot find the path specified.
The system cannot find the path specified.
../tbb_2020.3/build/common_rules.inc:160: recipe for target 'version_string.ver' failed

That remains true after following the instructions above by @rok-cesnovar, I still get the same issue. (I put the local file in the make directory of both cmdstan and tbb_2020.3. Apparently, this is what gets outputted to that file:

#define __TBB_VERSION_STRINGS(N) \
#N ": BUILD_HOST\t\tComputerName" ENDL \
#N ": BUILD_OS\t\tMicrosoft Windows [Version 10.0.19044.1766]" ENDL \
#N ": BUILD_GCC\t\tgcc (Rev2, Built by MSYS2 project) 12.1.0" ENDL \
#N ": BUILD_TARGET\tintel64" ENDL \
#N ": BUILD_COMMAND\tg++ -O2 -DUSE_WINTHREAD -D_WIN32_WINNT=0x0502 -DMINGW_HAS_SECURE_API=1 -D__MSVCRT_VERSION__=0x0700 -msse -mthreads -m64 -mrtm  -Wall -U__MSVCRT_VERSION__ -D__MSVCRT_VERSION__=0x0E00 -DTBB_SUPPRESS_DEPRECATED_MESSAGES=1  -std=c++1y -I../tbb_2020.3/src -I../tbb_2020.3/src/rml/include -I../tbb_2020.3/include" ENDL
#define __TBB_DATETIME "Tue, 28 Jun 2022 15:24:06 UTC"
#define __TBB_VERSION_YMD 2022, 0628

Is that what it is supposed to look like? I also get a bunch of "The system cannot find the path specified" which may not be an issue, as running the command without the redirect yields the above text.

marianklose commented 11 months ago

To run CmdStan with Rtools42 you need to do the following (This assumes Rtools42:

  1. Add C:\rtools42\usr\bin and C:\rtools42\ucrt64\bin to the PATH
  2. Run pacman -Sy mingw-w64-ucrt-x86_64-make mingw-w64-ucrt-x86_64-gcc in a freshly opened Powershell
  3. Add the following two lines to the make/local:
CXXFLAGS += -Wno-nonnull
TBB_CXXFLAGS= -U__MSVCRT_VERSION__ -D__MSVCRT_VERSION__=0x0E00

And that should do it.

Explanation of the steps:

The second step installs ucrt64 versions of mingw32-make and g++ (11.2) that are not installed by default. RTools42 by default uses mingw32.static.posix for which we can not install mingw32-make.

The first line we need to add to make/local is to silence some warnings caused by TBB with g++ 11. Newer versions of TBB do not spit out this warning.

The second line to make/local is due to a bug in MinGW that incorrectly sets the version of MSVCRT which causes the compiler to think it does not have support for some functions, though it does have it - this mainly affects std::at_quick_exit and std::quick_exit. That causes errors like the one here. This had been fixed in MinGW as I can see here but seems to not make its way into Rtools42 I guess. We should report this to Rtools I think, though I am not sure where is the best place to do that.

Just to let you know: I was running into the same issue with a fresh RTools version 4.3 installation and this fixed it for me. Thank you!

WardBrian commented 8 months ago

We have been using these newer RTools for a bit now, so I think we can close this issue