Numpy: Numpy 1.10.2 + MKL = bloqueo (Windows)

Hmm, no sé qué está pasando aquí. Intel hizo algunos cambios en la compilación, pero no creo que estén involucrados. Python 3.5 es un posible culpable, ya que está compilado con un VS más nuevo en Windows. @cgohlke pensamientos?

Creo que lo mejor que puedes hacer es proporcionar un reproductor (¿cuáles son las "algunas funciones" que producen esto?), Y esperar que @cgohlke aparezca con la respuesta o presentar un error con Anaconda (ya que tienen los recursos para respaldar su MKL construye y nosotros no).

Perdón por las "algunas funciones" :) - se bloqueó indirectamente a través de matplotlib.

Esto se bloquea de todos modos:

A = np.arange(2*3).reshape(2,3).astype(np.float32)
B = np.arange(2*3*2731).reshape(2,3,2731).astype(np.int16)

np.dot(A, B)

Hice una verificación rápida con el último @cgohlke numpy (1.10.2) python-3.4 (64bit) y python-3.5 (64bit) en mi computadora portátil:

>>> np.show_config()
openblas_lapack_info:
  NOT AVAILABLE
lapack_mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt', 'mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
lapack_opt_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt', 'mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
blas_mkl_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
blas_opt_info:
    include_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/include']
    libraries = ['mkl_lapack95_lp64', 'mkl_blas95_lp64', 'mkl_rt']
    library_dirs = ['C:/Program Files (x86)/IntelSWTools/compilers_and_libraries/windows/mkl/lib/intel64_win']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]

>>> import numpy as np
>>> A = np.arange(2*3).reshape(2,3).astype(np.float32)
>>> B = np.arange(2*3*2731).reshape(2,3,2731).astype(np.int16)
>>> np.dot(A, B)
array([[[  13655.,   13658.,   13661., ...,   21839.,   21842.,   21845.],
        [  38234.,   38237.,   38240., ...,   46418.,   46421.,   46424.]],

       [[  38234.,   38246.,   38258., ...,   70970.,   70982.,   70994.],
        [ 136550.,  136562.,  136574., ...,  169286.,  169298.,  169310.]]], dtype=float32)

Ambos funcionan como se esperaba para mí.

Supongo que el error Intel MKL FATAL ERROR: Cannot load mkl_intel_thread.dll podría explicarse debido a una versión incorrecta mkl_intel_thread.dll encontrada en algún lugar de PATH . La ubicación de las DLL MKL extendiendo PATH como se hizo en numpy + MKL es frágil si se instala otro tiempo de ejecución MKL en el sistema.

¿Hay archivos libiomp5md.dll o mkl_*.dll en los directorios C: \ Windows *?

@cgohlke , en numpy + MKL introdujiste _init_numpy_mkl() para agregar numpy.core al PATH .

¿Consideró el siguiente enfoque de https://gist.github.com/matham/f6a07f8fb5e403feb440 para cambiar el orden de búsqueda de DLL?

Ver también:
https://pytools.codeplex.com/workitem/1627 (de donde viene)
https://github.com/numpy/numpy/wiki/windows-dll-notes#python -dlls
http://stackoverflow.com/questions/23804438/find-library-in-ctypes

@cgohlke Estos son los archivos DLL que se encuentran en mi directorio de Windows:

['System32\\libiomp5md.dll',
 'System32\\mkl_core.dll',
 'System32\\mkl_def.dll',
 'System32\\mkl_intel_thread.dll',
 'SysWOW64\\libiomp5md.dll',
 'SysWOW64\\mkl_core.dll',
 'SysWOW64\\mkl_intel_thread.dll',
 'SysWOW64\\mkl_p4.dll',
 'SysWOW64\\mkl_p4m.dll',
 'SysWOW64\\mkl_p4m3.dll',
 'SysWOW64\\mkl_p4p.dll']

Intentar restablecer mi RUTA con SET PATH=; antes de invocar Python todavía falla, pero al eliminar las DLL anteriores por completo del directorio de Windows, se detiene el bloqueo. Parece un problema de precedencia de ruta @carlkl.

