topic mkl lapack zgesdd example in Intel® oneAPI Math Kernel Library

mkl lapack zgesdd example

jangerrit — Mon, 30 Jan 2012 16:29:48 GMT

Hey,
I'm trying to use the svd with the example function [1].
My system is a 64bit linux and i'm linking against the mkl-lapack supplied by matlab 2011a.
building and linking works (after some manipulation to get the link working) [2]

But the call results in the error:
MKL ERROR: Parameter 5 was incorrect on entry to ZGESDD

i use the gcc compiler.

hopefully you can help my :)

thanks

Jan

[1] http://software.intel.com/sites/products/documentation/hpc/mkl/lapack/mkl_lapack_examples/zgesdd_ex.c.htm

[2]
extern "C" {extern void zgesdd_( char* jobz, int* m, int* n, dcomplex* a,
myInt* lda, double* s, dcomplex* u, int* ldu, dcomplex* vt, int* ldvt,
dcomplex* work, int* lwork, double* rwork, int* iwork, int* info );
}

mkl lapack zgesdd example

mecej4 — Mon, 30 Jan 2012 17:13:07 GMT

You may be using MKL-Lapack in a non-standard way. In particular, what is the definition of type myInt? What is the command line used to compile, and which version of Matlab did the shared library come with? Is the function call in C++ code?

mkl lapack zgesdd example

jangerrit — Mon, 30 Jan 2012 18:26:49 GMT

sorry.. i didn't see that..
the myInt is a typedef for int
typedef int myInt;
i played around a little bit, because i found something in a different thread that states, that you need 8 bit integer (which i don't have and which doesn't make sense to me)

while checking the gcc commands again i found a mistake, although this works, i am linking against a custom lapack version.

g++ -c -m64 -pipe -O2 -D_REENTRANT -Wall -W -I/usr/include -I. -I. -o main.o main.cpp

g++ -m64 -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -Wl,-O1 -o zgesdd main.o -lpthread -llapack

but i forced the usage of the mkl lapack with ld_preload.. i don't know if this linking can be responsibe for this..

if i change it to
g++ -m64 -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -Wl,-O1 -o sizeOftest main.o -LPATH_TO_matlab/bin/glnxa64/ -lmkl -LPATH_TO_matlab/sys/os/glnxa64/ -liomp5 -lpthread -lpthread_nonshared

if get an error:
libiomp5.so: undefined reference to `pthread_atfork'

Jan

mkl lapack zgesdd example

TimP — Mon, 30 Jan 2012 18:50:26 GMT

Quoting jangerrit

g++ -c -m64 -pipe -O2 -D_REENTRANT -Wall -W -I/usr/include -I. -I. -o main.o main.cpp

g++ -m64 -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -Wl,-O1 -o zgesdd main.o -lpthread -llapack

but i forced the usage of the mkl lapack with ld_preload.. i don't know if this linking can be responsibe for this..

Here you appear to be linking against the (non-threaded) lapack and blas for gfortran which come with your OS. There isn't a separate lapack library in recent MKL versions, so it's not clear whether your LD_PRELOAD had any effect.

g++ -m64 -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -Wl,-O1 -o sizeOftest main.o -LPATH_TO_matlab/bin/glnxa64/ -lmkl -LPATH_TO_matlab/sys/os/glnxa64/ -liomp5 -lpthread -lpthread_nonshared

if get an error:
libiomp5.so: undefined reference to `pthread_atfork'

That message normally indicates that you neglected to link libpthread after libiomp5, which doesn't agree with the link command you quote (unless you failed to mention a warning at link time). You do need the 64-bit libpthread.so on relevant paths at both link and run time.
ldd ./sizeOftest
should show you which .so files will be used according to the run environment you have set up (and also the unresolved .so references).

mkl lapack zgesdd example

jangerrit — Mon, 30 Jan 2012 20:25:25 GMT

yes, i know that i am linking against my os lapack.
i only do that because i get the error the other way.

i preload matlabs mkl.so and that is working

ldd zgesdd
linux-vdso.so.1 => (0x00007fffb07ad000)
/home/jangerrit/uni/matlab/bin/glnxa64/mkl.so (0x00007f8fd917f000)
liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f8fd8915000)
libc.so.6 => /lib/libc.so.6 (0x00007f8fd8575000)
libiomp5.so => path_to_matlab/bin/glnxa64/../../sys/os/glnxa64/libiomp5.so (0x00007f8fd8396000)
libm.so.6 => /lib/libm.so.6 (0x00007f8fd8116000)
/lib/ld-linux-x86-64.so.2 (0x00007f8fdb2da000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f8fd7ebf000)
libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f8fd7ba6000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f8fd79a2000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f8fd7785000)
libquadmath.so.0 => /usr/lib/../lib/libquadmath.so.0 (0x00007f8fd754f000)

and even from valgrind(callgrind)
1,676 < ???:mkl_lapack_zgesdd (2x) [path_to_matlab/bin/glnxa64/mkl.so]

there are no other errors than the strange pthread error if i try to link against mkl.so

i would just like to mention, that if i use the lapack supplied by my os, the function works fine. unfortunately, that is not a possible solution for me, as i would like to use it within matlab (which uses the mkl)

Jan

mkl lapack zgesdd example

mecej4 — Tue, 31 Jan 2012 00:04:18 GMT

>i found something in a different thread that states, that you need 8 bit integer

An 8-byte integer, possibly? The standard MKL distribution for 64-bit OSes contains two versions of MKL: LP64 (32 bit integers, 64-bit longs and pointers), and ILP64 (integers also 64-bit). You need to find out which model (LP64 or ILP64) is followed by the MKL library that you wish to use, and call it with the correct types of arguments.

The error message (incorrect value for an integer argument) suggests that you may be using the wrong size for integers.

mkl lapack zgesdd example

jangerrit — Tue, 31 Jan 2012 02:01:35 GMT

thanks.. 8byte is whate i meant.
at least i was on the right track.

how do i find out which model is used?

and how do i change the size of my integers?
thats what i tried with the typedef..
i just cast the integer to long long int which is 8 byte long.

there is no change in the error message. Should i replace every mention of ints to myInt and try again? i hoped that there would be at least a change in the faulty parameter ;)

Jan

mkl lapack zgesdd example

jangerrit — Tue, 31 Jan 2012 02:04:43 GMT

ok.. i changed every int to a long long int and now it is working :)

great. thanks for the help :)

jan