topic Mac LP64 zgesv returns a wrong result in Intel® oneAPI Math Kernel Library

Mac LP64 zgesv returns a wrong result

jaewonj — Wed, 03 Mar 2010 17:42:28 GMT

Mac LP64 zgesv returns a wrong answer if MKL is linked statically. It seems
this only happens on I7 CPU.

If you compile and run zgesv.c (attached), you will see something like below,
but I expect x_exact == x. With MKL dynamic linking, everything seems to be ok.

$ ./zgesv

MKL Version = 10.2.3
Processor optimization : Intel Core i7 Processor
CPU frequency = 2.26 GHz

x_exact[0] = {1.000000, 0.000000}
x_exact[1] = {1.000000, 0.000000}
x_exact[2] = {1.000000, 0.000000}

info = 0
x[0] = {0.705114, 0.421455}
x[1] = {0.346944, 0.484740}
x[2] = {0.314761, -0.157588}

Test machine : MacPro 8-core 2.26GHz Nehalem.
MKL link : $(MKLPATH)/libmkl_intel_lp64.a $(MKLPATH)/libmkl_intel_thread.a $(MKLPATH)/libmkl_core.a -L$(MKLPATH) -liomp5

Could you check this on your side? Thanks.

Jaewon

-----------------------------------------------------------------------
/* zgesv.c */

#include
#include
#include
#include "mkl.h"
#include "mkl_service.h"
#include "mkl_lapack.h"

static void print_mklinfo()
{
MKLVersion ver;
MKLGetVersion(&ver);
printf("\\nMKL Version = %d.%d.%d\\n", ver.MajorVersion, ver.MinorVersion, ver.UpdateVersion);
printf("Processor optimization : %s\\n", ver.Processor);
printf("CPU frequency = %.2f GHz\\n\\n", getcpufrequency());
}

static void run_zgesv()
{
char trans = 'N';
MKL_INT i, n = 3, nrhs = 1, lda = 3, ldb = 3, info, ipiv[3];
MKL_INT incx = 1, incy = 1;
MKL_Complex16 alpha = {1., 0.}, beta = {0., 0.}, b[3];
MKL_Complex16 a[9] = {
{-2., 1.}, {0., -1.}, {0.5, 0.25},
{1., -1.}, {-2., 1.}, {0., -1.},
{0., 0.}, {1., -1.}, {-2., 1.}};
MKL_Complex16 x_exact[3] = {{1., 0.}, {1., 0.}, {1., 0.}};

for (i = 0; i < n; i++)
printf("x_exact[%d] = {%f, %f}\\n", i, x_exact.real, x_exact.imag);
printf("\\n");

zgemv(&trans, &n, &n, α, a, &lda, x_exact, &incx, β, b, &incy);
zgesv(&n, &nrhs, a, &lda, ipiv, b, &ldb, &info);

printf("info = %d\\n", info);
for (i = 0; i < n; i++)
printf("x[%d] = {%f, %f}\\n", i, b.real, b.imag);
printf("\\n");
}

int main()
{
print_mklinfo();
run_zgesv();
return 0;
}

Mac LP64 zgesv returns a wrong result

Gennady_F_Intel — Thu, 04 Mar 2010 11:53:02 GMT

jaewonj,

we tried to reproduce the problem on RHEL*5, the example passed, see the log below:

MKL Version = 10.2.3
Processor optimization : Intel Core i7 Processor

x_exact[0] = {1.000000, 0.000000}
x_exact[1] = {1.000000, 0.000000}
x_exact[2] = {1.000000, 0.000000}

info = 0

x[0] = {1.000000, 0.000000}

x[1] = {1.000000, -0.000000}

x[2] = {1.000000, 0.000000}

--Gennady

Mac LP64 zgesv returns a wrong result

Artem_V_Intel — Thu, 04 Mar 2010 14:43:20 GMT

Hello Jaewon,