@cgohlke , propongo el siguiente cambio para probar con numpy + MKL's __init__.py

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    import ctypes
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # extend DLL search order with numpy.core
    # See https://github.com/numpy/numpy/wiki/windows-dll-notes#python-dlls
    # and https://pytools.codeplex.com/workitem/1627
    try:
        _AddDllDirectory = ctypes.windll.kernel32.AddDllDirectory
        _AddDllDirectory.argtypes = [ctypes.c_wchar_p]
        # Needed to initialize AddDllDirectory modifications
        ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000)
    except AttributeError:
        _AddDllDirectory = ctypes.windll.kernel32.SetDllDirectoryW
        _AddDllDirectory.argtypes = [ctypes.c_wchar_p]
    try:
        _core = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        _AddDllDirectory(_core)
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

la eliminación completa de los archivos DLL anteriores del directorio de Windows detiene el bloqueo.

Buen viaje.

Propongo el siguiente cambio para probar con numpy + MKL's __init__.py

Eso realmente no funcionará en sistemas más antiguos y, lo que es más importante, rompe paquetes que dependen del orden de búsqueda de DLL del sistema. Puede ser aceptable para distribuciones como Anaconda o WinPython.

Me parece divertido que inicialmente encontré el método AddDllDirectory en la wiki numpy que se le atribuyó parcialmente a @carlkl , pero luego @carlkl propuso mi uso aquí como ejemplo, y terminé aquí porque de un problema con ese código de ejemplo al buscar numpy por AddDllDirectory . Es un círculo completo ...

De todos modos, quería señalar para otros que consideren usar esto, que la línea ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000) (y cualquier otra de las banderas sin cero) causa excepciones ImportError: DLL load failed: The parameter is incorrect al cargar algunas dlls. Para mí, solo sucedió específicamente con una extensión construida mingw-w64 (mingwpy) que se vinculaba a ffmpeg dlls que se compilaron de forma cruzada en debian con mingw-w64. Pero no sé si eso fue responsable.

Sin embargo, debido a que Python llama a LoadLibraryEx solo con LOAD_WITH_ALTERED_SEARCH_PATH y no con LOAD_LIBRARY_SEARCH_USER_DIRS , a menos que SetDefaultDllDirectories también se llame con LOAD_LIBRARY_SEARCH_USER_DIRS , LoadLibraryEx no buscará en los directorios agregados con AddDllDirectory . Para mí, esto parece un poco frágil de usar, así que creo que volveré a agregar el directorio dll a la ruta con os.environ . Sin embargo, me pregunto si debería actualizar la wiki con esta información.

De todos modos, espero que este no sea un tema muy alejado.

@matham , este fragmento de código debe acreditarse a _zooba_; consulte https://pytools.codeplex.com/workitem/1627. La línea ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000) no cambia el comportamiento de LoadLibraryEx con LOAD_WITH_ALTERED_SEARCH_PATH . _Con suerte_ cambia el comportamiento de LoadLibraryA (_without_ LOAD_WITH_ALTERED_SEARCH_PATH ) que solía cargar MKL_INTEL_THREAD.DLL justo después de que se cargue random \ mtrand.pyd y MKL_RT.DLL entonces llamadas MKL_INTEL_THREAD.DLL :

log del dependiente walker durante python -c "import numpy"

...
LoadLibraryExW("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\mtrand.cp35-win_amd64.pyd", 0x0000000000000000, LOAD_WITH_ALTERED_SEARCH_PATH) called from "d:\devel\py\python-3.5.0.amd64\PYTHON35.DLL" at address 0x00000000587E7747.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" at address 0x000007FEF3310000.  Successfully hooked module.
DllMain(0x000007FEF3310000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" called.
DllMain(0x000007FEF3310000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\MTRAND.CP35-WIN_AMD64.PYD" returned 1 (0x1).
LoadLibraryExW("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\random\mtrand.cp35-win_amd64.pyd", 0x0000000000000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned 0x000007FEF3310000.
LoadLibraryA("d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\mkl_intel_thread.dll") called from "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_RT.DLL" at address 0x000007FEE17C4772.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_INTEL_THREAD.DLL" at address 0x000007FEE0520000.  Successfully hooked module.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\MKL_CORE.DLL" at address 0x000007FEDEEC0000.  Successfully hooked module.
Loaded "d:\devel\py\python-3.5.0.amd64\lib\site-packages\numpy\core\LIBIOMP5MD.DLL" at address 0x000007FEE43E0000.  Successfully hooked module.
...

@carlkl es cierto, pero me refería a la wiki: (thanks to Steve Dower for the fragment, Carl Kleffner for finding it) , que asumí que eras tú :)

La fragilidad a la que me refería es que, en general, puede haber algún otro código ejecutado entre la llamada SetDefaultDllDirectories que establece esa bandera y cuando la biblioteca está realmente cargada. Por ejemplo, si importa algo que en sí mismo llama SetDefaultDllDirectories quizás con un valor (por ejemplo, 0) que puede resultar en que la dll no se encuentre más tarde cuando se importe. Aunque supongo que esto puede no ser un problema aquí si se importa inmediatamente.

@cgohlke , ¿hay algún problema con la precarga de MKL_RT.DLL , MKL_INTEL_THREAD.DLL y MKL_CORE.DLL con una ruta explícita a numpy.core dentro de _init_numpy_mkl() ? Sin embargo, no estoy seguro de si la carga gradual de otras DLL MKL necesarias funciona en ese momento.

@cgohlke ,

el siguiente fragmento garantiza (?) que las DLL MKL se cargan desde numpy.core y no desde ningún sistema de Windows o carpeta de Intel redist. El orden de carga de las DLL es importante. Al menos funciona para Windows 7 python-3.4 bit.

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    import ctypes
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # preload MKL DLLs from numpy.core
    try:
        _core = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        for _dll in ('mkl_rt', 'libiomp5md', 'mkl_core', 'mkl_intel_thread', 
                     'libmmd', 'libifcoremd', 'libimalloc'):
            ctypes.cdll.LoadLibrary(os.path.join(_core,_dll))
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

Tuve el mismo problema y lo rastreé hasta que instaló mkl_intel_thread.dll en C:\Windows\System32 como lo indica danielgeier.
La versión anterior no tenía el mkl_aa_fw_get_max_memory entre otras cosas.
El tiempo de creación coincidió con la instalación de los controladores de audio Asio4all. Después de desinstalarlos, que eliminaron varios dlls, funcionó nuevamente (mejor que simplemente eliminar dlls en system32 por mi cuenta).
Jugué con retroceder y actualizar la distribución de anaconda, pero eso no funcionó. Tampoco pude deshabilitar mkl con anaconda en Windows.

@ sebastian-schmidt, ¿puedes probar si la carga explícita de archivos DLL MKL desde la carpeta numpy / core funciona para ti, incluso con archivos DLL MKL desactualizados instalados en la carpeta del sistema de Windows? Ver arriba: https://github.com/numpy/numpy/issues/6923#issuecomment -169073613

@carlkl , ¿dónde tengo que agregar el fragmento?
Intenté agregarlo al archivo que usé como prueba: https://gist.github.com/sebastian-schmidt/9bb97354b481750209fd3dac1e748d31 y no funcionó.
La ruta unida es solo un subdirectorio desde donde llamo al archivo.
¿Tengo que agregarlo al módulo init de Numpy?

La función _init_numpy_mkl() es parte de @cgohlke numpy + mkl wheels. Puede encontrarlo en el archivo __init__.py . No es parte de las fuentes oficiales de numpy.

Aquí está la versión que se encuentra en numpy-1.10.4+mkl-cp34-none-win32.whl

def _init_numpy_mkl():
    # Numpy+MKL on Windows only
    import os
    if os.name != 'nt':
        return
    # disable Intel Fortran default console event handler
    env = 'FOR_DISABLE_CONSOLE_CTRL_HANDLER'
    if env not in os.environ:
        os.environ[env] = '1'
    # prepend the path of the Intel runtime DLLs to os.environ['PATH']
    try:
        path = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'core')
        if path not in os.environ.get('PATH', ''):
            os.environ['PATH'] = os.pathsep.join((path, os.environ.get('PATH', '')))
    except Exception:
        pass

_init_numpy_mkl()
del _init_numpy_mkl

Esta función añade el numpy/core carpeta para el PATH medio ambiente. Sin embargo, las DLL que se encuentran en la carpeta del sistema de Windows se prefieren a las DLL que se encuentran en la RUTA. Bienvenido al infierno de las DLL.

La versión alternativa de esta función https://github.com/numpy/numpy/issues/6923#issuecomment -169073613 carga las DLL MKL desde numpy/core en el orden correcto _sin_ cambiar el entorno PATH . Todos los nombres de DLL se dan como nombres de archivo explícitos con una ruta de acceso completa, por lo que no espero problemas con el remedo de DLL en la carpeta del sistema de Windows, pero no lo he probado.

Sin embargo, no me importaba el número congelado en este fragmento de código.

Cambié _init_numpy_mkl() en la distribución de Anaconda a su versión y luego funcionó (con dlls incompatibles en windows/system32 .

¡Me alegro de oirlo!

El código en _init_numpy_mkl () es parte de la distribución numpy @cgohlke 's y bajo su responibility.
@cgohlke : ¿algún comentario sobre https://github.com/numpy/numpy/issues/6923#issuecomment -169073613?

@ sebastian-schmidt, ¿puede probar la versión usando AddDllDirectory (o SetDllDirectoryW como alternativa)? Vea arriba: https://github.com/numpy/numpy/issues/6923#issuecomment -168490201

@carlkl , la versión AddDllDirectory / SetDllDirectoryW también funciona.
La prueba siempre fue solo el ejemplo np.dot() de danielgeier.
En una nota al margen, el software que instala las bibliotecas mkl fue Amplitube y no los controladores Asio4all.

Yo también rastreé el problema hasta Amplitube.

cuando lo intenté: import matplotlib.pyplot as plt con ambas versiones de inicio recibí un error:

---> 60 import matplotlib._png as _png
     61 ####################
     62 

ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.

Así que volví a la versión original de Anaconda y dejé Amplitube desinstalado.

@ sebastian-schmidt, al menos me funciona. Importar numpy, scipy, matplotlib._png funciona sin problemas en mi caja.

Sin embargo, desinstalar los archivos DLL MKL de las carpetas del sistema de Windows parece ser la mejor solución para este tipo de problemas.

¿Es hora de cerrar este problema?

Hola chicos. Por si acaso alguien todavía tiene este problema. Tengo numpy 1.12 + mkl y tuve el mismo problema. ¡Desinstalé Amplitube 3 y ahora todo está funcionando!

Hola chicos,

Acabo de instalar el último paquete numpy + mkl 1.13 desde aquí por @cgohlke .

Estoy ejecutando Anaconda con Python 3.6.1 de 64 bits en Windows 7.

Después de eso, también recibo este problema de DLL, funcionaba bien para v1.12 desde el mismo sitio antes.

Para agregar, en realidad todo el código funciona en un cuaderno Jupyter ... Esto solo ocurre en una consola.

@carlkl Busqué en mi carpeta Anaconda _init_numpy_mkl pero no pude encontrar el archivo que contenía esta cadena. Agregar manualmente numpy/core a mi variable PATH env tampoco funcionó.

¿Cualquier otra sugerencia?

Gracias.

cuando importé skimage, encontré el problema "no se puede cargar mkl_intel_thread.dll".
No puedo encontrar ningún mkl_intel_thread.dll en windows / system32, así que eliminé libiomp5md.dll en esa carpeta tal como mencionó @cgohlke , funciona！ ¡muchas gracias! el problema me ha preocupado semanas. De todos modos, espero que otros que hayan encontrado este problema puedan obtener ayuda de esto. Intente encontrar libiomp5md.dll, puede ayudar.

Me pregunto si https://github.com/numpy/numpy/issues/6923#issuecomment -169073613 funciona en ese caso sin la necesidad de eliminar las DLL MKL de windows / system32. Este fragmento muestra que es posible cargar siete (pero no todas) DLL MKL en la carpeta numpy / core sin la necesidad de pasar bibliotecas adicionales a la variable de entorno PATH o usar otros trucos. Es importante cargar estas 7 DLL en la secuencia correcta. Todos los demás archivos DLL MKL necesarios se cargan automáticamente desde numpy / core en lugar de la carpeta windows / system32.

Aún no está claro si esto funciona en todos los escenarios imaginables. Por ejemplo, aplicaciones de Python congeladas. Además, las versiones del sistema operativo Windows pueden diferir en el comportamiento de carga de la DLL.

Me parece ventajoso seguir investigando esta variante.

Fuimos de un lado a otro con SetDefaultDllDirectories , # 10229 lo agregó y luego # 11493 lo eliminó. Creo que hemos llegado tan lejos como podemos con esto. Parece que la mejor opción es eliminar otras copias de mkl de PATH.

Vuelva a abrir si no está de acuerdo.