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

[HaZweiOh]

Stichwort Wettbewerbsrecht, mal ein Beispiel, dass wir nicht im wilden Westen sind: Heute wurden europaweit Standorte von Mondelez durchsucht, Büros versiegelt. Falls die Siegel gebrochen werden, wurden Millionenstrafen angedroht.

Einige aus diesem Thread würden jetzt kommen mit: "Häh, wieso, versteh ich nicht. Illegale Preisabsprachen? Ist doch ihre Sache! Die faule Konkurrenz soll mal nicht so rumheulen, sie können sich doch am Kartell beteiligen! Das nennt man freie Marktwirtschaft!"

 

[Piktogramm]

Schlechtes Beispiel. RDRAND ist eine Instruktion, die Anwendungen als Zufallsquelle tunlichst vermeiden sollten. Der Linux-Kernel etwa traut dieser Funktion standardmäßig nicht, kryptographisch sicheren Zufall zu erzeugen. Ordentlich programmierte Anwendungen nutzen daher die Funktionen des Betriebssystems, mit wenigen Ausnahmen bei denen ein besonderer dafür Grund vorhanden ist (z.B. systemd).

Die RDRAND-Probleme hat AMD übrigens mit BIOS-Updates behoben. Es ist wie bereits gesagt auch nicht Intels Aufgabe, auf AMD-Systemen zu testen. Wenn da irgendwo ein Bug sein sollte ist das an AMD, dort Abhilfe zu schaffen.
Wenn wir schonmal beim Whataboutismus sind: https://www.golem.de/news/skylake-u...r-alptraum-bug-in-intel-cpus-1706-128582.html

Wie du schon schreibst, man sollte wissen was man tut, wenn man RDrand nutzt. Wenn man für nicht kryptografische Zwecke schnell gute Entropie ist RDrand rein zufällig genau der Befehl dazu.
AMD hat die Problematik zwar mit einem µCode Update behoben, das aber auch nur für Zen. Als Software Anbieter kann man sich da aber nicht drauf verlassen.
Für mehr Zufall kann man in Linux den Hardware Random Generator nach Belieben einbinden. Als auf meinem Jaguar RDrand weggepatcht wurde, war das nicht so lustig..

Ansonsten ist ein Beispiel um aufzuzeigen, dass die Übertragung von hoch optimiertem Code auf andere Plattformen nicht zwingend funktionieren muss und das anhand eines Befehls der vor kurzem Medial die Runde gemacht hat.

Also das FZ Jülich, die mit dem neuen EPYC HPC, haben das wohl getestet und für gut befunden.

Ich empfinde das aber nach wie vor für wenig überraschend, denn schlüssig erklärt warum x86-64 AVX2 Code auf Intel laufen, auf AMD aber nicht hast du noch immer nicht erklärt.

Im Wissenschaftlichem Rechnen hat man meist den Quellcode und kann den genutzten Compilern ein march=native mitgeben. An kritischen Stellen schreibt man da gegebenenfalls etwas Inlineassembler und testet dann alles durch bevor man es auf dem großem System laufen lässt.
Eben jenes Compilat welches auf die Architektur des Großrechners zugeschnitten wurde, willst du nicht auf einem "vergleichbarem" Intel laufen lassen. Da hat man auch hohe Chancen, dass man da doch 1-2 kritische Differenzen findet.
Insofern, dein Beispiel ist unwissentlich genau der Problemfall den ich beschreibe

Wow, mit der Begründung kann Intel also komplett den Dienst auf einer AMD-CPU verweigern. Schließlich kann sich Intel nie 100%ig sicher sein, ob nicht auch die ALU/AGU-Implementierungen oder MOV bei AMD "richtig" implementiert sind. Wenn AMD sagt, sie unterstützen einen Befehl, dann ist das so. Falls AMD dann Probleme bei der Implementierung fest stellt, ist das ihr Problem.

Genau deswegen hat sich ja eingebürgert, dass die Hersteller von Prozessoren ihre eigenen Compiler pflegen und die Compiler Dritter um Patches/fixes für ihre eigenen CPUs erweitern. Egal ob Visual C-Compiler, llvm, gcc, diese Compiler enthalten Optimierungen von Intel für Intel und genauso Patches von AMD für AMD. Was auch Mitigations für CPU Bugs umfasst.
Der AMD Compiler enthält deswegen auch genauso wenig Profile für Intel CPUs wie der ICC für AMD CPUs...

