topic Hi Erik, in Intel® oneAPI Math Kernel Library

Compiling NumPy+MKL on Windows with Composer XE 2013 SP1

Erik_A_ — Fri, 18 Jul 2014 17:34:56 GMT

Just bought the entire Composer XE 2013 SP1 package to compile NumPy/SciPy on a Windows Platform.

numpy-1.8.1
scipy-0.13.3

What are the proper build instuctions assuming I want to build with a .bat file (or DOS prompt)? I am positive they are out of date because the

\Intel\Composer XE 2013 SP1\bin\compilervars.bat intel64

Doesnt register the proper environment variables. None of the compilervars options setup the proper environment.

"RuntimeError: Broken toolchain: cannot link a simple C program"

icc.exe isnt in the setup path and manually putting it in the %PATH% gives other errors.

Several thousand dollars on alternative compiler packages that cant even properly setup the compiler environment.

I have all the Visual Studio's installed but since I intend to add this to an auto build system I need to build from a CMD prompt.

Any pointers/links out there?

Hi Erik,

Ying_H_Intel — Mon, 21 Jul 2014 05:54:09 GMT

Hi Erik,

It seems we have bunch of posts about numpy under linux os, like https://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl and comments under the article. but very few about Windows OS. The gap seems the different window build and linux build rule. Could you please tell, if without composer XE (and MKL), the command you build the numpy under windows? Then we may modify it to icc/ifort and mkl version based on your config.

Best Regards,

Ying

Erik,

VipinKumar_E_Intel — Mon, 21 Jul 2014 06:08:22 GMT

Erik,

There is also instructions on building NumPy/SciPy on Windows in scipy.org site.

http://www.scipy.org/scipylib/building/windows.html

Have you tried without Intel Compilers as Ying mentioned above?

--Vipin

Problem is not how I would

Erik_A_ — Mon, 21 Jul 2014 14:13:00 GMT

Problem is not how I would compiler on Windows. I absolutely hate MinGW on Windows and cross compiling Linux->Windows is out of the question.

It seems the problem isnt really building NumPy on Windows. Problem is the Intel product itself. When I run any of the Intel Composer XE 2013 "command prompts" shortcuts they dont register (put in the path) the icc compiler (c compiler).

Pictures seem to get everyone speaking the same language.

Intel short cuts that dont register the icc.exe compiler in the windows %PATH%

Windows command prompt showing the icc.exe (Intel C compiler) not registered in the Windows %PATH%.

We bought the high end version of the Intel Composer Studio XE 2013 and it doesnt work. Go figure.

It seems the Intel C compiler (icc.exe) is in the

C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\intel64_mic

Directory. That directory is not put in the Windows %PATH%. Manually putting it in the path causes other problems.

On the flip side I did get NumPy compiling+linking when I mixed the Visual Studio C compiler (lc.exe) + Intel Fortran Compiler (ifort.exe). This is not acceptable though. We want to use one compiler package to build the entire environment. If I just wanted the Intel Fortran compiler I wouldnt have bought the whole Intel C/Fortran+Performance package.

On Windows, the name of the

mecej4 — Mon, 21 Jul 2014 15:15:04 GMT

On Windows, the name of the Intel C compiler driver is icl, not icc. Configure your build accordingly.

Hi Erik A.

Ying_H_Intel — Fri, 01 Aug 2014 01:46:21 GMT

Hi Erik A.

is the problem solved if with icl?

Best Regards,

Ying

Ying,

anderson__erik — Fri, 01 Aug 2014 18:38:50 GMT

Ying,

NumPy build for a windows platform is a mess and assumes MinGw or Visual Studio. I am redoing the NumPy build scripts to support a

setup.py build --compiler=intelwin --fcompiler=intelwin

The intelwin is a new windows+intel+mkl target that will build NumPy using the ifort and icl compilers. I had to make complete new build targets because the Unix and Windows targets made too many hard coded assumptions about compilers and linkers.

I work for a very large corporation but we have agreed to give my modifications back to the community. I might have this all finished up next week (or not) since I am only 1/2 time on this project. I will still need to figure out how to generate .PDB files and .map files for the resulting linked files so might take me a few more weeks.

After NumPy I need to attack SciPy and Pandas build targets.

We had one question maybe you could answer. How does the MKL library handle parallelization? Direct CPU to CPU MPI? For the MKL library it doesnt spawn threads to handle parallel calculations, correct? We hope not. Each new thread creates a new stack and that stack can use upwards of 1meg of ram.

Erik

Hi Erik,

Ying_H_Intel — Mon, 04 Aug 2014 03:50:33 GMT

Hi Erik,