I tried to reproduce this problem on Intel Core 2 Duo processor running Mac OS 10.6 'Snow Leopard' and doesn't obtain any issues. I linked this app against MKL 10.2.4. Please see logs for LP64 and ILP64 modes below:

LP64:

MKL Version = 10.2.4
Processor optimization : Intel Core 2 Duo Processor
CPU frequency = 1.99 GHz

x_exact[0] = {1.000000, 0.000000}
x_exact[1] = {1.000000, 0.000000}
x_exact[2] = {1.000000, 0.000000}

info = 0
x[0] = {1.000000, 0.000000}
x[1] = {1.000000, -0.000000}
x[2] = {1.000000, 0.000000}

ILP64:

MKL Version = 10.2.4
Processor optimization : Intel Core 2 Duo Processor
CPU frequency = 2.00 GHz

x_exact[0] = {1.000000, 0.000000}
x_exact[1] = {1.000000, 0.000000}
x_exact[2] = {1.000000, 0.000000}

info = 0
x[0] = {1.000000, 0.000000}
x[1] = {1.000000, -0.000000}
x[2] = {1.000000, 0.000000}

Best regards,

Artem

Mac LP64 zgesv returns a wrong result

jaewonj — Fri, 05 Mar 2010 23:30:25 GMT

Gennady,

This is weird. I can reproduce the problem everytime I run the example code. Is it possible for you to compile the example with MKL static link and run on Mac Pro (2.26GHz, 2 Quad-Core Intel Xeon Nehalem processor)?

Jaewon

Mac LP64 zgesv returns a wrong result

jaewonj — Mon, 08 Mar 2010 18:10:28 GMT

Updated to 10.2.4, but doesn't help. ZGESV still returns a wrong solution.

Mac LP64 zgesv returns a wrong result

Todd_R_Intel — Fri, 12 Mar 2010 23:04:27 GMT

Jaewon,

I ran your code on a 2.66GHz 8-core Intel Xeon processor (Nehalem) and still do not see the problems you report when linking statically. Could you say something about the OS and gcc version you are using?

-Todd

Mac LP64 zgesv returns a wrong result

jaewonj — Sat, 13 Mar 2010 21:32:12 GMT

Todd,

Here is gcc, system, and os information. You can find CFLAGS and LDFLAGS in the screen shot attached before. Please let me know in case you need futher information.

Thanks.

Jaewon

$ system_profiler | more

Hardware Overview:

Model Name: Xserve
Model Identifier: Xserve3,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.26 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per core): 256 KB
L3 Cache (per processor): 8 MB

System Software Overview:

System Version: Mac OS X Server 10.6.2 (10C540)
Server Configuration: Advanced
Kernel Version: Darwin 10.2.0
Boot Volume: 10.6
Boot Mode: Normal
Computer Name:
User Name: Jaewon Jang (jaewonj)
Secure Virtual Memory: Not Enabled
64-bit Kernel and Extensions: Yes
Time since boot: 31 days 18 minutes

$ gcc --version

i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Mac LP64 zgesv returns a wrong result

jaewonj — Wed, 24 Mar 2010 21:30:30 GMT

Any update on this issue? Thanks.

Mac LP64 zgesv returns a wrong result

Todd_R_Intel — Wed, 24 Mar 2010 22:01:06 GMT

Jaewon

Here is the information I see on our system. The OS, kernel, and gcc are older versions. I'll ask

Hardware Overview:

Model Name: Xserve
Model Identifier: Xserve3,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.66 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per core): 256 KB
L3 Cache (per processor): 8 MB

System Software Overview:

System Version: Mac OS X Server 10.5.8 (9L34)
Kernel Version: Darwin 9.8.0
Boot Volume: XserveHW
Boot Mode: Normal
Computer Name:
User Name:
Time since boot: 14 days 4:11

PLL-Xserve:u72449 trosenqu$ gcc --version

i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'll continue to investigate.

Todd