es auch bei Intel CPUs große Variationen beim Feature Set gibt, müssen sie eine solche Anfrage eh durchführen.

Wieso denn? Intel weiß sehr genau was ihre CPUs können und die compiler flags gehen sowieso nach der CPU Generation..

@HaZweiOh

Annahme: Intel blockt AMD bei MKL komplett.

Was ist die Alternative für AMD?
OpenBLAS oder BLIS oder ...?
Sind die Libs für die unterstützten Betriebssysteme durch Matlab verfügbar? Falls crosscompile, welche Auswirkung hat es auf die Performance?
Wie sieht die Performance der Libs aus?

Egal welche Mathebibliothek, der Mathekernel der MKL ist in oftmals überlegen. Nach den Messungen vom BLIS Projekt selbst , ist die MKL selbst auf ARM CPUs mitunter deutlich fixer als Blis. Die große Ausnahme ist Blis auf Epyc, da ist die MKL aus bekannten Gründen recht lahm. Das dürfte aber auch anders aussehen, wenn man die Nutzung neuerer Befehlserweiterungen erzwingt.
https://github.com/flame/blis/blob/master/docs/Performance.md

Leider ist juristischer Sachverstand im Technik-Bereich wohl ziemlich schwach ausgeprägt. Selbst in einem alten c't-Artikel kam der Autor mit der fixen Idee um die Ecke, dass Intel kein Monopol bei Compilern hätte.

Stimmt auch, Intel hat kein Monopol aus Compiler. Für Intel CPUs liefert der ICC meist trotzdem den schnellsten Code. Wobei in vielen Fällen der GCC, Visual C Compiler, llvm in Schlagweite sind.

Es ist ja generell ironisch eine Vendor Abfrage zu machen, obwohl man dann eine Feature Abfrage macht.... man weiß schon was man da tut, vor allem in Hinblick darauf, dass man Tech-Magazine darauf hinweist doch bitte diese Software für Benchmarks zu benutzen.

Wo hast die die Featureabfrage her?
Die einzige Funktion die in der MKL enthalten ist und Featureabfragen macht dient dazu AVX Featurelevel zu unterscheiden. Hauptsächlich weil es verschiedene Featurelevel für AVX512 gibt. Der Rest ist ne Abfrage auf die CPU Generation.

 

[calluna]

[x] Du vergleichst Äpfel mit Birnen

;-)

 

[HaZweiOh]

Nö, das passt schon. Das Beispiel war für die Fraktion, die meint, in einer Marktwirtschaft dürfe jeder zu allen Mitteln greifen.

 

[Atent123]

Wieso denn? Intel weiß sehr genau was ihre CPUs können und die compiler flags gehen sowieso nach der CPU Generation..

Du vergisst engineering Samples.
Unis bekommen meist CPUs mit reduziertem Feature Set.
Wenn der Skylake-X dann plötzlich gar kein AVX512 kann, wird es problematisch.

 

[Hayda Ministral]

Er scheint ja wohl zumindest nicht allgemein bekannt gewesen zu sein.

Relevanz? Die Allgemeinheit erstellt eher selten CPU-lastige Programme bei denen die Codepfade relevanz haben. Entscheidend ist doch, ob diejenigen die sich mit der Materie länger als ein paar Minuten brauchen um die passende Information/Anleitung zu finden. Wer kann aus der Praxis berichten?

 

[Piktogramm]

Du vergisst engineering Samples.
Unis bekommen meist CPUs mit reduziertem Feature Set.
Wenn der Skylake-X dann plötzlich gar kein AVX512 kann, wird es problematisch.

Engeneering Samples sind für Tests und Qualifikation da und sollten nicht im Produktivbetrieb landen. Bei der Auslegung von Produktivsoftware sind die damit schlicht egal. Gerade wenn sich die ersten verfügbaren Samples nicht an ihre Spec halten sollten.

