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

[Hallo32]

Als ob dieser "Fix" nicht schon vorher bekannt war. Der Aufwand liegt doch nicht daran ein paar Parameter zu ändern sondern sicher zu stellen, dass die entsprechenden Codepfade auch auf AMD CPUs immer exakt die gewollten Ergebnisse liefern und unter keinen Umstand (zusätzliche) Fehler provozieren. Wobei das perspektifisch auch auf alle kommenden Versionen der MKL zutreffen muss.

Genau, die Verifikation des Codes ist die Arbeit.

 

[MichiSauer]

Also nach ein paar Stunden durchsuchen diverser Librarys etc. ist mir einiges aufgefallen, was die teils absurden Vorteile von Intel/NVidia Comps im CAD-Sektor erklären kann.

1. Scheinen fast alle gängigen CAD-Programme die MKL-Bibliothek zumindest in Teilen zu nutzen.
SolidWorks verwendet Sie zur Beschleunigung von Vektorbasierten Aufgaben, andere Systeme nutzen sie für FEM-Berechnungen, Soll-Ist-Vergleiche, Spline-Generation etc.
Falls hier auf AMD-Systemen auch die MKL abgegriffen wird macht das einen enormen Leistungsnachteil aus. Nachprüfen kann ich das leider nicht, da mir keine Systeme und Programme zur Verfügung stehen.
Habe zwar 2 CAD-Lizenzen, aber nur Intel-Rechner und Laptops im Haus (Alter Xeon und n 6700HK im Laptop)

2. Zusätzlich greifen viele CAD-Programme auf CUDA für die Hardware-Beschleunigung zurück.

3. Habe mit Fusion 360 auf einem Intel/Nvidia-System und aktuell auf einem Ryzen (2700X)/Nvidia-System nahezu gleiche Leistungsparameter. Allerdings sobald ich auf Vektorbasierte Berechnungen zugreife wird's doch sehr träge. Intel scheint da etwas schneller. Kann aber auch an der Core-Auslastung liegen, wo's dem Ryzen da nicht ganz so liegt und Fusion gerne einen Kern bevorzugt.

Müsste man alles mal Testen, leider ist mir das jedoch nicht möglich.

 

[Ned Flanders]

Der Aufwand liegt doch nicht daran ein paar Parameter zu ändern sondern sicher zu stellen, dass die entsprechenden Codepfade auch auf AMD CPUs immer exakt die gewollten Ergebnisse liefern und unter keinen Umstand (zusätzliche) Fehler provozieren.

unterstellst du jetzt das die mkl im avx2 codepath non konformen avx Code ausgibt (und welche Befehle sollten das sein, die zwar nicht crashen, aber falsche rechenergebnisse liefern) oder unterstellst du, dass AMD CPUs nicht mit AVX2 Code umgehen können und dabei ... Rechenfehler .. auftreten. Könntest du das noch etwas ausführen? konkreter bitte!

 

[Ephesus]

Motor Kontroll Leuchte

 

[Piktogramm]

Er scheint ja wohl zumindest nicht allgemein bekannt gewesen zu sein. Irgendeine verstaubte Forenseite zähle ich jetzt mal nicht. Jetzt kann sich jedenfalls so leicht niemand mehr heraus reden. "Hab ich nicht gewusst."
Jetzt wird sich auf jeden Fall etwas dauerhaft ändern.

https://www.agner.org/optimize/blog/read.php?i=49#49
https://discourse.julialang.org/t/openblas-is-faster-than-intel-mkl-on-amd-hardware-ryzen/8033
https://www.reddit.com/r/Amd/comments/9rx0rj/is_amd_working_on_an_alternative_to_intel_mkl_or/

Das ist alles 2009 bekannt und nicht auf einer "verstaubten" Forenseite sondern tatsächlich auf Mailinglisten die Leute nutzen die den ganzen Komplex verstehen und entsprechende Software entwickeln. In Usergroups zu numpy, BLAS, Atlas, Julia und R findet sich zum Komplex auch genügend.
Das sich jetzt ein paar deutsche Endkunden auf einer Consumer / Gaming fokusierten aufregen ist dahingegen wirklich unerheblich.

