MSVC support tracking issue #12056
Comments
|
I don't think blis and flame are realistic, given that every arch has good blas and lapack libraries. We could however just use the CBLAS interface and LAPACKe. |
|
Perhaps explore blis and flame in a package to see how they compare? |
|
at least two of those failures appear to be related to running an unpatched version of llvm (https://github.com/JuliaLang/julia/blob/master/deps/instcombine-llvm-3.3.patch and https://github.com/JuliaLang/julia/blob/master/deps/int128-vector.llvm-3.3.patch) or the corresponding disables in codegen.cpp (set if USE_SYSTEM_LLVM is set) the |
At this time you're right, with the exception that MSVC is not able to compile those good blas and lapack libraries. I did make a package to try out BLIS (mostly just copy-pasting
I may have done the MSVC build of LLVM prior to those patches. It takes a long time to build and I'm never quite sure what cmake arguments should be used so I haven't done it again. |
|
Tried to build but The real issue must come from the |
|
I am working on using cmake for OpenBLAS on Visual Studio. Because of different assembly syntax (AT&T vs Intel), I can only support pure C kernels on Visual Studio. |
|
Good to know @xianyi, it's a start anyway. Either in OpenBLAS or in BLIS, I hope someone who's heavily invested in being able to build using MSVC comes along and is able to support that effort. There might be automated ways of translating the assembly syntax, but would still need to be carefully validated. @joa-quim I suspect the problem is related to mount points and the MSYS2 path mangling, |
|
Hmm, V:/ is a RAM disk where I do all my buildings (including the MSVC some months ago) |
I believe the cygwin and msys2 syntax is |
|
MSYS2 does not use the |
|
As a test I built julia from scratch with mingw in V: so this path issue is a MSVC building issue only. @tkelman Do you build yours under |
|
Also tried by setting a symbolic link in C: but same type of error Don't get it why the .o is not created |
|
can you add |
|
The msys_build.sh already has
than it advances more but because it will create |
|
One other debug option then is to edit the compile (in deps/libuv) script as follows, and then change diff --git a/compile b/compile
index 531136b..cb95b37 100755
--- a/compile
+++ b/compile
@@ -255,7 +255,7 @@ EOF
echo "compile $scriptversion"
exit $?
;;
- cl | *[/\\]cl | cl.exe | *[/\\]cl.exe )
+ cmd | echo | cl | *[/\\]cl | cl.exe | *[/\\]cl.exe )
func_cl_wrapper "$@" # Doesn't return...
;;
esac
|
|
I am sorry but neither that makes it talk more Why is it complaining of a |
|
you also need to redirect the |
|
Ah, better and indeed I don't have that file, only a |
|
it looks like it might be helpful to try one of the c files directly, |
|
Sorry, you are right. I was just looking at it and (there is indeed a path translation problem) |
|
it looks the output path has gotten double-expanded. what shell are you using / what does |
It's the same that use the build julia with MinGW |
|
msys1 or msys2? (or from git) |
|
msys2 |
|
what does |
|
it screws the path |
|
ok, so it's a issue specific to interacting with msys2. what does |
|
should be fixed by 1986c50 |
|
I think that the solution to the BLAS and LAPACK problems is to find a way to use MinGW64-compiled BLAS and LAPACK from an MSVC-compiled Julia. Trying to use an MSVC-compiled BLAS/LAPACK will likely cause a huge performance penalty (unoptimized BLAS is much slower than tuned BLAS; same for LAPACK) and make Julia much less attractive on Windows. The only BLAS and LAPACK that play "nice" with MSVC is Intel's MKL. However, it is proprietary, and one needs an expensive license to redistribute it with applications. It gets even worse: the standard Julia distribution is under the GNU GPL (because of FFTW), and so a version linked to MKL could not be legally redistributed at all. The same licensing issues have an additional corollary: we may need to link to The other option is to ditch FFTW and find a FFT library with a better license. This still does not solve the problem of MSVC not being able to compile a decent BLAS, however – I consider requiring that users have ifort and MKL to build Julia with MSVC to be unacceptable. As far as compiling the BLAS and LAPACK libraries: I believe that there are two options:
Option 3 is the simplest, but has the problem of not playing well with embedding programs. The most likely answer to this – which is good practice anyway – is to make sure that Julia never allocates an object that must be freed by foreign code, and that Julia never needs to free an object allocated by foreign code (This is good practice on Windows in particular). |
That already pretty much works. All the linalg tests, and the blas tests, passed last time I ran them on an MSVC-built julia using a normal MinGW-w64-built OpenBLAS. Mixing toolchains is just messy.
Yeah, I'm not proposing using unoptimized BLAS. If @xianyi can only get pure C kernels to work at first in an MSVC-built OpenBLAS, that's a start towards the currently impossible task of building an optimized open source BLAS implementation with MSVC. Maybe BLIS or an inline generated LLVM BLAS will be the future here, we'll have to see.
I believe the story on the new CRT in MSVC 2015 is going to get better here in terms of being part of the OS.
We already have a no-GPL optional build flag that disables FFTW, and plans to move FFTW out to a package before too much longer, and a PR with a pure-Julia MIT-licensed FFT implementation. Some of the Windows-only dependencies need to be tweaked to respect the no-GPL build flag though, Git (which is going to be replaced by libgit2 anyway) and busybox and possibly others.
Why would an MSVC-built Julia need to link to GCC runtimes at all? libjulia and julia.exe are not linked to blas or lapack or any other Fortran dependencies, we only ever use them dynamically through ccall. |
|
This build process appears to have been broken by the usage of |
|
I need a slightly modified patch for master but I tested this as recently as a day or two ago and it was still working edited the top post with a link to the new patch, works fine at fdee9f4 |
|
This has some very vague info that MS seems to be working on a Clang frontend coupled with the normal MSVC backend. Probably not helpful for this issue per se, but I thought it sounded interesting. |
|
edit: looks like rearranging the includes can fix this, oh joy msvc |
|
I looked at compiling LLVM with MSVC 2015. Compiler-rt built successfully, I am not too sure if builtins were included. Could not see an option to enable or disable them in the cmake gui. There is a clang frontend for msvc called clang c2 which uses the clang frontend with the Microsoft backend. This is due with VS2015 update 1 which should be released around November [2]. From discussions I saw that this may provide a way to use c99/11 with the Microsoft backend. Would that not help this issue? One problem may be windows specific code but until the tool is actually released this is all speculation. [3] [1] https://connect.microsoft.com/VisualStudio/feedback/details/1551173/msvc-2015-complex-hs-complex-i-macro-does-not-conform-to-the-standard |
|
@Mike43110 which version of LLVM did you build? Clang/C2 may help a bit with the remaining missing C99 pieces, though I think using full Clang with the LLVM backend would be more useful as they get Windows exception handling finished and become fully usable for self-building LLVM and our other C++ deps. The question is how well is the gcc-style clang frontend supported on Windows. If there's a real advantage in debuginfo or MSVC compatibility with eventually using Clang instead of g++ we could switch the (or add alternative) Windows builds, but the Clang toolchain would have to be as easy to get and fit with the build system like g++ does now. MSVC, and the MSVC-compatible clang-cl frontend, and in all likelihood Clang/C2, all require messy build system hacks to get working right now and would eventually be better suited to build via CMake than MSYS and gmake. What will be useful is what's mentioned at the very tail end of http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/
|
|
I built svn with Visual Studio 2015. Assertions off, no tests or docs built. CMake will be very nice once clang-cl or clang c2 is ready. I will play around with it once it is released. It would be interesting comparing clang/llvm vs clang/msvc performance. CMake will probably be necessary though for building as you stated right now. I tried to get the msvc build going but I could not even get past the libuv stage. No idea why but not too bothered as there is the WIP CMake PR. I have wondered if building llvm and clang (and lldb at some stage too) then using them to build Julia would not be a bad idea. Especially with cxx. Pkg could then also rely on clang instead of using gcc for builds unless explicitly stated. On windows I can get the clang toolchain very easily (unless I am missing something right now) by just downloading the installer. The build only toolchain did not have a timeframe. It was mentioned in the slides but I think it will be before the end of the year. If there are any build flags needed for building a Julia compatible llvm please mention them. I can regularly build llvm with msvc on my spare PC. |
|
I'm not positive what cmake flags we would need to get an msvc or windows clang built llvm set up correctly for julia. Will depend on how things look once we start looking into and fixing various test failures. Does the clang for windows toolchain work on a clean system that does not have visual studio? Does it have the clang.exe gcc style front end? Last time I checked the installer does not come with the llvm static libraries, which we could even use to avoid having to rebuild llvm. Maybe we should ask a few more times and figure out how their installer generation scripts work to help make that happen sooner. |
|
Hi all, I released OpenBLAS 0.2.15, which supports MSVC by cmake. However, it only can build the c kernels and the performance is not good now. |
|
Thanks @xianyi, we're now using 0.2.15 on master. I haven't tried the MSVC CMake build yet but when I do we'll let you know if there are any issues. On LLVM's ability to generate native debug info, some good news: https://github.com/Microsoft/microsoft-pdb |
|
Gotta love that Microsoft is getting on the LLVM train. |
|
I hope LLVM+Visual Studio+CMake can solve the assembly issue. |
|
@davidanthoff , is it Clang/C2 release? |
|
It doesn't mention it, so I assume no, but not sure. |
|
Has a walk through on how to use the Clang frontend with the MS codegen backend. |
|
No inline assembly support (yet). |
|
Other than maybe slightly better performance, I'm not sure what the benefit would be for going through Clang with Microsoft codegen if Clang with LLVM codegen is capable of the same level of support for exception handling, MSVC ABI compatibility, and MSVC debug info compatibility. |
|
Once Clang\LLVM or Clang\MSVC are fully working would it not be possible to ignore msvc completely? Both of the available options would at least have much better C standards support than the MSVC frontend. Are there any other benefits that I am missing? I would hope being able to ignore the msvc frontend would be able to reduce the required effort to keep windows support working properly. I did a quick test with the LLVM install sans Visual Studio. Biggest issue is that the llvm install includes no stdlib so either the msvc or mingw one has to be used on Windows. There seems otherwise to be no immediate issues. |
|
We aren't going to be doing this and removed some very old build files for MSVC support in 584d412 |
@kshyatt asked me to write down the current state of affairs w.r.t. building Julia using MSVC. Building master as of fdee9f4 works with VS 2013 after applying msvc-bootstrap.patch and msvc-sysimg4.patch
(or msvc-sysimg3.patch for release-0.4) using the following hacky build process that I'm not proud of, copied from the first post in #7761:
cd "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC"vcvarsall x86_amd64cdto your MSYS installation, whichever foldersh.exeis located in (eitherbinorusr/bindepending whether you're using MSYS1 or a recent MSYS2 - best to use msysgit here, otherwise you'll likely get an error message due to the MSYS version oflink.exeshowing up first in the path, and MSYS2 has been reported not to work here)set MSYSTEM=MINGW32sh --logincdto your Julia directory, checkout latest master (if you have an existing mingw build here, best to start from a separate clean clone)ARCH=x86_64 USEMSVC=1 contrib/windows/msys_build.shThe build process would eventually get better if we port the build system to cmake as an alternative option to GNU make, see #11754. My hacky script downloads a Julia nightly binary, which is itself compiled on our buildbots via the Cygwin cross-compilation process as documented in README.windows.md, and extracts out the MinGW-w64-built dependency dll's from it. It also downloads an MSVC 2013 binary build of LLVM 3.3 that I made some time ago.
The first patch is necessary because MSVC does not have some 128-bit integer intrinsics that are needed for
Int128support in Julia. In versions of LLVM newer than 3.3, we may be able to get those intrinsics from the compiler-rt library in LLVM. I have not managed a build of that yet myself though. The second patch is necessary to work around the lack of a comdat section in the system image object file - with LLVM 3.5 or newer that should not be necessary, we could use the MSVC linker for sys.dll with a different patch that could be merged to master.If you can reproduce my steps above, then a failure to compile libccalltest is expected because MSVC does not support C99 complex https://connect.microsoft.com/VisualStudio/feedback/details/891891/c99-complex-number-support. The resulting MSVC-built Julia executable needs to be run as
usr/bin/julia -J usr/lib/julia/sys.jifor now due to the sysimg patch.Aside from documenting the above in a central place, the purpose of this issue is to track remaining items before we could call MSVC (and even expand to ICC + ifort on Windows) a first-class supported build platform and document it as an alternative to MinGW-w64.
@msvc_onlymacrofcallImplement fcall #2167 if we want to makeifortor MKL work on Windows - or entirely replace our Fortran dependencies via https://github.com/flame/blis and https://github.com/flame/libflame?Anything else I forgot? Success or failure stories are welcome if anyone wants to test this. Trying out VS 2015 and/or LLVM 3.7 or svn and determining what patches would be required to make those work would also be worth doing if anyone wants to help get this to a more usable state.
The text was updated successfully, but these errors were encountered: