[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