Wer will kann sich ja auch mal bei AMD beschweren, AMD hat ihre Softwareunterstützung massiv zurückgefahren. Ihre eigene Mathebibliotheken wurden 2014 eingestellt https://en.wikipedia.org/wiki/AMD_Core_Math_Library

 

[Hallo32]

Wer will kann sich ja auch mal bei AMD beschweren, AMD hat ihre Softwareunterstützung massiv zurückgefahren. Ihre eigene Mathebibliotheken wurden 2014 eingestellt https://en.wikipedia.org/wiki/AMD_Core_Math_Library

Dafür gibt es aktuell:
AMD AOCL https://developer.amd.com/amd-aocl/

Ist aber closed Source wie MKL.

 

[Piktogramm]

unterstellst du?

Nein, Unterstellungen lesen sich anders als allgemeine Anforderung ans Testing von Software. Testing macht man ja nicht, weil man weiß das etwas Fehler produziert sondern weil man herausbekommen will OB etwas nicht so funktioniert wie vorgesehen. Für Software die im wissenschaftlichem Rechnen eingesetzt wird, kann man als Anbieter sich nicht erlauben einen Fix aus dem "Netz" einzuspielen und nicht das komplette Testprogramm durchzuspielen. Was zwangsweise für jede neue Version von Matlab UND der MKL gemacht werden muss. Das bedeutet einen enormen Aufwand.

Und ganz nebenbei, bei der Menge an dokumentierten Bugs die heutige Prozessoren haben, kann man sicher sein, dass bei komplexer, hoch optimierter Software irgend ein Fehler auftaucht. Bei AMD wäre da das Problem mit RDrand welches erst für Zen aufwärts mit recht neuen µCodeupdates überhaupt gefixt wurde. Wenn die MKL RDrand nutzt und auf AM CPUs läuft wo die entsprechenden Updates nicht vorhanden sind wäre das bereits problematisch.

 

[Ned Flanders]

@Piktogramm

Die aktuelle numerische lib von AMD ist die AOCL.

Und was hat rdrand mit AVX2 zu tun?

 

[Piktogramm]

Dafür gibt es aktuell:
AMD AOCL https://developer.amd.com/amd-aocl/

Ist aber closed Source wie MKL.

