News Intel MKL: Workaround erhöht Leistung auf AMD Ryzen signifikant

[MaverickM]

Ich wette dem Matlab-Entwicklern war dies gar nicht bewusst. Jetzt wo das bekannt ist, müssen sie natürlich handeln.

Du willst mir sagen, es wäre den Entwicklern nicht aufgefallen, dass ihre Software auf AMD-CPUs bis zu 400% langsamer läuft? Und dann hätte man nicht nachgeschaut woran das liegt und gemerkt, dass Befehlssätze, obwohl vorhanden, nicht genutzt werden!?
Vielleicht testet Mathworks ja aber ihre Software auch nur in VMs...

 

[Sun_set_1]

Eieieiei. [...] Gepatchter MKL Code (Fenuine statt Genuine, sonst nichts, also nur 1 Byte geändert):

Autsch. Erinnert stark an Ferrari vorn paar Wochen, die auf einmal 10km/h langsamer wurden als RedBull darum bat, dochmal den Code für die Überprüfung der Einspritzmenge zu untersuchen.

“Warum wart ihr heute deutlich langsamer?“
„Ja..., also der Wind...“


Ist klar.

 

[DocWindows]

Geht umgekehrt auch? Das sie quasi AuthenticAMD als korrekte Antwort nimmt? oder beides? Das wäre ja die große Lösung.

Ich kann die VendorID Checks komplett rauspatchen, kein Problem. Aber es wäre natürlich rechtlich problematisch so etwas hier öffentlich zu posten, etwa in Form eines Patchtools. Deshalb werde ich das unterlassen.

 

[Ned Flanders]

Macht Sinn!

 

[Sightus]

Moin,

ich nutze Matlab 2019b unter Windows Server 2019, aber die vorgeschlagenen Methoden funktionieren nicht. Grundsätzlich;
1) Muss Intel MKL installiert sein oder genügt jenes, dass Matlab mitbringt?
2) Ich habe Intel MKL geladen und installiert, nun habe ich auch die "mklvars.bat", welche jedoch "MKL_DEBUG_CPU_TYPE=5" nicht verarbeiten kann.

Wenn ich "MKL_DEBUG_CPU_TYPE=5" also globale Umgebungsvariable in Windows eintrage, dann zeigt mir Matlab nach "version -blas" nach wie vor "auto" und nicht AVX2 an.

Wo liegt mein Fehler? Muss ich die Intel MKL noch irgendwie einstellen?

 

[Sun_set_1]

@DocWindows

Was ist denn, wenn Du die komplette Funktion mal auskommentierst? Theoretisch müsste das Programm doch dann crashen, insofern diese wirklich noch weitere Relevanz hat. Oder zumindest auf den kleinsten Fallback Modus fallen, sprich SSE.

Wenn er dann, wider Erwarten, auf einmal doch anfängt das Feature Set abzufragen wäre es ein eindeutiger Beleg für nachträgliches Einbauen / Betrug.

 

[ryzen-]

Mich wundert hier nur immer wieder, wie man das bei Intel schafft Skandal über Skandal unter den Teppich zu kehren. Solche Praktiken waren ja schon vor 10-15 Jahren mehrfach aufgeflogen, von gefakten Benchmarks bis sonst was... klar sind andere Firmen auch keine Engel aber hier wurde immer wieder krass das Monopol ausgenutzt und diese Art der Manipulation wiegt mindestens genauso schwer wie die geschmierten Händler wofür Intel wenigstens mal Strafe zahlen musste...
Hier muss man auch nicht groß um den heißen Brei herum reden, so etwas ist kein Zufall, es ist volle Absicht von Intel und einkalkuliert.
400% muss man sich mal vor Augen führen... im Prinzip sieht man aber auch was gute Anpassung ausmacht, ist halt generell die Schwäche am PC, die Power wird selten voll ausgenutzt. Was da an Leistung flöten geht... traurig!

 

[Ned Flanders]

Wenn ich "MKL_DEBUG_CPU_TYPE=5" also globale Umgebungsvariable in Windows eintrage, dann zeigt mir Matlab nach "version -blas" nach wie vor "auto" und nicht AVX2 an.

Wo liegt mein Fehler? Muss ich die Intel MKL noch irgendwie einstellen?

Kein Fehler. Der AVX Pfad sollte trotzdem aktiv sein. Nimm die Variable nochmal raus und mach einen "bench(4)".

Dann setz die Variable und mach nochmal einen bench(4). Der unterschied in Sparse sollte nicht zu übersehen sein.

P.S.: Du musst keine MKL installieren. Die kommt mit Matlab.

Ergänzung (19. November 2019)

Endlich mal eine eindeutige Aussage!

Aber du solltest eben auch nicht naiv glauben Intel macht das ohne Grund.

https://twitter.com/LegitReviews/status/1196517513909227522

Hier sind wirklich ein Umdenken an vielen Stellen gefragt, weswegen ich das eben auch bewusst mal in die Öffentlichkeit gezerrt hab. Hat ja zum Glück auch ganz gut funktioniert.

 

[NameHere]

@Ned Flanders Der Tweet macht Robert Hallock wohl sehr nachdenklich

 

[yummycandy]

@Ned Flanders Der Tweet macht Robert Hallock wohl sehr nachdenklich

Ist mir auch aufgefallen. Kann aber sein, daß er das nicht auf den Schirm hatte. Gibt ja außer ihm noch andere Leute bei AMD.

 

[AMDprayer]

Du willst mir sagen, es wäre den Entwicklern nicht aufgefallen, dass ihre Software auf AMD-CPUs bis zu 400% langsamer läuft? Und dann hätte man nicht nachgeschaut woran das liegt und gemerkt, dass Befehlssätze, obwohl vorhanden, nicht genutzt werden!?
Vielleicht testet Mathworks ja aber ihre Software auch nur in VMs...

Ja will ich. Ich hätte hier auf Arbeit auch kein einziges AMD-Ryzen System zum Testen zur Verfügung. Grund: die Rechner kommen meist von einem exklusiven Partner, z.B. Dell. Diese bieten oft immer noch keine Workstations mit AMD an dank exklusiver Intel-Knebelverträge. Bei Dell finde ich nur Alienware-Gaming-PCs mit Ryzen. Als Entwickler kann man sich das leider nicht aussuchen.

 

[DocWindows]

Was ist denn, wenn Du die komplette Funktion mal auskommentierst? Theoretisch müsste das Programm doch dann crashen, insofern diese wirklich noch weitere Relevanz hat. Oder zumindest auf den kleinsten Fallback Modus fallen, sprich SSE.

Habe ich doch schon probiert. Siehe #299.

 

[blöderidiot]

Der Tweet macht Robert Hallock wohl sehr nachdenklich

Ja, ganz bestimmt. Weil nämlich überhaupt nicht seit mindestens 10 Jahren AMD mit Intel wegen "GenuineIntel" im Clinch liegt. Und weil alle schon vergessen haben, dass in Intel-ICC-kompilierten Binaries ein anderer Codepath verwendet wird, wenn nicht GenuineIntel ausgelesen wurde. So ist die Welt. Da kommt das mit MatLab gaaaanz überraschend, weil nämlich niemand gemerkt haben kann, dass seit Jahren viele Berechnungen auf AMD 6x langsamer als auf gleichwertigem Intel waren. Ganz klar

 

[ZRUF]

Da hat @AMDprayer schon recht. Man testet nur mit dem was man hat. Und selbst, wenn einem auffällt, dass auf AMD-Maschinen alles länger dauert, wer weiß erstmal, ob das an den CPUs oder der Lib liegt. Der erste Gedanke ist dann wohl: Ok AMD CPUs sind wohl hier schlecht aufgestellt. Die Lib lief ja schon immer und wird dann so schnell nicht in Frage gestellt.
Ist das richtig? Nicht zwingend. Nachvollziehbar ist das aber schon.
Trägt MathWorks die Verantwortung nicht weiter getestet zu haben? Ja. Hätte es sich für sie finanziell rentiert den Aufwand zu betreiben, bei dem vergleichsweise geringen Marktanteil von AMD im Businessumfeld oder gar in wissenschaftlichen Einrichtungen? Eher nein. Also hat man sich das gespart.
Mit höherem Marktanteil von AMD wird es aber auch für die Softwarehersteller immer wichtiger auch sicherzustellen, dass AMD-Rechner bestmöglich laufen. Von daher gehe ich davon aus, dass zukünftig noch mehr solcher Fälle auftreten werden.

 

[domian]

Achso, deshalb wurde Intel in jüngster Zeit von einem Gericht auferlegt genau die selbe VendorID Abfrage aus ihrem Intel Compiler zu entfernen.

