Ned Flanders
Fleet Admiral
- Registriert
- Aug. 2004
- Beiträge
- 11.612
Auf jeden Fall.
News Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround
- Ersteller SVΞN
- Erstellt am
- Zur News: Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround
Ned Flanders
Fleet Admiral
- Registriert
- Aug. 2004
- Beiträge
- 11.612
Es tut sich gerade wieder sehr interessantes an der MKL Front:
Letzteres ist natürlich klar grundsätzlich begrüßenswert
Der Python Contributor Daniel de Kros hat jetzt allerdings eine neue Möglichkeit gefunden das Ergebnis der CPU ID Abfrage der MKL unter Linux mit sehr einfachen Mitteln zu faken. In Kürze, die MKL benutzt eine 'mkl_serv_intel_cpu_true' Abfrage um die Identität des CPU Vendors zu überprüfen. Wenn 1 zurück kommt, benutzt die MKL den entsprechenden Intel Codepfad. Wenn 0 zurück kommt benutzt die CPU gegebenenfalls den neuen ZEN Codepfad, welcher (bislang) allerdings nicht alle Matrix Operationen beschleunigt (dgemm wird beschleunigt, sgemm nicht), andere Funktionen wie Inverse scheinbar auch nicht.
Mit
Hat danieldk nun einen Weg gefunden, mit dem er die Abfrage abfängt und diese immer mit 1 = true zurück meldet. Im oben verlinkten Blog erklärt er die Details.
Daraufhin beschleunigt die MKL auch auf seinem 3700x sgemm Operationen ebenso wie auf einem Intel System. Jetzt könnte man anehmen, dass Intel eben noch nicht fertig ist mit dem Implementieren des ZEN spezifischen Codepfads. Das wäre aber eine gewisse Merkwürdigkeit, da ja durch die Validierung durch Mathworks bewiesen ist, dass es keines spezifischen ZEN Codepfad bedarf. Der aktuelle AVX2 Kernel für Intel CPUs läuft auch auf AMD Prozessoren korrekt und schnell.
Besonders merkwürdig ist obendrein, dass dgemm Operationen im Zen Kernel in der MKL 2020.2 langsamer sind. Nach dem Faken der Intel ID auf dem AMD System sind auch diese schneller als wenn die MKL den ZEN Kernel zum Berechnen verwendet. In anderen Worten: Der für AMD CPUs vorgesehene Kernel ist auf AMD langsamer als der für Intel vorgesehene Kernel.
Zusammenfassend: Intel scheint sich tatsächlich zu bewegen und nimmt in die MKL einen Zen spezifischen Kernel auf, der nun nicht mehr blind auf SSE basiert. Allerdings ist dieser spezifisch für AMD geschriebene Pfad langsamer als der für Intel CPUs vorgesehene. Ob sich daran noch etwas tut wird man abwarten müssen. Natürlich auch wie Intel auf den neuen Workaround reagiert.
Das ganze Thema kocht gerade auf den einschlägigen Seiten wie Hackernews, auf Twitter (Suchterm MKL+AMD) und auch auf Reddit wieder deutlich hoch. Daniel de Krös selbst geht von folgenden Möglichkeiten aus.
Auch im Pytorch Github gibt es mittlererweile Diskussionen
Auch Agner Fog (Wissenschaftler an der Technical University of Denmark und Autor von Software Optimization Guides), der sich mit der gesamten Thematik seit langem beschäftigt, hat in seinem Blog die Historie und Situation noch einmal komplett zusammengefasst. Er zeigt auch einige Korrespondenz mit Intels Software Ingenieuren die lesenswert ist. Auch er bietet einige neuartige Patches als Workarounds für durch Intel Compiler mit diskriminierenden CPU Dispatchern versehene Libraries auf seiner Seite an.
Meine Anfrage bei Mathworks (kurzer Dienstweg) wie sich Matlab verhalten wird hat als inoffizielle Antwort erbracht, dass das nächste Major Release von Matlab (2020b) aufgrund der Thematik wohl erstmal mit MKL 2020.0 und aktiviertem Debug Mode ausgeliefert werden wird, anstatt mit der neuesten Version.
Die beste Neuigkeit @SV3N , es gibt zumindest unter Linux einen neuen, einfachen Workaround für sämtliche MKL verwendende Software.
Gruss,
Ned
- Intel hat definitiv die Verwendung des Debug Mode in der MKL mit Release 2020.1 und folgend unterbunden. Das setzen der Variablen MKL_DEBUG_CPU_TYPE=5 hat keinen Effekt mehr.
- Gleichzeitig scheint Intel spätestens ab 2020.2 (aktuelle Version) einen Zen Kernel für AMD CPUs in die MKL einzupflegen
Letzteres ist natürlich klar grundsätzlich begrüßenswert
Der Python Contributor Daniel de Kros hat jetzt allerdings eine neue Möglichkeit gefunden das Ergebnis der CPU ID Abfrage der MKL unter Linux mit sehr einfachen Mitteln zu faken. In Kürze, die MKL benutzt eine 'mkl_serv_intel_cpu_true' Abfrage um die Identität des CPU Vendors zu überprüfen. Wenn 1 zurück kommt, benutzt die MKL den entsprechenden Intel Codepfad. Wenn 0 zurück kommt benutzt die CPU gegebenenfalls den neuen ZEN Codepfad, welcher (bislang) allerdings nicht alle Matrix Operationen beschleunigt (dgemm wird beschleunigt, sgemm nicht), andere Funktionen wie Inverse scheinbar auch nicht.
Mit
Code:
int mkl_serv_intel_cpu_true() {
return 1;}Hat danieldk nun einen Weg gefunden, mit dem er die Abfrage abfängt und diese immer mit 1 = true zurück meldet. Im oben verlinkten Blog erklärt er die Details.
Daraufhin beschleunigt die MKL auch auf seinem 3700x sgemm Operationen ebenso wie auf einem Intel System. Jetzt könnte man anehmen, dass Intel eben noch nicht fertig ist mit dem Implementieren des ZEN spezifischen Codepfads. Das wäre aber eine gewisse Merkwürdigkeit, da ja durch die Validierung durch Mathworks bewiesen ist, dass es keines spezifischen ZEN Codepfad bedarf. Der aktuelle AVX2 Kernel für Intel CPUs läuft auch auf AMD Prozessoren korrekt und schnell.
Besonders merkwürdig ist obendrein, dass dgemm Operationen im Zen Kernel in der MKL 2020.2 langsamer sind. Nach dem Faken der Intel ID auf dem AMD System sind auch diese schneller als wenn die MKL den ZEN Kernel zum Berechnen verwendet. In anderen Worten: Der für AMD CPUs vorgesehene Kernel ist auf AMD langsamer als der für Intel vorgesehene Kernel.
Zusammenfassend: Intel scheint sich tatsächlich zu bewegen und nimmt in die MKL einen Zen spezifischen Kernel auf, der nun nicht mehr blind auf SSE basiert. Allerdings ist dieser spezifisch für AMD geschriebene Pfad langsamer als der für Intel CPUs vorgesehene. Ob sich daran noch etwas tut wird man abwarten müssen. Natürlich auch wie Intel auf den neuen Workaround reagiert.
Das ganze Thema kocht gerade auf den einschlägigen Seiten wie Hackernews, auf Twitter (Suchterm MKL+AMD) und auch auf Reddit wieder deutlich hoch. Daniel de Krös selbst geht von folgenden Möglichkeiten aus.
Auch im Pytorch Github gibt es mittlererweile Diskussionen
Auch Agner Fog (Wissenschaftler an der Technical University of Denmark und Autor von Software Optimization Guides), der sich mit der gesamten Thematik seit langem beschäftigt, hat in seinem Blog die Historie und Situation noch einmal komplett zusammengefasst. Er zeigt auch einige Korrespondenz mit Intels Software Ingenieuren die lesenswert ist. Auch er bietet einige neuartige Patches als Workarounds für durch Intel Compiler mit diskriminierenden CPU Dispatchern versehene Libraries auf seiner Seite an.
Meine Anfrage bei Mathworks (kurzer Dienstweg) wie sich Matlab verhalten wird hat als inoffizielle Antwort erbracht, dass das nächste Major Release von Matlab (2020b) aufgrund der Thematik wohl erstmal mit MKL 2020.0 und aktiviertem Debug Mode ausgeliefert werden wird, anstatt mit der neuesten Version.
Die beste Neuigkeit @SV3N , es gibt zumindest unter Linux einen neuen, einfachen Workaround für sämtliche MKL verwendende Software.
Gruss,
Ned
Zuletzt bearbeitet:
- Registriert
- Juni 2007
- Beiträge
- 22.970
Danke @Ned Flanders wird heute Abend aufgegriffen. Vielen Dank für den Hinweis und die Unterstützung bei diesem doch etwas komplexeren Thema.
Liebe Grüße,
Sven
Liebe Grüße,
Sven
Man darf wirklich gespannt sein, wie Intel mit MKL weiter vorgeht. Das Argument der zusätzlichen Arbeit fällt ja somit weg, lässt ja durchaus auf die "klassischen" Beweggründe schließen 
Die Reaktionen bisher von Mathworks finde ich dagegen extrem positiv, hätte nicht gedacht, dass man dort so flexibel ist und gegenüber Intel doch recht provokante Entscheidungen trifft.
Die Reaktionen bisher von Mathworks finde ich dagegen extrem positiv, hätte nicht gedacht, dass man dort so flexibel ist und gegenüber Intel doch recht provokante Entscheidungen trifft.
