Native Library Interface

Our Native Library Interface (NLI) is a thin .NET wrapper around native numerical libraries. It allows .NET developers to access native numerical libraries without having to write their own P/Invoke calls or generate versions of native libraries that are P/Invoke compatible. It is a thin wrapper, since it does not validate the arguments used (just passes them through) and tries to keep the interface as close as possible to the original library. The library is licensed under a BSD license.

The NLI currently wraps all the BLAS routines and a handful of LAPACK routines from ATLAS/CLAPACK, AMD's ACML, and Intel's MKL. We will be wrapping more LAPACK routines and additional native libraries in the future. In addition to the .NET wrapper, the NLI includes a script that automatically builds a combined ATLAS/CLAPACK shared library (DLL) for Microsoft Windows or Linux systems.
ATLAS / CLAPACK Notes

WARNING: The QR and SVD routines dormqr, dgeqrf, dgeqp3, and dgesvd are UNSTABLE under Windows. They will randomly crash with a null pointer or corrupted memory exception. We don’t recommend using the NLI with CLAPACK under Windows.

To build a combined ATLAS/CLAPACK DLL/shared library that will work with our Native Library Interface, you must use one of our build scripts (buildwindows.sh or buildlinux.sh). These scripts will download all necessary files, compile ATLAS and CLAPACK, and then link them into a DLL/shared library. The directory to build the DLL in is specified by the BUILD_DIR script variable. This variable is located at the top of the script.

NOTE: There is a problem building ATLAS with gcc 4.x. See at the end of the page on how to build ATLAS with gcc 4.x.

build_windows.sh can only be ran under Cygwin (http://www.cygwin.com/) on MS Windows. The script requires that make, gcc-core, gcc-g++, gcc-f77, sed, and wget be installed with Cygwin. After you invoke the script and the script downloads the ATLAS source package, you will be prompted to answer questions regarding your setup. Once you have answered the questions, the script will not prompt you for any further information. The build time varies with from machine to machine and may take up to one hour to build on slower machines.

Windows: build_windows.sh will create a DLL named atlas.dll. The DLL should be placed in the same directory as your application, somewhere in your path, or into a Windows system directory, such as c:\windows\system32.

Linux: buildlinux.sh will create a shared library named libatlas.so. The library should be placed into directory where Mono can locate the library, such as somewhere listed in your LDLIBRARY_PATH, /lib/ , or /usr/lib . See this Mono help page for more for more information. You will need to add this dllmap line to the configuration section of your Mono configuration file (i.e.: $prefix/etc/mono/config): <dllmap dll=”atlas.dll” target=”libatlas.so”> $prefix is the prefix used when you installed mono. By default $prefix is nothing, and the config file is /etc/mono/config .

Building ATLAS using gcc 4.x:

  • comment out this line in the build script.<BR>rm -rf ATLAS CLAPACK
  • extract ATLAS to your build directory.
  • move the prototype of ATL_L2GE on lines 67 and 68 of ATLAS/bin/uumtst.c to before the start of the function.
  • run the script

Intel's Math Kernel Library Notes

To create a DLL that is compatible with the Native Library Interface, we need to use the MKL custom DLL builder tool. This directory contains a file named function_list. This file contains a list of functions that the DLL should export (all BLAS and LAPACK routines).

Windows:
  • Start a VS 2003 command line prompt.
  • cd to where the custom builder tool is installed.
  • Enter this command to generate mkl.dll (the DLL must be named mkl.dll): nmake ia32 export=&lt;location to functionlist&gt;/functionlist name=mkl

example: nmake ia32 export=d:\dnAnalytics\nli\trunk\NativeCode\MKL\function_list name=mkl Note: The custom DLL builder has a problem with VS 2005. It seems that it doesn’t embed the manifest correctly, so at runtime we get error R6034.

Linux:
  • cd to where the custom builder tool is installed. The directory must be writable by you.
  • enter this command to generate libmkl.so (the library must be named libmkl.so): make ia32 export=&lt;location to functionlist&gt;/functionlist name=mkl example: make ia32 export=/dnAnalytics/nli/trunk/NativeCode/MKL/function_list name=libmkl
  • add this line to $prefix/etc/mono/config:<BR><BR>&lt;dllmap dll=”mkl.dll” target=”libmkl.so”/&gt;

$prefix is the prefix used when you installed mono. By default $prefix is nothing, and the config file is /etc/mono/config. move or copy libmkl.so and libguide.so to somewhere where Mono can find them, such as somewhere listed in your LDLIBRARYPATH, /lib/, or /usr/lib. See this Mono help page for more for more information.

AMD's ACML Notes

You can download AMD’s ACML from http://developer.amd.com/acml.aspx. NOTE: ACML only supports column major matrices. The library will throw a NotSupportedException if BlasOrderType.Row is used.

32-bit Windows: The library has been tested with the versions compiled with Intel’s FORTRAN compiler and Compaq Visual FORTRAN (CVF). In order to use the CVF build of ACML, you need to install the CVF runtime libraries. The runtime libraries can be downloaded from: ftp://ftp.compaq.com/pub/products/fortran/vf/VFRUN66BI.exe.

The NLI uses the cdecl ACML DLL libacmldll.dll. By default, this DLL is installed into C:\Program Files\AMD\acml3.0.0\win32cdecl\lib. The DLL needs to be placed into the same directory as your application, into a directory that is in your PATH, or into a Windows system directory, such as c:\windows\system32. The AcmlIFort provider should be used with the version compiled with Intel’s FORTRAN compiler and AcmlCvf should be used with the one compiled with CVF.

64-bit Windows (not tested): The Acml provider should be used for 64-bit versions of ACML. All variants of the 64-bit version are supported (standard, large arrays, mp, and mp with large arrays). The ACML DLL, libacml_dll.dll, and all it supporting DLLs need to be in the same directory as your application, in a directory that is in your PATH, or in a Windows system directory, such as c:\windows\system32.

Linux: Only the GFORTRAN (32-bit) build of ACML is supported (the G77 Linux version will NOT work). The 64-bit version has not been tested. The Acml provider should be used for this version. In order to use ACML with the NLI under Linux, a new shared library must be created. The shared library that ships with ACML is NOT compatible with the NLI. Assuming that ACML is installed in /opt/acml3.0.0/ and the GFORTRAN library is in /usr/lib, execute this command:

ld -shared -o libacml.so --whole-archive /opt/acml3.0.0/gfortran32/lib/libacml.a --no-whole-archive /usr/lib/libgfortran.so

This will create a shared library named libacml.so. This library should be placed into directory where Mono can locate the library, such as somewhere listed in your LDLIBRARYPATH, /lib/, or /usr/lib. See this Mono help page for more information. You will need to add this dllmap line to the configuration section of your Mono configuration file (i.e.: $prefix/etc/mono/config): <dllmap dll=”libacml_dll.dll” target=”libacml.so”>

Last edited Oct 6, 2007 at 1:41 PM by pvandervelde, version 1

Comments

No comments yet.