[Numpy-discussion] numpy with icc/MKL

David Cournapeau david@ar.media.kyoto-u.ac...
Mon May 19 07:58:03 CDT 2008


rex wrote:
>
> I always remove the build directory (if I forget the much faster
> compilation reminds me). Do you mean remove the installed numpy?
>   

Yes.

> Did that, built numpy again, and it fails numpy.test() exactly as before.
>
> I changed site.cfg to:
>
> [mkl]
> library_dirs = /opt/intel/mkl/10.0.3.020/lib/32
> lapack_libs = mkl_lapack
> mkl_libs = mkl, mkl_vml_p4m, guide
>   

Please follow exactly my instruction, otherwise, we cannot compare what 
we are doing: use exactly the same site.cfg as me.
>
> ldd /usr/local/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so
>         linux-gate.so.1 =>  (0xffffe000)
>         libmkl_lapack.so => /opt/intel/mkl/10.0.3.020/lib/32/libmkl_lapack.so (0xb7a48000)
>         /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel.so (0xb790a000)
>         /opt/intel/mkl/10.0.3.020/lib/32/libmkl_intel_thread.so (0xb770d000)
>         /opt/intel/mkl/10.0.3.020/lib/32/libmkl_core.so (0xb76a9000)
>         libmkl_vml_p4m.so => /opt/intel/mkl/10.0.3.020/lib/32/libmkl_vml_p4m.so (0xb73bd000)
>         libguide.so => /opt/intel/mkl/10.0.3.020/lib/32/libguide.so (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)
>   

You still have libraries linked to intel compilers (libintlc, libimf). 
If you remove both the build directory and installed numpy, I don't why 
those are used. As a last resort, can you put aside /opt/intel/fc 
temporally ?

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

Only _dotblas and lapack_lite use blas/lapack on numpy, AFAIK. They may 
be linked to other extensions, but won't be used.

> In your list post you show mkl/10.0.1.014/. I'm using 10.0.3.020,
> 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. 
>
>   

You are not using the free version, right ? The problem is that the MKL 
error has no clear meaning, and google did not return anything 
meaningful. Maybe your environment is corrupted in some way, because 
something is likely to influence how MKL is initialized. But what 
exactly, I have no idea.

cheers,

David


More information about the Numpy-discussion mailing list