[Numpy-discussion] numpy with icc/MKL

rex rex@nosyntax....
Mon May 19 04:58:45 CDT 2008

> No, they heavily changed how to link against mkl in 10. There is a whole
> chapter about it in the releases notes.

Yes, I read it, but it appears to me that the new layer libraries
are an option, and that the legacy link format still works. From
chapter 3: 

"Pure layered libraries give more flexibility to choose the appropriate combination of
libraries but do not have backward compatibility by library names in link lines. Dummy
libraries are introduced to provide backward compatibility with earlier version of Intel MKL,
which did not use layered libraries.
Dummy libraries do not contain any functionality, but only dependencies on a set of layered
libraries. Placed in a link line, dummy libraries enable omitting dependent layered libraries,
which will be linked automatically. Dummy libraries contain dependency on the following
layered libraries (default principle):
·    Interface: Intel, LP64
·    Threading: Intel compiled
·    Computational: the computation library.
So, if you employ the above interface and use OpenMP* threading provided by the Intel®
compiler, you may not change your link lines."

> I don't have the same thing at all. You have many more libraries than I
> have, and that's because you were using the intel compiler, I think
> (libguide is from intel cc, imf is also used by icc and ifort).

>> Remove the installer numpy AND the build directory, and retry building
>> numpy with the mkl.

I always remove the build directory (if I forget the much faster
compilation reminds me). Do you mean remove the installed numpy?
Did that, built numpy again, and it fails numpy.test() exactly as before.

I changed site.cfg to:

library_dirs = /opt/intel/mkl/
lapack_libs = mkl_lapack
mkl_libs = mkl, mkl_vml_p4m, guide

(the vml is appropriate for my CPU). The build log shows:

F2PY Version 2_5189
    libraries = ['mkl', 'mkl_vml_p4m', 'guide', 'pthread']
    library_dirs = ['/opt/intel/mkl/']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/']

    libraries = ['mkl', 'mkl_vml_p4m', 'guide', 'pthread']
    library_dirs = ['/opt/intel/mkl/']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/']

    libraries = ['mkl', 'mkl_vml_p4m', 'guide', 'pthread']
    library_dirs = ['/opt/intel/mkl/']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/']

    libraries = ['mkl_lapack', 'mkl', 'mkl_vml_p4m', 'guide', 'pthread']
    library_dirs = ['/opt/intel/mkl/']
    define_macros = [('SCIPY_MKL_H', None)]
    include_dirs = ['/opt/intel/mkl/']

    libraries = ['mkl_lapack', 'mkl', 'mkl_vml_p4m', 'guide', 'pthread']
    library_dirs = ['/opt/intel/mkl/']

So it's finding the vector math library, but checking with ldd
shows that of all the *.so libs in site-packages/numpy only
lapack_lite.so is using vml. Any thoughts on why none of the other
libs are using it?

ldd /usr/local/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so
        linux-gate.so.1 =>  (0xffffe000)
        libmkl_lapack.so => /opt/intel/mkl/ (0xb7a48000)
        /opt/intel/mkl/ (0xb790a000)
        /opt/intel/mkl/ (0xb770d000)
        /opt/intel/mkl/ (0xb76a9000)
        libmkl_vml_p4m.so => /opt/intel/mkl/ (0xb73bd000)
        libguide.so => /opt/intel/mkl/ (0xb735a000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb732f000)
        libimf.so => /opt/intel/fc/10.1.015/lib/libimf.so (0xb70ff000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb70da000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb70cf000)
        libintlc.so.5 => /opt/intel/fc/10.1.015/lib/libintlc.so.5 (0xb708c000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb6f5a000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb6f56000)
        /lib/ld-linux.so.2 (0x80000000)

As you can see from the above, it uses libmkl_vml_p4m, but it's
the only *.so that does. It would be interesting to see the output
of these commands below on a box running BlAS and Lapack to see how many
of the *.so libs use them.

ldd /usr/local/lib/python2.5/site-packages/numpy/fft/fftpack_lite.so
ldd /usr/local/lib/python2.5/site-packages/numpy/lib/_compiled_base.so
ldd /usr/local/lib/python2.5/site-packages/numpy//core/multiarray.so
ldd /usr/local/lib/python2.5/site-packages/numpy//core/_dotblas.so
ldd /usr/local/lib/python2.5/site-packages/numpy//core/_sort.so
ldd /usr/local/lib/python2.5/site-packages/numpy/core/scalarmath.so 
ldd /usr/local/lib/python2.5/site-packages/numpy/core/umath.so
ldd /usr/local/lib/python2.5/site-packages/numpy/random/mtrand.so
ldd /usr/local/lib/python2.5/site-packages/numpy/numarray/_capi.so

> > Interestingly, the above shows libmkl_lapack.so is being used even
> > though it is not in the site.cfg. Apparently, mkl and guide are
> > sufficient in site.cfg.  

> I am not sure I understand: there is a mkl_lapack section in the
> site.cfg, and you need it.

Sorry, I'm going blind from fatigue. :(

> > So why do Erik and I get failures (with both gcc & icc) when MKL
> > is used and you don't?

> I don't know. I would ask Intel about this error if the above does not
> work, maybe you did not install it correctly, or there was a bug in your
> version (my version is a bit more recent, I downloaded it a few days
> ago).

In your list post you show mkl/ I'm using,
but I've tried an older 10.0.X version with no better luck. BTW,
my build runs, i.e., I can run some programs that use NumPy. 

I have posted to the Intel MKL forum. No responses yet. 

I am not goin' to buy my kids an encyclopedia. Let them walk to school the way I did.

More information about the Numpy-discussion mailing list