Skip to content

Numerical software on Windows

Matthew Brett edited this page Apr 11, 2014 · 32 revisions

Introduction

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.

Open-source numerical software

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.

BLAS / LAPACK libraries

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 terms. 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. 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:

    1. 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. Appears to have only three active developers. Some worries about bugs and lack of tests.

  • 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.

Fortran

The options for a 64-bit Fortran compiler on Windows are:

  • Cygwin gfortran
  • MinGW64 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.
  • 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.

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.

Mixing Cygwin / MinGW and Visual Studio

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-64 lacks intrinsic support for choosing MSVC runtimes 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.

Unix-like build systems

  • Cygwin contains a full range of Unix build tools. However, by default, builds on Cygwin link to 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
  • msys provides a build toolchain including the MinGW set of GNU compiler tools. MinGW tries to link against Microsoft C run-time libraries.
  • msys2 is the current development version of MSYS, and supports 64-bit compilation using the MinGW64 32 and 64-bit GNU compilers. However, it is experimental and changes rapidly.

Another option is using cross-compilers like MXE. MXE does MinGW builds from Linux.

An aside - finding DLLs

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_PATH flag to the DLL loading call LoadLibraryEx. 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.

Building installers for numerical libraries on Windows

Numpy / scipy

See Building numpy / scipy.

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.

R

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:

Octave

See Octave for Windows and Octave-forge Windows directory.

Octave binary releases are behind Windows 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 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

Sage

See installing sage from source

Sage can only be built on Cygwin on Windows. Uses:

Scilab

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:

Julia

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