Problems with Intel MKL #6669
Comments
|
RuntimeWarning is an error because of a bug in the 1.10.1 release, you can ignore those. Some of the others may be fixed in 1.10.2 when it comes out. The 'f2py3.5' thing is strange. |
|
It's the failed tests that I'm worried about. Note that numpy+openblas in the same environment passes those tests. And, what got me looking at this is that one of my programs gave me good results on an AMD machine using numpy+openblas but terrible results on an Intel machine using numpy+MKL. |
|
We (= the numpy core team) don't really test numpy against MKL ourselves... On Wed, Nov 11, 2015 at 4:16 PM, Rob Malouf notifications@github.com
Nathaniel J. Smith -- http://vorpus.org |
|
(And for clarity, note that by "CC" I mean "on my email reply to github, On Thu, Nov 12, 2015 at 3:12 PM, Nathaniel Smith njs@pobox.com wrote:
Nathaniel J. Smith -- http://vorpus.org |
|
Okay, sounds reasonable. The fix for me is easy -- just use OpenBLAS -- but if I manage to get any more clues about what's going on with MKL I'll let you know. |
|
Another piece of information: numpy + MKL appears to be working when using pthreads, but not with openmp. If that helps. |
|
Actually, that does jiggle my memory a bit. ISTR openmp problems with the gnu compilers also, seems to be feature of the software ;) Might be worth looking into. |
|
The problem with gnu OpenMP is that it isn't fork safe. Can't see how that would be relevant to those test failures. Plus Intel OpenMP is fork safe anyway, though I'm not sure what happens when you use gcc + OpenMP + mkl together. |
|
for GNU OpenMP+MKL, you might want to set |
|
There are 3 issues that may still exist (the rest is fixed): |
|
We'll take a look |
|
Disclosure: I'm from Intel. So, we are not yet able to get back to those issues, but this will be our ongoing work in a few weeks. |
|
Thanks @antalmal |
I see that no one replied to this part yet. @rmalouf you should be able to specify that MKL is to be used in |
|
Another info on this issue. This is on numpy 1.10.4 with stock python 2.7.5 on CentOS 7. Using l_mkl_11.3.1.150. Using the following site.cfg: |
|
I get the same three arcsinh assertion failures on Centos 7 with python 2.7.8 and openblas (I tried both 0.2.14 and 0.2.15.) |
|
The arcsinh issues are library related, I don't know which math library mkl links to. The f2py issue might be fixed in 1.11, or might not. It would be good if you could determine where |
|
I got f2py working. The arcsinh asserts are still a problem. |
|
The arcsinh issue is specific to Centos 7: I have found that, with a little work, I can get all tests to pass with python 2.7.8 and openblas 0.2.15 on Centos 6. While building on Centos 6, I did run into a different test failure, which I worked around using these instructions. Centos 7 uses glibc-2.17. I wonder if these assertion failures might also be related to glibc. |
|
Hmm, currently we blacklist a bunch of functions for glibc < 2.16. You can play with the blacklist in |
|
numpy on Centos 7 (glibc == 2.17) runs the test suite successfully after building with the following appended to numpy/core/src/private/npy_config.h: |
|
To the comment about compiling NumPy 1.10.4 with MKL 11.3.x, I've compiled it and the site.cfg is just: [mkl] However note I'm compiling with Intel's compiler 2015 XE parallel studio, and Microsoft Visual Studio 2015 Community (for Python 3.5). You'll have to get it right for your Python build (MSVC compiler). That passes all tests except 1 which looks like a bug in the test script more than anything else. Building SciPy on top of this doesn't produce any errors after sp.test() |
|
The issue with building numpy+mkl comes up if you've also got openblas installed in a place where distutils can find it. Since it checks for openblas first, it'll use it even if you've specified mkl in site.cfg. I just submitted a PR (#7232) to correct that. |
|
The first problem described here is the order of mkl and openblas, which was fixed. There are duplicate and ongoing issues with mkl/openblas and multithreading. Closing this in favor of the other, more updated ones |
I've been trying to get numpy working with Intel's MKL math library without much success.
The first problem was convincing numpy's build process to use MKL even though I have openblas installed on my system The problem is in
distutils/system_info.pychecks for the existence of openblas before checking whether MKL is configured. Checking MKL first resolved that issue (I can submit a patch if you're interested).That leads to the second problem. When linked with MKL, numpy fails several of it's tests. Specifically:
I don't even know where to begin to isolate the problem. Has anyone reported this before? What other information would be helpful? I'm using numpy 1.10.1, python 3.5.0, gcc 4.8.3, MKL 11.3.
The text was updated successfully, but these errors were encountered: