News Intel MKL 2020.2: Neuer AMD-Workaround schneller als Zen-Kernel

[calluna]

Wenn jeder Hersteller seine Software dazu benutzt den Wettbewerb oder was auch immer zu unterdrücken anstatt die eigenen Produkte glänzen zu lassen wirds schnell kompliziert werden.

Ich stimme dir zu, so betrachtet steckt dahinter eine unschöne Taktik, vor allem wenn die MKL in Produkten steckt, bei denen es nicht sofort ersichtlich ist.

Ich wusste darum, als ich von Intel 6 Kern auf AMD 16 Kerne umgestiegen bin und dachte mir "conda install -c anaconda openblas"... und habe auch ohne MKL deutlich mehr Leistung.

Das einzige, was ich da anders sehe, ist das "glänzen" lassen, was ja wohl durch so etwas wie die MKL schwer möglich ist, wenn jede Optimierung auf die Befehlssätze hin dem Konkurrent ebenso zu gute kommt. - dann kann man nur durch neue Erweiterungen wie AVX512 oder eine bessere Architektur glänzen - aber dann fällt der unternehmerische Sinn für die MKL weg. (Außer es gibt einen gemeinsamen "Gegner" wie ARM bzw. Nvidia, um die x64 Plattform insgesamt zu verteidigen.)

Von daher hätte das sehr deutlich in der Dokumentation stehen sollen... da stimme ich dir zu.

 

[Holt]

Außer es gibt einen gemeinsamen "Gegner" wie ARM bzw. Nvidia, um die x64 Plattform insgesamt zu verteidigen.

Zwar nutze ich die Matlib nicht, aber ein Entwickle der damit Prototypen für neue Algorithmen baut, hat mir versichert, dass man locker Faktor 5 bis 10 rausholen kann, wenn man den Algorithmus dann in C++ Code implementiert. Schon von daher ist die ganze Diskussion um die Performance mit Matlib irgendwie verfehlt, wenn es schnell sein soll, dann schreibt man richtigen Code und keine Scripte!

 

[calluna]

@Holt

Nur eine kleine Korrektur... Matlab... abgeleitet von "Matrix Laboratory". ;-)

Ja, aber in C++ wird dieser Entwickler sicher auch auf irgendeine BLAS oder LAPACK Implementierung zurückgreifen.

Die Skriptsprache von Matlab ist nur dann effizient, wenn die eingebauten Funktionen genutzt werden.

 

[Holt]

Nur eine kleine Korrektur

Egal, fällt für mich unter belanglos.

abgeleitet von "Matrix Laboratory". ;-)

Die richtigen Matrix Befehlserweiterungen kommen ja erst noch.

 

[ebird]

Wer einen Trick nutzt, kann sich aber nicht beschweren wenn es Probleme gibt.

Logische Schlussfolgerung ist nicht gerade Deine Stärke

 

[Wadenbeisser]

Sicher, die Bibliothek funktioniert ebenso auf AMD... aber der strittige Punkt ist dabei: ist es rechtlich oder moralisch richtig.

Warum sollte es rechtlich oder moralisch strittig sein wenn sie selbst einräumen das es auf nicht Intel Prozessoren läuft und lediglich die Formulierung an den aktuellen Kenntnisstand anpassen?
Vielleicht sollte man lieber mal die Frage stellen wie korrekt diese Vorgehensweise ist denn es geht schließlich nicht um Optimierung sondern um die Nutzung der Befehlssätze die bereits von der Software unterstützt werden.

 

[DarkSoul]

wenn es schnell sein soll, dann schreibt man richtigen Code und keine Scripte!

Also in Assembler, mit dem richtigen Befehlssatz für die Ziel-CPU.

 

[Holt]

Also in Assembler

Habe ich C++ oder Assembler geschrieben? Ok diese Denksportaufgaben ist mag unfair weil zu schwer sein, aber versuche es doch trotzdem

 

[Wadenbeisser]

Wer einen Trick nutzt, kann sich aber nicht beschweren wenn es Probleme gibt.

Und wenn es keine Probleme gibt belegt es das es dafür keine technischen Gründe gibt.

 

[d3vz3r0]

ASM Anweisung sind direkt in C++ Code implementierbar.