Thank you alot for sharing your status and windows build experiences.

Regarding your question about how MKL handle parallelization, actually, most of MKL functions are paralleled by OpenMP threads. MKl support different OpenMP* implementations, (from Intel, GNU*, and PGI* etcs). For example, you link mkl as " -L/intel/mkl/lib/intel64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -L/intel/lib/intel64 -liomp5 -lpthread", the libiomp5.so is Intel OpenMP Runtime library. According to OpenMP* parallal model, it will spawn threads to handle calculations on multi-core system automatically. If you'd like specify the stack size, you may use the environment variable kMP_STACKSIZE or functions, you may refer to Intel Compiler's doc or OpenMP docs.

MKL also support Scalapack, cluster FFT etc functionality. They are for cluster, and use MPI as parallel method. for example, To link with ScaLAPACK for a cluster of systems based on the IA architecture, use the following link line:

mpicc <user files to link> \ -L$MKLPATH \ -lmkl_scalapack_core \ -lmkl_blacs_intelmpi \ -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core \ -liomp5 -lpthread

In this case, mkl use OpenMP to parallel on each node. use MPI as across-nodes parallel.

you may find more information in MKL userguide documentation.

Best Regards,

Ying

p.s i copy the threaded functions from mkl user guide.

Threaded Functions and Problems

The following Intel MKL function domains are threaded:

Direct sparse solver.
LAPACK.

For the list of threaded routines, see Threaded LAPACK Routines.
Level1 and Level2 BLAS.

For the list of threaded routines, see Threaded BLAS Level1 and Level2 Routines.
All Level 3 BLAS and all Sparse BLAS routines except Level 2 Sparse Triangular solvers.
All mathematical VML functions.
FFT.

For the list of FFT transforms that can be threaded, see Threaded FFT Problems.

I have the new Windows build

anderson__erik — Wed, 06 Aug 2014 20:46:25 GMT

I have the new Windows build system for NumPy trying to use Intel's xilink.exe

It seems the Intel linker isnt doing what it should. In Visual Studio I dont have to specify the CRT. However in Intel's xilink.exe it seems I need too?

Here is failed links.

xilink: executing 'link'
LINK : error LNK2001: unresolved external symbol mainCRTStartup
libirc.lib(new_proc_init.obj) : error LNK2019: unresolved external symbol strlen referenced in function __intel_new_feature_proc_init
libirc.lib(irc_msg_support.obj) : error LNK2001: unresolved external symbol strlen
libirc.lib(new_proc_init.obj) : error LNK2019: unresolved external symbol strncat referenced in function __intel_new_feature_proc_init
libirc.lib(new_proc_init.obj) : error LNK2019: unresolved external symbol exit referenced in function __intel_new_feature_proc_init
libirc.lib(irc_msg_support.obj) : error LNK2019: unresolved external symbol __imp_GetThreadLocale referenced in function __libirc_get_msg
libirc.lib(irc_msg_support.obj) : error LNK2019: unresolved external symbol sprintf referenced in function __libirc_get_msg
libirc.lib(irc_msg_support.obj) : error LNK2019: unresolved external symbol __imp_LoadLibraryA referenced in function __libirc_get_msg
libirc.lib(irc_msg_support.obj) : error LNK2019: unresolved external symbol __imp_FormatMessageA referenced in function __libirc_get_msg
libirc.lib(irc_msg_support.obj) : error LNK2019: unresolved external symbol vsprintf referenced in function __libirc_get_msg
libirc.lib(irc_msg_support.obj) : error LNK2019: unresolved external symbol strncpy referenced in function __libirc_get_msg
libirc.lib(irc_msg_support.obj) : error LNK2019: unresolved external symbol printf referenced in function __libirc_print
libirc.lib(proc_init_utils.obj) : error LNK2019: unresolved external symbol memset referenced in function __intel_proc_init_ftzdazule

There is actually no reason for this failure. Must I use Microsofts link.exe or Microsofts libraries? C runtime libraries are suppose to come for free and dont need to be specified on the link line. Actually if you do specify them it causes a lot of mismatching.

Thx,

Erik

Hi Erik,

Ying_H_Intel — Tue, 19 Aug 2014 08:41:22 GMT

Hi Erik,

I escalated your last problem to compiler forum https://software.intel.com/en-us/forums/topic/520065

One compiler expert hint it looks your environment setting is wrong. The Intel compiler environment setting does not seem to be proper. How did you set this?

So are you using Intel Compiler Prompt windows to build the numpy, which means icl.exe + Xilink

Or are you using Cl.exe + Xilink when run into the probelm?

Best Regards,

Ying