Mac LP64 zgesv returns a wrong result

Alexander_K_Intel3 — Tue, 13 Apr 2010 10:59:33 GMT

Jaewon,

Could you please try different compiler (another version of gcc, or icc or anything else) to look if issue still appears.

I'm also trying to reproduce your issue, but still not succesfull.
My envoronment is almost the same:

Hardware Overview:

Model Name: Xserve
Model Identifier: Xserve3,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.66 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per core): 256 KB
L3 Cache (per processor): 8 MB
Memory: 12 GB
Processor Interconnect Speed: 6.4 GT/s
Boot ROM Version: XS31.0079.B00
SMC Version (system): 1.43b3
LOM Revision: 1.1.2

System Software Overview:

System Version: Mac OS X 10.6.2 (10C540)
Kernel Version: Darwin 10.2.0
Boot Volume: XserveHW_SL
Boot Mode: Normal
Secure Virtual Memory: Not Enabled
64-bit Kernel and Extensions: Yes

gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.

The only differencies are frequency and build of GCC. It could happen that the last hides the cause...

Thanks,
Alexander.

Mac LP64 zgesv returns a wrong result

jaewonj — Thu, 15 Apr 2010 15:06:25 GMT

Alexander,

You're right. The problem doesn't appear with gcc 4.0. Thanks.

i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
Copyright (C) 2005 Free Software Foundation, Inc.

I'll forward this information to the release engineering team.

Regards,
Jaewon

Mac LP64 zgesv returns a wrong result

Gennady_F_Intel — Mon, 19 Apr 2010 05:27:28 GMT

another possibleWorkarounds is:Instead of 'gcc' call directly executable 'i686-apple-darwin10-gcc-4.2.1'.

--Gennady

Mac LP64 zgesv returns a wrong result

jaewonj — Fri, 23 Apr 2010 23:52:47 GMT

Gennady,

i686-apple-darwin10-gcc-4.2.1 also worked. Thanks. Do you have any reference that explains why this is happening?

Jaewon

Mac LP64 zgesv returns a wrong result

Gennady_F_Intel — Sat, 24 Apr 2010 03:07:26 GMT

Jaewon,

We believe that this looks like problem of linker, which messes static constants.

For example incorrect results from ZGETRF are because constant complex one becomes really complex minus one and that leads to incorrect results.

--Gennady

Mac LP64 zgesv returns a wrong result

jaewonj — Sun, 17 Oct 2010 21:35:39 GMT

Gennady,

When I initially reported this problem, the MKL version I used was 10.2.3. I found the problem still exists in 10.2.5. Has this problem been resolved in 10.2.6 or 10.3?

Thanks.
Jaewon

Mac LP64 zgesv returns a wrong result

mecej4 — Sun, 17 Oct 2010 22:29:01 GMT

From all the posts in this thread, I gather that this is a problem specific to the Apple OSX platform. And, from what Gennady Fedorov has stated, it is attributable to the OSX linker, which is controlled by Apple, not Intel. On Linux-x64, your example runs fine with the 11.1.073 compiler and MKL 10.2.6.

The solution, it seems, should come from Apple, although Intel has an interest in seeing it emerge.

I do not understand why Apple is dragging its feet with all the XCode problems that we see so much of on this forum, and why Apple users put up with such nonchalance. I admit, however, that I speak as a casual observer -- the last experience I had with any of Jobs' computers was with a NeXT workstation in the early 1990s, and it was fine for the time.

Mac LP64 zgesv returns a wrong result

jaewonj — Wed, 20 Oct 2010 07:49:34 GMT

Thanks, mecej4. Yes, this issue is Mac specific, and can be reproducible with gcc (4.2.1 build 5664) and icc (11.1 089).

Mac LP64 zgesv returns a wrong result

jaewonj — Sat, 13 Nov 2010 14:22:44 GMT

No longer reproducible with MKL 10.3. Thanks Gennady for looking into this issue.