https://en.cppreference.com/w/cpp/language/asm

 

[Ned Flanders]

Das einzige, was ich da anders sehe, ist das "glänzen" lassen, was ja wohl durch so etwas wie die MKL schwer möglich ist, wenn jede Optimierung auf die Befehlssätze hin dem Konkurrent ebenso zu gute kommt.

AVX512 hat nur Intel. Dadurch alleine glänzen die ja schon in dem Markt. Die MKL sollte schonmal dem Zweck dienlich sein diesen neuen Befehlssatz weitreichend zu unterstützen. Daher verstehe ich auch nicht warum sich Intel selbst torpediert und den nicht weitreichend in die CPUs bringt sondern da die eigenen Produkte segmentiert. OpenBLAS unterstützt AVX512 bislang nur mau.

Desweiteren könnten sie ja auch auf die eigene Architektur (Cache Größen, Sprungvorhersage etc.) optimieren. Da würden Intel CPUs immernoch glänzen.

dachte mir "conda install -c anaconda openblas"

Alles Richtig gemacht. Nur wie gesagt, das ist ne komfortable Situation in der Matlab, Simulink, Ansys, Microsoft R ... Anwender leider nicht sind und die sie vorher auch nicht erkennen können. Das ist durchaus ein Fehler von diesen Herstellern, nur die hatten auch nicht wirklich eine transparente Dokumentation zur Verfügung und müssen sich auf das verlassen können was im Dev Guide steht.

Das ist imho der Kern der Kritik.

 

[=rand(10)]

Manche meinen ja, man könne dann einfach auf eine Validierung verzichten, nur fallen alle Fehler wie falsche Ergebnisse (wie man sieht wird ja die FPU intensiv genutzt und nicht nur Integeroperationen) oder Abstürze dann doch wieder auf Intel zurück und sind dann viel schlimmer als ein Performancenachteil.

Sorry, das ist ein Strohmann-Argument.

Wenn es ernsthaft nur darum gänge; was bringt dann Intel dazu die Runntime-Variable zu entfernen? Könnte Intel doch sogar dokumentieren: "Bringt perfekte Performance, aber nicht unser Problem wenn auf nicht Intel-Produkten nicht vernünftig funktioniert". Wäre jeder zufrieden.

Und das ist nur das oberflächlich offensichtliche Argument. Wenn du ein bisschen in die Tiefe schaust:

https://www.agner.org/forum/viewtopic.php?f=1&t=6

Stellst du fest: Alter Intel-Compiler auf neuem Intel-Prozessor bringt komischerweise auch beste Performance. Ohne dass Intel die Möglichkeit gehabt hätte, irgendetwas zu validieren.

Also bitte; es wäre schön, wenn wir diesen Sachverhalt nicht wie Intels Marketingabteilung ("wir optimieren halt nur für Intel") nennen könnten, sondern wie es tatsächlich ist: Wenn Intel AMD-Prozessor erkännt, lässt Intel eigene Software langsamer laufen.

 

[calluna]

@Ned Flanders

Hm, den Punkt habe ich übersehen... eine weite Verbreitung und gute Unterstützung von AMD ist für Intel ein Vorteil, weil auch nur dann AVX512 gut unterstützt wird, wenn Dritte bedenkenlos zur MKL greifen können.

@Holt

In der Praxis zählt aber oft mehr die Geschwindigkeit der Entwicklung... deswegen ist auch Python so beliebt... und alles Laufzeitkritische wird in Bibliotheken ausgelagert, die in Cython, C, Fortran, C++... und meinem neuen Liebling Rust geschrieben sind.

Und es ist einfach angenehm in einer Skriptsprache wie Matlab so etwas zu schreiben: x = A \ b ... um ein lineares Gleichungssystem zu lösen. ;-)

 

[Piktogramm]

@=rand(10)
Ich würde ja erwarten, dass Intel neue Hardware umgekehrt auch gegen den eigenen Softwarestack testet.

Ansonsten verstehe ich das Geschimpfe nicht. Propritäre Softwarelösungen sind proprietär, es folgt der Wetterbericht:

 

[Crythunder]