Und das Unis großartig CPUs mit reduziertem Featureset bekommen ist mir komplett neu. Selbst wenn sowas in Unis landet. Es gibt ja genau deswegen bei der MKL dokumentierte Paramater, die Featuredowngrades zulassen.

 

[Hayda Ministral]

Ich empfinde das aber nach wie vor für wenig überraschend, denn schlüssig erklärt warum x86-64 AVX2 Code auf Intel laufen, auf AMD aber nicht hast du noch immer nicht erklärt.

@Piktogramm hat aus meiner Sicht schlüssig erklärt dass "läuft nachgewiesenermaßen zuverlässig auf Intel" nicht automatisch und vor allem nicht ohne weitere Mannpower bedeutet "läuft nachgewiesenermaßen zuverlässig auf AMD".

 

[Piktogramm]

Auf jeden Fall danke an Alle, das Ganze ist interessant genug, dass ich es mir nochmal genauer angeschaut habe.

Funktionen der Intel libmkl_core.so der Version 2019.4.243-1

0000000000209140 T mkl_serv_cpuisatomsse4_2
0000000000209230 T mkl_serv_cpuisatomssse3
0000000000209050 T mkl_serv_cpuisbulldozer
0000000000209490 T mkl_serv_cpuisclx
00000000002092b0 T mkl_serv_cpuisitbarcelona
0000000000209420 T mkl_serv_cpuisknm
00000000002093a0 T mkl_serv_cpuisskl
0000000000209020 T mkl_serv_cpuhasnhm
0000000000209600 T mkl_serv_cpuhaspnr
0000000000209630 T mkl_serv_cpuhaspnr_true

Laut Funktionsnamen, erkennt das Ding wirklich nur die CPU Familie aber nicht direkt die Featurelevel.
Genau genommen gibt es mkl_serv_ mit cpuis/cpuhas über verschiedene Objectfiles hinweg:

$ nm -gC libmkl_*.so | grep cpuhas                                               
0000000000209020 T mkl_serv_cpuhasnhm
0000000000209600 T mkl_serv_cpuhaspnr
0000000000209630 T mkl_serv_cpuhaspnr_true
                 U mkl_serv_cpuhaspnr
                 U mkl_serv_cpuhaspnr
                 U mkl_serv_cpuhaspnr
                 U mkl_serv_cpuhaspnr

nm -gC libmkl_*.so | grep cpuis
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisclx
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisbulldozer
0000000000209140 T mkl_serv_cpuisatomsse4_2
0000000000209230 T mkl_serv_cpuisatomssse3
0000000000209050 T mkl_serv_cpuisbulldozer
0000000000209490 T mkl_serv_cpuisclx
00000000002092b0 T mkl_serv_cpuisitbarcelona
0000000000209420 T mkl_serv_cpuisknm
00000000002093a0 T mkl_serv_cpuisskl
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisitbarcelona
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisitbarcelona
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisitbarcelona
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisitbarcelona
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisknm

Eine Prüfung auf Haswell (HSW?) habe ich nicht gefunden, nm -gC libmkl_*.so | grep hsw gibt nichts zurück.

Weiter ins Detail gehe ich nicht, habe kein Bock für euch §69e vom Urhebergesetz zu testen

 

[Hallo32]

Die Version in Matlab kommt aus 2018.

 

[Ned Flanders]

Was bemerkenswert ist, in anbetracht der Tatsache, dass das ändern eines einzelnen Bytes in "GenuineIntel" bereits dazu führt das ein Fall Back auf SSE stattfindet.

Warum wird da auf e.g. Bulldozer getestet?

 

[chithanh]

AMD hat die Problematik zwar mit einem µCode Update behoben, das aber auch nur für Zen. Als Software Anbieter kann man sich da aber nicht drauf verlassen.

Alles falsch.
Den Fix zum BIOS-Problem welches bei Jaguar RDRAND kaputt gemacht hat, hat AMD auch den OEM-Herstellern zur Verfügung gestellt. Aber angesichts der Tatsache, dass es für so alte Hardware selten noch BIOS-Updates gibt, hat man sich entschieden, das entsprechende CPU-Flag im Betriebssystem zu maskieren.

Als Softwareanbieter kann man sich also weiterhin darauf verlassen, dass die Flags tatsächlich funktionierende Features anzeigen. Wenn nicht ist es ein Bug und der Hersteller muss handeln.

Hätte Intel in der MKL nicht nach GenuineIntel-CPUID, sondern nach AVX2 Flag den Codepfad umgestellt, und wegen irgendeines AMD-Bugs liefe das nicht korrekt, dann würde nur AMD in der Kritik stehen und nicht Intel.

 

[blöderidiot]

Die Version in Matlab kommt aus 2018.

Woher weißt Du das und welches MatLab meinst Du? Die MKL in Matlab R2019B hat gar keine Signatur, soweit ich das hier sehe:

mkl.dll:
Verified: Unsigned
Link date: 1:44 2019-07-19
Publisher: n/a
Company: n/a
Description: n/a
Product: n/a
Prod version: n/a
File version: n/a
MachineType: 64-bit

 

[Hallo32]

@Ned Flanders
Matlab verwendet eine ältere Version, wodurch Abweichungen entstehen.

Ergänzung (20. November 2019)

Woher weißt Du das und welches MatLab meinst Du? Die MKL in Matlab R2019B hat gar keine Signatur, soweit ich das hier sehe:

Matlab 2019b Update 1

>> version -blas

ans =

    'Intel(R) Math Kernel Library Version 2018.0.3 Product Build 20180406 for Intel(R) 64 architecture applications, CNR branch AVX2
     '

 

[Piktogramm]

Die Version in Matlab kommt aus 2018.

Ganz ehrlich, trotz Smiley, Krümelkacker

@Ned Flanders
Da müsstest selbst ein Disassembler drauf werfen und nachschauen.

@chithanh
Ändert nicht viel daran, dass RDrand über Jahre defekt war und mittlerweile einfach abgeklemmt wurde. So oder so, Programme die RDrand auf einer solchen Plattform benutzen würden, haben die Chance auf Probleme.

 

[Ctrl]

ja was solls.. hat AMD eine eigene Math Kernel Library entwickelt .. oh nö.. 🖕

 

[Hallo32]

Ganz ehrlich, trotz Smiley, Krümelkacker

Wie sicher bist du dir, dass die beiden Versionen sich in den Punkt hinreichend ähnlich sind? 🧐

 

[blöderidiot]

 >> version -blas

bei mir:

ans =
'Intel(R) Math Kernel Library Version 2019.0.5 Product Build 20190808 for Intel(R) 64 architecture applications, CNR branch auto
Linear Algebra PACKage Version 3.7.0

... nachdem ich händisch die aktuelle MKL installiert und sie MatLab mit diesem .cmd untergeschoben habe:

call "D:\usr\compilers_and_libraries_2019.5.281\windows\mkl\bin\mklvars.bat" intel64 && set BLAS_VERSION=mkl_rt.dll && set LAPACK_VERSION=mkl_rt.dll && set MKL_DEBUG_CPU_TYPE=5
matlab.exe

 

[Piktogramm]

Wie sicher bist du dir, dass die beiden Versionen sich in den Punkt hinreichend ähnlich sind? 🧐

Mir ist es ausreichend egal!
Zudem, wer ausreichend Lust und Laune hat, ich habe dokumentiert wie man Symbolnamen aus ObjektFiles herausbekommt. Weniger Spekulieren, einfach selber nachschauen und so Aussagen auf Wissen basieren lassen (aber Vorsicht, macht man das hier wird man ganz schnell als Troll abgestempelt ).

Aber mal realistisch betrachtet: Die MKL ist ein Monster, die wesentliche Struktur zum Selektieren der Codepfade wird da nicht einfach mal umgeschrieben. Es würde mich sehr wundern, wenn das mittlerweile alles komplett anders ausschaut. Die größten Differenzen wird es evtl. dadurch geben, dass es bei mir die Bibliotheken für Linux sind und bei den meisten Anderen für Microsoft Windows. (BTW, wenn Windowsnutzer über böse Monopolisten und closed source heulen ist das immer witzig..)

 

[Hallo32]

Wie verhält sich die Version ohne MKL_DEBUG_CPU_TYPE=5 auf AMD Systemen?