Genaugenommen ist die Entsprechung eher BLIS ( https://en.wikipedia.org/wiki/BLIS_(software) ) welches Bestandteil der aocl ist, wobei BLIS auch erst seit 2016 verfügbar ist. Wobei selbst bei den Benchmarks des Projektes herauskommt, dass die MKL (wenn sie Intel vendor erkennt..) schneller ist als BLIS: https://github.com/flame/blis/blob/master/docs/Performance.md

AMD hat was Software Support echt das Problem, dass sie ihre Projekte teils verrotten ließen und die Nachfolger alle erst vergleichsweise kurz am Markt sind (und aus eigener Erfahrung, einigen merkt man an, dass sie noch nicht ausreichend abgehangen sind).

 

[calluna]

@SV3N

Eine kurze Suche bei Google ergab, dass selbst im Matlab Forum ein User schon vor Jahren schon auf diesen Flag hingewiesen hat.

Ups... wie peinlich für mich... das war Ned, der es dort gepostet hat.

 

[Piktogramm]

@Piktogramm
Und was hat rdrand mit AVX2 zu tun?

Nix, aber dein Fix aktiviert soweit ich das sehe nicht explizit AVX2 sondern generell neuer CPU Generationen. Was bedeutet, dass Codepfade die Haswell oder neuer unterstützen durchaus:
BMI 1/2, RDrand und AVX2 Befehle enthalten können. Das können AMD CPUs ab Zen zwar auch, wobei RDrand bei AMDs Jaguar und Zen als teilweise defekt bekannt sind. Was man also nicht will ist Software die RDrand nutzen könnte [1] auf Systemen läuft, wo eben diese Befehle zu Fehlern führen.

Als Softwareanbieter müsste man also sicher Stellen, dass man diese potentielle Fehlerquelle nicht berührt oder aber in kritischen Fällen abfängt. Das ist jedoch alles weit komplexer als das Setzen von 1-2 Parametern wie in deinem Fix.

Und RDrand habe ich mir herausgesucht, weil das Erzeugen von gutem Zufall in hoher Geschwindigkeit durchaus ein Fall ist, der in der Mathematik gewünscht ist. Wobei das Erzeugen eines Seeds für den Pseudozufallsgenerator über RDrand schneller gehen dürfte als das Nutzen eines Seeds aus der Entropiequelle des Betriebssystems.

[1] Konjunktiv!

Edit:
@Ned Flanders
https://www.reddit.com/r/matlab/comments/dxn38s/howto_force_matlab_to_use_a_fast_codepath_on_amd/

Ich Zitiere dich:

Disclaimer: I OF COURSE CANNOT AND DO NOT TAKE RESPONSIBILITIES FOR ISSUES RESULTING FROM USING THIS TWEAK.

Du scheinst dir ja auch bewusst zu sein, dass deine Lösung nicht zwingend wasserdicht ist.

 

[Ned Flanders]

Nix, aber dein Fix aktiviert soweit ich das sehe nicht explizit AVX2 sondern generell neuer CPU Generationen.

Nein. MKL_DEBUG_CPU_TYPE =5 setzt den AVX2 Codepath. 4=AVX; 7=AVX512

Ich Zitiere dich

Das Ding ist... Du weisst sehr genau, warum ich das da reingeschrieben habe. Genauso wie ich genau weiss warum Du Dir so eine Mühe hier damit gibst einen diskriminierenden Dispatcher als etwas normales und natürliches dastehen zu lassen.

Dabei wissen wir beide das es Intel mit nichten darum geht den armen non-Intel User vor Problemen zu bewahren.

Also lassen wir es an dieser Stelle gut sein, oder willst du das weiter ausdiskutieren?

 

[max9123]

Der Punkt ist, und das wurde hier auch schon angesprochen, dass jeder die MKL auf eigene Gefahr außerhalb der Spezifikation verwendet - ubd das sollte man auf Arbeit nicht tun, wenn es sich nicht um unkritische Berechnungen handelt.

Wenn es sich um kritische Berechnungen handelt ziemlich sicher nicht. Selbstverständlich auch mit keinem System welches nicht einmal ECC- Speicher unterstützt.
Selbstverständlich ist auch jeder numerische Code möglichst genau zu prüfen. Es in der Regel zig Varianten ein numerisches Problem zu lösen, mit ihren jeweiligen Auswirkungen.
Natürlich wären da auch noch diverse Fehler die in jedem Prozessor vorkommen.

Es gibt auch einen kleinen Bereich dazwischen (mindestens alles wo nicht einmal ECC-Speicher zum Einsatz kommt) wo ein vergleichsweise einfacher Test durchaus ausreichend sein kann.

 

[Jesterfox]

Dazu müsste man nachweisen, dass Intels Software auf nicht Intel CPUs sinnlose Loops / Sprünge einbaut.

Es wird aber sinnloserweise die schnelle AVX2 Ausführungseinheit brach liegen gelassen wegen einer explizit eingeführten Abfrage die auf den Hersteller anstatt das Featureset prüft!

 

[Piktogramm]

@Ned Flanders
Mal abgesehen davon, dass diese Umgebungsvariable nicht offiziell dokumentiert ist. Die MKL selbst prüft auf CPU Familien z.B. prüft die Funktion mkl_vml_serv_CPUisHSW ob die CPU zur Haswell Familie gehört. Was die Umgebungsvariable zu tun scheint, ist diese Prüfung auf CPU Familien zu überschreiben. Was im Falle von "gehört zur Haswell" b.z.w. MKL_DEBUG_CPU_TYPE =5 bedeutet, dass AVX2 genutzt wird, weil Haswell nunmal AVX2 kann. Was es aber nicht bedeutet, ist dass in diesem Modus nicht auch alle andere Befehle genutzt werden, die Intel CPUs ab Haswell verstehen. Worunter auch RDrand fallen würde (wurde eingeführt mit IvyBridge).

Ergänzung (19. November 2019)

Es wird aber sinnloserweise die schnelle AVX2 Ausführungseinheit brach liegen gelassen wegen einer explizit eingeführten Abfrage die auf den Hersteller anstatt das Featureset prüft!

Ist nicht sinnlos. Die MKL prüft auf knapp 10 verschiedene Featurelevels[1] von Intel CPUs. Für jedes Level benötigt es eigene Codepfade. Würde man das an Featuresets festmachen und Codepfade für jede der Möglichkeiten an Features vorsehen, müsste man wahrscheinlich einige 100 Codepfade ausliefern. Dieser Mehraufwand ist aber nicht zu rechtfertigen, wenn es der eigenen Firma nicht nutzt sondern nur der Konkurrenz.

Wer was anderes will sollte anfangen Linux / BSD, GCC / Clang, BLAS zu nutzen. Das man statt Matlab nur R/Julia nutzt ist dann aber wohl auch klar.

 

[DEFCON2]

Herzlichen Glückwunsch @Ned Flanders dass du das zur Sprache gebracht hast. Eigentlich meide ich dich nach unserem Zank in der Vergangenheit, aber das ist ein sehr schöner Beitrag, der Applaus verdient. Als ich 2017 umgerüstet habe scheint es ACOL noch nicht gegeben zu haben. Damals bin ich nur auf alte Bibliotheken für Opertons gestoßen und eben OpenBlas. Sehr gut dass AMD da aufholt - wäre super interessant z.B. NumPy benchmarks mit ACOL bzw der MKL zu machen auf den CPUs der jeweiligen Hersteller. Für so Kommerz wie MATLAB ist jedoch vermutlich eh nicht damit zu rechnen, dass sie ACOL nehmen.

 

[wikinger1]

Nvidia mit PhysX was auf CPU´s grundsätzlich nur einen Kern nutzen tut.

Nvidia PhysX schön wäre es, wenn es weit mehr games geben würde und bitte wer nutzt AMD oder Intel cpu dafür? das soll nur auf NV Grakas berechnet werden können zudem sind sie doch genacht sei es die cuda core etc. ICH forcire sehr viel vom NV treiber aus und NvPhysX ist eins davon was ich nach dem treiber istallieren umstelle und auch denn rest unter 3D settings max Qualy AA AF wenn es sein muss alles auf 128x wenn es noch möglich wäre. Denn vor 10Jahren oder sogar weniger gab es das noch. Damals hatten wir die "Power" nicht gehabt dafür und heute haben wir die "Power" dafür aber die filter gibt es nicht mehr zumindest nicht mehr offiziell. tja.

 

[Ned Flanders]

@DEFCON2

Ganz Herzlichen Dank! Und sorry das ich dir da offensichtlich irgendwann mal zu nahe getreten bin.

Ich hoffe einfach, dass ein paar Entwickler mal ob der Problematik (die ja lange bekannt aber irgendwie nie auf die Tagesordnung kam) aufwachen und sich etwas hin zu einem offeneren Angebot entwickelt, in dem der User wirklich eine freie Wahl der Hardware hat. Das war zumindest der Antrieb.

Mein Favorit wäre immernoch das die Anbieter dem User eine echte Wahl der Lib ermöglichen, so wie beispielsweise Octave.

 

[pascaljackson]

Habe zwar 2 CAD-Lizenzen, aber nur Intel-Rechner und Laptops im Haus (Alter Xeon und n 6700HK im Laptop)



Müsste man alles mal Testen, leider ist mir das jedoch nicht möglich.

Habe Zugriff auf Catia, NX und Solidworks durch die Uni. Wenn du mir sagst wie ich da was mit meinem 1800x testen soll, könnt ichs machen bei Gelegenheit.

 

[D2490nm4573r]

Im Zweiten Absatz von 2.3 steht dafür aber genauso klar, dass eben dieser Punkt NICHT dazu führen darf, dass Intel gezwungen wird ihre Produkte für ihre Wettbewerber optimieren muss.

Das verwenden eines bereits vorhandenen Code-paths für AVX2 hat nichts aber auch wirklich gar nichts mit optimieren zu tun weshalb der benannte abschnitt hier keinerlei Relevanz hat.

Code Optimieren heist Operationen aus einem Befehlssatz (nicht die Verwendung oder eben nicht Verwendung eines kompletten Befehlssatzes bevor du das wieder absichtlich missverstehst) zu verwenden die auf dem Prozessor besonders effizient laufen, die Code-Abschnitte so zu optimieren das sie komplett in den level 1 Cache geladen werden können , auf anderweitige Eigenheiten eines speziellen Prozessormodells im Code gezielt einzugehen usw.