Es ist realitätsfern und schade, dass manche Intels Machenschaft verteidigen. Zum einen ist niemandem, der sich nicht besonders tiefgehend mit einer spezifischen Software auskennt, ersichtlich, dass AMD Prozessoren ohne technischen Hintergrund benachteiligt werden. Dann ist es auch nicht möglich jeden Entwickler dazu zu zwingen die Library zu wechseln oder eine Alternative anzubieten. Egal, ob es technisch nicht ohne große Umstände realisierbar ist, die das Firma nicht finanziell tragen möchte oder es anderweitig nicht will oder gar dubiose Abmachungen im Hintergrund stattfinden.

Die Endkunden können auch nicht ohne massive Einschnitte ihren Workflow vollständig auf ein Konkurrenzprodukt umstellen. Wegen einigen Performanceeinbußen wird das kein Management veranlassen. Deshalb ist es hier notwendig notfalls gesetzlich gegenzusteuern.
Der kapitalistische Status ist leider, dass sich alles auf wenige große Firmen fokussiert und diese eventuell eine marktbeherrschende Stellung mit ihrer Software einnehmen. Einfach kurzerhand Ansys zu kicken, wegen MKL ist beinahe eine wirtschaftliche Unmöglichkeit.

Wenn sowas stattfindet, müssen deutliche Warnhinweise ersichtlich sein, dass bestimmte Produkte ausgebremst werden. Vielleicht sogar eine vollständige Nutzungssperre gegenüber AMD Prozessoren einführen, damit gar nicht die Illusion auftreten kann, dass es kein Monopol gibt.

 

[Ned Flanders]

Einfach kurzerhand Ansys zu kicken, wegen MKL ist beinahe eine wirtschaftliche Unmöglichkeit.

Einfach den Ansys Support mit Feature Request Anfragen sättigen. Hat bei Matlab auch funktioniert. Ohne erkennbare Nachfrage wird sich nirgends etwas ändern.

Support Anfragen sind der Schlüssel zum Support ;-)

 

[DarkSoul]

Ok diese Denksportaufgaben ist mag unfair weil zu schwer sein, aber versuche es doch trotzdem

Du hast "schnell" geschrieben, nicht alles was aus C/C++ raus kommt ist zwangsläufig "schnell". Außerdem es gibt kein "C" oder "C++", das ist nur ein Standard. Je nach verwendetem Compiler und den verwendeten Klassen und natürlich Compiler-Optionen kommen da zwar, im Vergleich zu Skriptsprachen, "schnelle" Binaries raus, teilweise auch optimiert, aber dennoch kann man mit Assembler noch mehr rausholen. Aber ich weiß, das war eine Denksportaufgabe die man nicht nachvollziehen kann, wenn man nur den Namen von Programmiersprachen aber keine Debugger kennt.

 

[max9123]

Als Entwickler von beispielsweise Matlab oder Anaconda war es bei der Auswahl der BLAS nicht einsehbar, das die MKL nicht Intel CPUs aktiv benachtleiligt.

Nun ja, das nicht Intel CPUs in der MKL benachteiligt werden ist seit Jahren so ziemlich jedem bekannt der in einem entsprechenden Bereich arbeitet, selbstverständlich auch den Entwicklern.
Lange Zeit hatte AMD ohnehin keine konkurrenzfähigen CPUs (vor allem FPUs) daher hat dieser Umstand auch kaum jemanden gestört.

Von dem abgesehen ist es mit Debug Environment Variablen auch nicht getan. Auch die
KMP_AFFINITY und das KMP_CPUINFO_FILE Beispiel sollten richtig konfiguriert werden, ansonsten kann die Performance bei Prozessoren mit vielen CCX auch eher mäßig ausfallen.

 

[wayne_757]

Es geht nicht Floating point precision, aber Lesen und Verstehen ist, wie die Pisa Studie ja ergeben hat, für so manchen eine große Herausforderung.

Aha. Was soll es jetzt neben Hardwarebugs und FPU Precision issues noch geben?

 

[calluna]

Wenn ich das gerade richtig gesehen habe, gibt es in der oneAPI von Intel auch den MKL Teil mit Source Code auf Github... das ganze Projekt von Intel zu einer einheitlichen API für ML, um verschiedenste Hardware zu nutzen, ist OpenSource.