Numpy: Numpy 1.10.2 + MKL = Absturz (Windows)

Hmm, ich weiß nicht was hier los ist. Intel hat einige Änderungen am Build vorgenommen, aber ich glaube nicht, dass diese beteiligt sind. Python 3.5 ist ein möglicher Schuldiger, da es mit einem neueren VS unter Windows kompiliert wird. @cgohlke Gedanken?

Ich denke, Ihre beste Wahl ist es, einen Reproducer bereitzustellen (was sind die "einige Funktionen", die dies erzeugen?) Und entweder zu hoffen, dass @cgohlke mit der Antwort auftaucht, oder einen Fehler bei Anaconda einzureichen (da sie die Ressourcen zur Unterstützung haben ihre MKL baut und wir nicht).

Entschuldigung für die "einige Funktionen" :) - es stürzte indirekt über matplotlib ab.

Das stürzt trotzdem ab:

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)

Ich habe einen kurzen Check mit dem neuesten @cgohlke numpy (1.10.2) Python-3.4 (64bit) sowie Python-3.5 (64bit) auf meinem Laptop durchgeführt:

>>> 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)

Beides funktioniert für mich wie erwartet.

Ich denke, der Fehler Intel MKL FATAL ERROR: Cannot load mkl_intel_thread.dll könnte durch eine falsch versionierte mkl_intel_thread.dll die irgendwo auf PATH . Das Auffinden von MKL-DLLs durch Erweitern von PATH wie in numpy + MKL ist fragil, wenn eine andere MKL-Laufzeit auf dem System installiert ist.

Gibt es in den Verzeichnissen C: \ Windows * libiomp5md.dll oder mkl_*.dll Dateien?

@cgohlke , in numpy + MKL haben Sie _init_numpy_mkl() , um numpy.core zu PATH hinzuzufügen.

Haben Sie den folgenden Ansatz von https://gist.github.com/matham/f6a07f8fb5e403feb440 in Betracht gezogen, um die DLL-

Siehe auch:
https://pytools.codeplex.com/workitem/1627 (woher es kommt)
https://github.com/numpy/numpy/wiki/windows-dll-notes#python -dlls
http://stackoverflow.com/questions/23804438/find-library-in-ctypes

@cgohlke Dies sind die DLLs in meinem Windows-Verzeichnis:

['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']

Der Versuch, meinen PATH mit SET PATH=; vor dem Aufrufen von Python zurückzusetzen, stürzt immer noch ab, aber das vollständige Entfernen der oben genannten DLLs aus dem Windows-Verzeichnis stoppt den Absturz. Scheint ein Problem mit der Pfadpriorität @carlkl zu sein.

@cgohlke , ich schlage folgende Änderung vor, um mit numpy + MKLs __init__.py zu testen

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

Wenn Sie die obigen DLLs vollständig aus dem Windows-Verzeichnis entfernen, wird der Absturz gestoppt.

Auf Nimmerwiedersehen.

Ich schlage vor, die folgende Änderung vorzunehmen, um mit numpy + MKLs __init__.py zu testen

Das funktioniert auf älteren Systemen nicht wirklich und, was noch wichtiger ist, es bricht Pakete, die von der DLL -

Ich finde es amüsant, dass ich anfangs die AddDllDirectory -Methode im numpy-Wiki gefunden habe, die teilweise @carlkl gutgeschrieben wurde, aber dann wurde meine Verwendung hier von @carlkl als Beispiel vorgeschlagen, und ich bin hier AddDllDirectory . Der Kreis schließt sich ...

Wie auch immer, ich wollte für andere, die dies in Betracht ziehen, beachten, dass die Zeile ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000) (und jedes andere der Nicht-Null-Flags) beim Laden einiger DLLs ImportError: DLL load failed: The parameter is incorrect Ausnahmen verursacht. Für mich geschah dies nur speziell mit einer von mingw-w64 (mingwpy) erstellten Erweiterung, die mit ffmpeg-DLLs verknüpft war, die auf debian mit mingw-w64 kreuzkompiliert wurden. Aber ich weiß nicht, ob das dafür verantwortlich war.

Da Python jedoch LoadLibraryEx nur mit LOAD_WITH_ALTERED_SEARCH_PATH und nicht mit LOAD_LIBRARY_SEARCH_USER_DIRS aufruft, es sei denn, SetDefaultDllDirectories wird auch mit LOAD_LIBRARY_SEARCH_USER_DIRS , LoadLibraryEx aufgerufen AddDllDirectory hinzugefügt wurden. Für mich scheint dies ein bisschen zu fragil zu sein, daher denke ich, dass ich wieder das DLL-Verzeichnis zum Pfad mit os.environ hinzufügen werde. Ich frage mich allerdings, ob ich das Wiki mit diesen Informationen aktualisieren soll.

Wie auch immer, hoffentlich war das nicht zu weit vom Thema entfernt.

@matham , dieses Code-Snippet sollte _zooba_ gutgeschrieben werden - siehe https://pytools.codeplex.com/workitem/1627. Die Zeile ctypes.windll.kernel32.SetDefaultDllDirectories(0x1000) ändert nichts am Verhalten von LoadLibraryEx mit LOAD_WITH_ALTERED_SEARCH_PATH . Es ändert hoffentlich das Verhalten von LoadLibraryA (_ohne_ LOAD_WITH_ALTERED_SEARCH_PATH ), das zum Laden von MKL_INTEL_THREAD.DLL direkt nachdem random \ mtrand.pyd geladen wurde und MKL_RT.DLL dann ruft MKL_INTEL_THREAD.DLL :

Protokollieren Sie sich vom Depency Walker während 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 stimmt, aber ich bezog mich auf das Wiki: (thanks to Steve Dower for the fragment, Carl Kleffner for finding it) , von dem ich annahm, dass du es bist :)

Die Fragilität, auf die ich mich bezog, ist, dass im Allgemeinen möglicherweise ein anderer Code zwischen dem Aufruf von SetDefaultDllDirectories , der dieses Flag setzt, und wann die Bibliothek tatsächlich geladen wird. Wenn Sie beispielsweise etwas importieren, das selbst SetDefaultDllDirectories aufruft, möglicherweise mit einem Wert (z. B. 0), der dazu führen kann, dass die DLL später beim Import nicht gefunden wird. Obwohl ich denke, dass dies hier kein Problem ist, wenn es sofort importiert wird.

@cgohlke , stimmt etwas nicht mit dem Vorladen von MKL_RT.DLL , MKL_INTEL_THREAD.DLL und MKL_CORE.DLL mit explizitem Pfadnamen auf numpy.core innerhalb von _init_numpy_mkl() ? Ich bin mir jedoch nicht sicher, ob das schrittweise Laden anderer erforderlicher MKL-DLLs dann funktioniert.

@cgohlke ,

Das folgende Snippet stellt (?) sicher, dass die MKL-DLLs aus numpy.core und nicht aus einem Windows-System oder einem Intel Redist-Ordner geladen werden. Die Reihenfolge des Ladens der DLLs ist wichtig. Zumindest funktioniert es für 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

Ich hatte das gleiche Problem und habe es auf mkl_intel_thread.dll in C:\Windows\System32 wie von Danielgeier angegeben.
Die ältere Version hatte unter anderem nicht die mkl_aa_fw_get_max_memory .
Die Erstellungszeit fiel mit der Installation der Asio4all-Audiotreiber zusammen. Nachdem ich diese deinstalliert hatte, die mehrere DLLs entfernt hatten, funktionierte es wieder (besser als nur DLLs in System32 alleine zu löschen).
Ich habe mit dem Zurückrollen und Aktualisieren der Anaconda-Distribution herumgespielt, aber das hat nicht funktioniert. Ich konnte mkl auch nicht mit anaconda unter Windows deaktivieren.

@ sebastian-schmidt, können Sie ausprobieren, ob das explizite Laden von MKL-DLLs aus dem Ordner numpy / core für Sie funktioniert, auch wenn veraltete MKL-DLLs im Windows-Systemordner installiert sind. Siehe oben: https://github.com/numpy/numpy/issues/6923#issuecomment -169073613

@carlkl , wo muss ich das Snippet hinzufügen?
Ich habe versucht, es der Datei hinzuzufügen, die ich als Test verwendet habe: https://gist.github.com/sebastian-schmidt/9bb97354b481750209fd3dac1e748d31 und es hat nicht funktioniert.
Der verknüpfte Pfad ist nur ein Unterverzeichnis, von dem aus ich die Datei aufrufe.
Muss ich es dem Init des Numpy-Moduls hinzufügen?

Die Funktion _init_numpy_mkl() ist Teil von @cgohlke numpy + mkl Rädern. Sie finden es in der Datei __init__.py . Es ist nicht Teil der offiziellen Numpy-Quellen.

Hier ist die Version in 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

Diese Funktion fügt den Ordner numpy/core zur Umgebung PATH . DLLs im Windows-Systemordner werden jedoch gegenüber DLLs im PATH bevorzugt. Willkommen in der DLL-Hölle.

Die alternative Version dieser Funktion https://github.com/numpy/numpy/issues/6923#issuecomment -169073613 lädt die MKL-DLLs von numpy/core in der richtigen Reihenfolge, ohne die PATH -Umgebung zu ändern. Alle DLL-Namen werden als explizite Dateinamen mit vollständig qualifiziertem Pfadnamen angegeben. Daher erwarte ich keine Probleme beim Abschatten von DLLs im Windows-Systemordner, habe dies jedoch nicht getestet.

