-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Numerical software on Windows
This is a survey of the build dependencies of numerical software on Windows.
Fast numerics need optimized libraries for BLAS and LAPACK. They also need a Fortran compiler to make use of standard Fortran numerical libraries.
Most numerical programming development happens in Unix, and most open-source
software is cross-platform. Building many numerical libraries needs a
Unix-like build system such as make and autoconf.
A selected list:
- numpy and scipy numerical libraries for Python
- R language for statistical computing
- GNU Octave numerical computing language
- Sage mathematics software system
- Scilab software for numerical computation
- Julia dynamic programming language for technical computing
All of these need to compile Fortran code and use BLAS / LAPACK libraries - see below.
See Visual Studio page on Wikipedia. This is the platform compiler for Windows. Express edition is free to download. Compiles C and C++, but Microsoft does not make a Fortran compiler.
See MSVC and Python for a list of MS Visual C versions and download links.
Free x86 and AMD64 (x86-64) VC90 c-compilers for Python-2.7 are now available from Microsoft.
Cygwin is a Unix-like environment on Windows. It includes the full GNU compiler collection and the Unix build tools. gcc compilers link against a C runtime in a Cygwin-specific DLL providing a POSIX compatibility layer. This can cause problems when different libraries compile against different versions of the DLL. It is easy to run into problems with multiple copies of the DLL
MinGW is a port of of the GNU compiler collection to Windows that links against the Microsoft C runtime libraries. It is 32-bit only.
See MingGW-w64 sourceforge page and section in MinGW wikipedia article
Another port of of the GNU compiler collection to Windows implementing multilib (32- and 64- bit compilation from the same compiler).
Much younger than the MinGW project, and under rapid development.
See Intel C compilers. Seem to be somewhere upward of $1000 for Windows C compiler.
The Intel developer license agreement says:
D. DISTRIBUTION: Distribution of the Redistributables is also subject to the following limitations:
[clauses i through iii omitted]
(iv) shall use a license agreement that prohibits disassembly and reverse engineering of the Redistributables,
(v) shall indemnify, hold harmless, and defend Intel and its suppliers from and against any claims or lawsuits, including attorney's fees, that arise or result from your distribution of any product.
"Redistributables" does appear to cover run-time DLLs, it wasn't immediately clear to me (MB) whether it referred to statically linked object code.
See below for discussion of Intel Fortran compiler.
This is a list of Windows libraries offering BLAS and / or LAPACK with the CBLAS C language wrappers:
-
Intel Math Kernel Library - MKL. Good performance on benchmarks across the range, except on AMD processors. Costs "from $499" per machine in simultaneous use. Linkable files can be redistributed with open-source applications, but with these restrictions from the MKL license:
D. DISTRIBUTION: Distribution of the Redistributables is also subject to the following limitations:
[clauses i through iii omitted]
(iv) shall use a license agreement that prohibits disassembly and reverse engineering of the Redistributables,
(v) shall indemnify, hold harmless, and defend Intel and its suppliers from and against any claims or lawsuits, including attorney's fees, that arise or result from your distribution of any product.
In practice this makes it impossible to release a binary compilation of an MKL linked project under an unmodified open-source license. Open source projects often want to allow automated installation without needing explicit agreement to license terms, and this would not conform to the MKL license. Even with the modified license, the open-source developer has to take responsibility for legal fees that they are unlikely to be able to pay.
See discussions about MKL on numpy mailing list and MKL on Julia issues.
-
AMD Core Math Library - ACML. It is free of cost to use, and appears to perform roughly as well as the MKL in some tests, and moderately worse in others. It does not contain cblas interface. Binaries linked against ACML have to conform to the ACML license, which, as for the MKL, requires software linked to the ACML to subject users to the ACML license terms including:
- Restrictions. The Software contains copyrighted and patented material, trade secrets and other proprietary material. In order to protect them, and except as permitted by applicable legislation, you may not:
a) decompile, reverse engineer, disassemble or otherwise reduce the Software to a human-perceivable form;
b) modify, network, rent, lend, loan, distribute or create derivative works based upon the Software in whole or in part [...]
-
Netlib reference implementation - netlib BLAS, netlib LAPACK. Most available benchmarks (e.g R benchmarks, BLAS LAPACK review) show the reference BLAS / LAPACK to be considerably slower than any optimized library.
-
GotoBLAS2. A library written by Kazushige Goto, and released under a BSD license, but no longer maintained. Goto now works for Intel. At or near the top of benchmarks on which it has been tested (e.g BLAS LAPACK review, Eigen benchmarks). Like MKL and ACML, GotoBLAS2 chooses routines at runtime according to the processor. Does not detect modern processors (after 2011).
-
OpenBLAS Fork of GotoBLAS2 updated for newer processors. Actively merging pull requests. Some recent worries about bugs and lack of tests on the numpy mailing list and the octave list
-
Automatically tuned linear algebra software ATLAS. BSD license. Uses comprehensive tests of parameters on a particular machine to chose from a range of algorithms to optimize BLAS and some LAPACK routines. Modern versions (>= 3.9) perform reasonably well on benchmarks. Each ATLAS build is optimized for a particular machine (processor capabilities, L1 / L2 cache size, memory speed), and ATLAS does not select routines at runtime but at build time, meaning that a default ATLAS build can be badly optimized for a particular processor. ATLAS is difficult to build on Windows, and is not well optimized for Windows 64 bit.
-
BLIS: "BLIS is a software framework for instantiating high-performance BLAS-like dense linear algebra libraries". BSD license. It can be compiled into a BLAS library. As of writing (April 2014) Windows builds are experimental. BLIS does not do run-time hardware detection.
-
COBLAS - "Reference BLAS library in C99", BSD license. A quick look at the code in April 2014 suggested it used very straightforward implementations that are not highly optimized.
The options for a 64-bit Fortran compiler on Windows are:
- Cygwin gfortran
- MinGW-w64 gfortran
- Intel Fortran. "From $849". This Intel document on redistribution appears to say that binaries built with Intel Fortran have no extra license restrictions unless they link to any of: the IMSL numerical library; the MKL; the Intel Performance Primitives; or the Intel Threading Building Blocks. For any of these libraries, terms similar to the MKL license apply - users must agree not to reverse engineer the libraries, and you must agree to pay for Intel's lawyers if Intel gets sued.
- Portland Group Visual Fortran. Free license offer for US and German academics until June 30th 2014. License for run-time files is similar to MKL license making it very unattractive for open source development. Standard cost appears to be $140 for a single seat Academic license.
- Absoft (from $289 academic, $697 commercial).
- gfortran from Fortran tools for Windows
- NAG Fortran builder
- Lahey Fortran - from $175 for an educational license for Lahey / GNU Fortran.
- Simply Fortran - GNU Fortran with an IDE and package manager. It is free to download, but will disable some of the features of the IDE after 30 days unless you register. Registration costs $99.
If all Fortran code is compatible with Fortran 77, it is also possible to compile the Fortran code with a C compiler by converting the Fortran code to C with f2c.
Various problems can arise - see OpenBLAS with VS and MSVC and MinGW DLLs for examples.
Applications and DLLs have to make sure that they do not use different MSVC runtime libraries in the same process.
MinGW-w64 lacks intrinsic support for choosing MSVC run-times as a gcc option. For example, Python 3.3 was compiled with MSVC 10 (VS 2010). A Python extension will be in the same process as Python, and so will also need to link against the MSVC 10 run-times.
The workaround is to create and patch the gcc specs file for the particular MSVC runtime you want to link against.
- Cygwin contains a full range of Unix build tools.
- msys is "a collection of GNU utilities such as bash, make, gawk and grep to allow building of applications and programs which depend on traditionally UNIX tools to be present. It is intended to supplement MinGW and the deficiencies of the cmd shell." MSYS can also be used with MinGW-w64. It contains make and autoconf and a minimal bash shell.
- msys2 is "an updated, modern version of MSYS, both of which are Cygwin (POSIX compatibility layer) forks with the aim of better interoperability with native Windows software." It can install MinGW-w64 from its own package manager.
Another option is using cross-compilers like MXE. MXE does MinGW builds from Linux.
If a program tries to load a DLL called mylibrary.dll, Windows has to
decide which directories it should search for mylibrary.dll.
Applications and libraries often need to ship DLLs, and they need to make sure the application / libraries finds the correct version.
One place that Windows looks for DLLs is on the system $PATH (the %PATH%
variable in cmd.exe, or $env:PATH in Powershell). It is not safe in
general to put our own mylibrary.dll into some system directory like
WINDOWS/system because another application may depend on a different
version of the DLL that is also called mylibrary.dll.
For reference here is the standard DLL search algorithm. See this exploration of DLL search settings for more explanation.
Alternative strategies for finding the right DLL are:
-
Putting the required DLL in the same directory as the calling executable, assuming the standard search order is in place.
-
Using the
LOAD_WITH_ALTERED_SEARCH_PATHflag to the DLL loading callLoadLibraryEx. In this case you get the alternate DLL search algorithm, which looks in the directory containing the loading DLL instead of the directory containing the calling executable. -
Setting an extra DLL search directory with SetDllDirectory. The Microsoft documentation on the LoadLibraryEx call says this about
SetDllDirectory:However, be aware that using SetDllDirectory effectively disables safe DLL search mode while the specified directory is in the search path and it is not thread safe. If possible, it is best to use AddDllDirectory to modify a default process search path.
See the standard DLL search algorithm for more detail on safe DLL search mode.
-
Adding a specific directory to the search path with AddDllDirectory. This only works for updated Windows 7 and later.
-
Using private assemblies to specify a set of DLLs specific to the application.
Standard Windows compile uses:
- MinGW or Cygwin for build tools
- ATLAS for BLAS / LAPACK
- MinGW or Cygwin for Fortran
Standard numpy and scipy binary releases on Windows use pre-compiled ATLAS libraries and are 32-bit only because of the difficulty of compiling ATLAS on 64-bit Windows. Because of the problem of locating DLLs, ATLAS is linked statically.
See building R from source and R Windows toolset.
In the Windows toolset page, a typical quote:
We have found that the build process for R is quite sensitive to the choice of tools: please follow our instructions exactly, even to the choice of particular versions of the tools
The R build depends on a customized set of Windows tools for R. These include copies of Cygwin command line tools and a copy of the MinGW-w64 toolchain
So, R uses:
- MinGW / Cygwin copies for build tools
- Copies of reference BLAS
- MinGW for Fortran
See Octave for Windows and Octave-forge Windows directory.
Octave Windows binary releases on the main sourceforge site are behind compared with Mac (3.6.4 vs 3.8.0). The top of the Octave Windows page says:
GNU Octave is primarily developed on GNU/Linux and other POSIX conformal systems. The ports of GNU Octave to Windows use different approaches to get most of the original Octave and adapt it to Microsoft Windows idiosyncrasies (eg: dynamic libraries, file paths, permissions, environment variables, GUI system, etc). Bear this in mind and don't panic if you get unexpected results.
There is a current Octave build for windows using the MXE cross compiler.
Tools, BLAS and Fortran use are a little confusing across the range of Octave builds:
- There appear to be Octave builds with MinGW, Cygwin and MSVC. The current MinGW builds look like they are 32-bit. Approach seems to be to specify a custom MSYS / MinGW environment via install.cmd scripts to get dependencies. MSVC builds apparently need MSYS - see this email thread.
- BLAS is both of (choice of) OpenBLAS and ATLAS
- MinGW builds use gfortran. It's not clear to me (MB) how the MSVC builds deal with Fortran. They may use MinGW gfortran - see links in this thread
See installing sage from source
Sage can only be built on Cygwin on Windows. Uses:
- Cygwin for build chain
- Blas from ATLAS
- Fortran from gfortran
See compiling scilab for Windows
The instructions include this command to checkout requirements for Windows:
svn export --force --username anonymous --password Scilab svn://svn.scilab.org/scilab/trunk/Dev-Tools/SE/Prerequirements/Windows scilab
This fetches a large number of Windows binary packages that appear to include compiled reference BLAS, ATLAS, OpenBLAS, MKL, Python, java.
So:
- MSVC for build chain
- One of reference BLAS, ATLAS, OpenBLAS, MKL
- Intel Fortran XE 2011 or f2c for Fortran sources.
See building juilia on Windows
Julia uses MinGW-builds - binary builds of dual 32- / 64-bit MinGW compilers.
- MinGW-builds / MSYS2 or MinGW-builds / MSYS for Unix build tools
- OpenBLAS compiled as part of the build process
- Fortran by gfortran