Ich halte das wie gesagt für unsittlich, jedoch dürfte aus meinem Rechtsverständnis Intel in Intel Compilern abgragen was es will. Umgekehrt hätte sicher auch AMD die Möglichkeiten. Ich möchte aber keinen der beiden MN-Konzerne in Schutz nehmen, deren Ausrichtung in Gewinnmaximierung und Marktwachstum liegt. Hierzu gehört nunmal auch das kaltstellen der Konkurrenz. Solange Negativwerbung zulässig ist, ist es m.M. auch das frisieren von Compilern.

 

[SVΞN]

Artikel-Update: Workaround liefert Lösung nach 10 Jahren
Wie dem offiziellen englischen Wikipedia-Eintrag der Math Kernel Library zu entnehmen ist, existieren die Leistungseinbußen der Programmbibliothek im Zusammenhang mit einer ganzen Reihe mathematischer Anwendungen wie NumPy, SymPy und eben Matlab bereits seit gut 10 Jahren. Was der Routine unter anderem zu einem wenig schmeichelhaften Spitznamen („verkrüppel AMD“) verholfen hat.

However, as long as the master function detects a non-Intel CPU, it almost always chooses the most basic (and slowest) function to use, regardless of what instruction sets the CPU claims to support. This has netted the system a nickname of "cripple AMD" routine since 2009. As of 2019, MKL, which remains the choice of many pre-compiled Mathematical applications on Windows (such as NumPy, SymPy, and MATLAB), still significantly underperforms on AMD CPUs with equivalent instruction sets.

Mittlerweile haben auch andere Tech-Magazine wie beispielsweise @LegitReviews den Sachverhalt aufgegriffen, von dem jetzt auch Robert Hallock, Senior Technical Marketing Manager bei AMD, Kenntnis genommen hat. Eine offizielle Stellungnahme eines der Unternehmen steht indes noch aus.

[Embed: Zum Betrachten bitte den Artikel aufrufen.]​

 

[Rickmer]

Die Antworten auf den Tweet sind auch interessant.

Zwei runter -> Hinweis auf NumPy - der CB Artikel
Drei runter -> Charlie Demerjian von SemiAccurate

Ich bin mal auf offizielle Antworten betroffener Unternehmen gespannt.

 

[MaverickM]

Ja will ich. Ich hätte hier auf Arbeit auch kein einziges AMD-Ryzen System zum Testen zur Verfügung. Grund: die Rechner kommen meist von einem exklusiven Partner, z.B. Dell. Diese bieten oft immer noch keine Workstations mit AMD an dank exklusiver Intel-Knebelverträge. Bei Dell finde ich nur Alienware-Gaming-PCs mit Ryzen. Als Entwickler kann man sich das leider nicht aussuchen.

Ich weiß wie das abläuft. Es ist trotzdem eine fadenscheinige Ausrede. Als Entwickler muss man möglichst viele Systeme abdecken. Und bei gerade mal zwei Herstellern von x86 CPUs ist es eigentlich nicht so wahnsinnig schwierig.

Ich behaupte einfach mal dreist, es hat sie schlichtweg nicht interessiert. Entweder weil Geld von Intel geflossen ist, oder wegen grober Inkompetenz.

 

[konkretor]

@SV3N wenn du nur auf die deutsche wiki links, steht nix dazu drin, mußt schon die englsiche nehmen :-)


https://en.wikipedia.org/wiki/Math_Kernel_Library

 

[DocWindows]

Man sollte die Kirche jetzt aber auch mal im Dorf lassen, die Mistgabeln runternehmen und die Fackeln wieder ausmachen.

Unterm Strich heißt die Intel MKL nicht umsonst Intel MKL. Die Mathematik die sie kapselt ist kein Geheimnis. Das was Intel hier durchaus absichtlich macht, ist, den Nutzern dieser Bibliothek ihre Arbeit zu erleichtern, wenn sie Intel CPUs nutzen. Quasi eine kostenlose Dreingabe.
Niemand ist daran gehindert eine offenen Bibliothek mit ähnlicher oder gleicher Funktion zu entwickeln und sie dann zu verschenken.
Dass sie von Matlab und anderen Produkten genutzt wird kann man Intel schwer anlasten. Auch diese Firmen hätten die Mathematik selbst implementieren können. Haben sie aber nicht.

Wenn ich es schon innerhalb von 2 Stunden schaffe die Bremse zu identifizieren und probeweise zu lösen (ohne Quellcodeeinsicht), dann wäre diese Entdeckung für die Entwickler von Matlab auch kein Problem gewesen. Kann mir keiner erzählen dass die jetzt aus allen Wolken fallen. Man hat sie aber trotzdem benutzt und in Kauf genommen dass nur Intel-CPUs Beschleunigung bieten.