Allerdings war mir eingefrorener Numpy in diesem Code-Snippet egal.

Ich habe die _init_numpy_mkl() in der Anaconda-Distribution auf Ihre Version geändert und dann hat es funktioniert (mit inkompatiblen DLLs in windows/system32 .

Gut zu hören!

Der Code in _init_numpy_mkl () ist Teil von @cgohlkes Numpy-Distribution und unter seiner Verantwortung.
@cgohlke : Kommentare zu https://github.com/numpy/numpy/issues/6923#issuecomment -169073613?

@ sebastian-schmidt, können Sie die Version mit AddDllDirectory (oder SetDllDirectoryW als Fallback) testen: siehe oben: https://github.com/numpy/numpy/issues/6923#issuecomment -168490201

@carlkl , die Version AddDllDirectory / SetDllDirectoryW funktioniert ebenfalls.
Test war immer nur das np.dot() Beispiel von Danielgeier.
Nebenbei bemerkt war die Software, die die mkl-Bibliotheken installiert, Amplitube und nicht die Asio4all-Treiber.

Auch ich habe das Problem auf Amplitube zurückgeführt.

Als ich versuchte: import matplotlib.pyplot as plt mit beiden Init-Versionen bekam ich eine Fehlermeldung:

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

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

Also wechselte ich zurück zur Anaconda Originalversion und ließ Amplitube deinstalliert.

@ sebastian-schmidt, zumindest funktioniert es bei mir. Das Importieren von numpy, scipy, matplotlib._png funktioniert auf meiner Box problemlos.

Die Deinstallation von MKL-DLLs aus den Windows-Systemordnern scheint jedoch die beste Lösung für diese Art von Problemen zu sein.

Zeit, dieses Problem zu schließen?

Hallo Leute. Nur für den Fall, dass noch jemand mit diesem Problem ist. Ich habe numpy 1.12 + mkl und hatte das gleiche Problem. Ich habe Amplitube 3 deinstalliert und jetzt funktioniert alles!

Hallo Leute,

Ich habe gerade das neueste numpy + mkl 1.13-Paket von hier von @cgohlke installiert .

Ich verwende Anaconda mit Python 3.6.1 64-Bit unter Windows 7.

Danach bekomme ich auch dieses DLL-Problem, es funktionierte einwandfrei für Version 1.12 von derselben Site.

Außerdem funktioniert der gesamte Code in einem Jupyter-Notizbuch. Dies geschieht nur in einer Konsole.

@carlkl Ich habe in meinem Anaconda-Ordner nach _init_numpy_mkl gesucht, aber keine Datei gefunden, die diese Zeichenfolge enthält. Das manuelle Anhängen von numpy/core an meine Variable PATH env funktionierte ebenfalls nicht.

Irgendwelche anderen Vorschläge?

Vielen Dank.

Als ich Skimage importierte, stieß ich auf das Problem "mkl_intel_thread.dll kann nicht geladen werden".
Ich kann keine mkl_intel_thread.dll in Windows / System32 finden, also habe ich die libiomp5md.dll in diesem Ordner gelöscht, genau wie @cgohlke es erwähnt hat. Es funktioniert.

Ich frage mich, ob https://github.com/numpy/numpy/issues/6923#issuecomment -169073613 in diesem Fall funktioniert, ohne dass MKL-DLLs aus Windows / System32 entfernt werden müssen. Dieses Snippet zeigt, dass es möglich ist, sieben (aber nicht alle) MKL-DLLs in den Ordner numpy / core zu laden, ohne dass zusätzliche Bibliotheken an die Umgebungsvariable PATH übergeben oder andere Tricks verwendet werden müssen. Es ist wichtig, diese 7 DLLs in der richtigen Reihenfolge zu laden. Alle anderen erforderlichen MKL-DLLs werden dann automatisch aus numpy / core anstelle des Ordners windows / system32 geladen.

Es ist noch unklar, ob dies in allen denkbaren Szenarien funktioniert. Zum Beispiel eingefrorene Python-Anwendungen. Auch Windows-Betriebssystemversionen können sich im Ladeverhalten der DLL unterscheiden.

Es erscheint mir vorteilhaft, diese Variante weiter zu untersuchen.

Wir gingen mit SetDefaultDllDirectories hin und her, # 10229 fügte es hinzu und # 11493 entfernte es. Ich denke, wir sind so weit gegangen, wie wir können. Es scheint die beste Option zu sein, andere Kopien von mkl aus PATH zu entfernen.

Bitte öffnen Sie erneut, wenn Sie nicht einverstanden sind.