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

[Tzk]

So gibt es CPU-Einordnungsfunktionen für

• Zen (Funktion mkl_serv_cpuiszen)

Da frag ich mich jetzt nun warum trotzdem kein AVX2 mit Zen genutzt wird, man aber trotzdem explizit auf "Zen" abfragt. WTF?

 

[Taxxor]

Wie kann Intel kontrollieren, ob die AMD-Implementation der jeweiligen AVX-Stufen korrekt ist? Was ist, wenn MKL auf AMD-CPUs gelegentlich falsche Ergebnisse liefert? Dann ist Intel schuld, nicht wahr?

Das muss Intel gar nicht kontrollieren, weil es ein klar definierter Standard ist, Intel muss einfach nur abfragen ob dieser Standard von der jeweiligen CPU unterstützt wird, egal von welchem Hersteller die CPU ist.

Sollten AMD CPUs dann falsche Ergebnisse liefern, liegt die Schuld bei AMD, da sie dann offenslichtlich irgendwas in ihrer AVX Implementierung drin haben, was nicht dem Standard entspricht.

 

[Ned Flanders]

Wie kann Intel kontrollieren, ob die AMD-Implementation der jeweiligen AVX-Stufen korrekt ist?

Das ist AMDs job und darum braucht sich Intel keinerlei Sorgen zu machen. Im Gegenteil, wenn rauskommt das AMD CPUs mit AVX2 Code falsch rechnen dürfte AMD von heute auf Morgen mit dem Rücken zur Wand stehen.

 

[DocWindows]

man aber trotzdem explizit auf "Zen" abfragt.

Die Abfrage der AVX2-Fähigkeit findet an einer anderen Stelle statt. Das hat nichts mit der Einordnung der CPU zu tun. Ohne einen Debugger zu benutzen kann ich aber nicht weiter nachschauen was genau da wann passiert. Dazu ist der Code ein wenig zu komplex

Das muss Intel gar nicht kontrollieren, weil es ein klar definierter Standard ist, Intel muss einfach nur abfragen ob dieser Standard von der jeweiligen CPU unterstützt wird, egal von welchem Hersteller die CPU ist.

Intel fragt mit dem cpuid-Befehl den Funktionsblock 7 der CPU ab. Und bei beiden Herstellern ist das AVX2-Bit an der gleichen Stelle. Entweder ist es ein Bug im Code oder die Vendor-ID Abfrage verhindert dass bei Nicht-Intel-CPUs überhaupt keine Abfrage der erweiterten Funktionen der CPU stattfindet. Beides ist möglich.
Ich habe eine Weiche zur Vendor-ID gefunden, aber ich kann nicht sagen ob sie greift oder wann sie greift.

Man kann sich aber denken was zutrifft, wenn man bedenkt dass CPU-Z und Knosorten nichts anderes machen als ebenfalls diesen Block abzufragen. Wenn die AVX2 auf Enabled setzen, dann ist es auch für MKL enabled. Also würde es bedeuten Intel führt die Abfrage der erweiterten Funktionen auf Nicht-Intel-CPUs nicht aus. Ich kann es aber nicht verifizieren. Onwohl ... Es gab doch da diesen Democode irgendwo

 

[Taxxor]

@DocWindows Die Frage ist ja wozu man überhaupt die Vendor-ID abfragen muss, wenn auch einfach direkt geschaut werden kann, welche Features unterstützt werden.
Darauf gibt es mMn nur eine Antwort.

 

[Tzk]

@Taxxor
Naja, wenn man über die Instructionsets hinaus noch weitere Optimierungen einfließen lassen möchte, dann ist das schon sinnvoll. Trotzdem sollte man aber als Fallback immer das maximal mögliche unterstützen. Sprich Cpu kann AVX2 -> AVX2 wird genutzt.

Das Intel nicht AMD spezifisch optimiert sollte klar sein, aber zumindest das korrekte/schnellste Instructionset sollte genutzt werden.

 

[DocWindows]

@Taxxor Wie gesagt: Man könnte es leicht beweisen indem man mit einem Hexeditor das G von GenuineIntel in ein F umbiegt. Damit werden alle Intel-CPUs zu unbekannten (unoptimierten) CPUs im programmatischen Sinne und müssten entsprechend in der Leistung einbrechen. WENN die VendorID Abfrage diesen Zweck hat.

Ich fnide aber keinen Code mit dem man man eben einen Quick and Dirty Test machen kann. UNd reinarbeiten will ich mich jetzt auch nicht. Keine Zeit.

 

[Ned Flanders]

Diesen umgeht man übrigens am Besten mit der Environment-Variable MKL_ENABLE_INSTRUCTIONS, die man auf AVX2 setzt.
Damit wird der CPU-Typ ebenfalls auf 5 statt 4 gesetzt. Jede Erweiterungs-DLL bietet eine Funktion "dll_cpu_version". Der Rückgabewert wird bei AVX fix auf 4 gesetzt, bei AVX2 auf 5. Anhand dieses Werts lädt der Core die DLL oder eben auch nicht. Darum funktioniert der Wert 5 den man über die Env-Variable setzt.

Würde man beispielsweise den CPU-Typ auf 7 setzen, wäre das Äquivalent zu AVX512.

Leider habe ich weder Matlab noch Kenntnis darüber wie man die MKL benutzt.
Wenn man die Bytes des Vendor Strings ein wenig ändert, z.B. in FenuineIntel () dann sollten weder Intel noch AMD Prozessoren AVX(2) nutzen können und gleich langsam sein.

Merci für den Input! Enable Instructions werde ich heute abend mal ausprobieren. Ich hab gehört, dass das aber nur auf Intel CPUs funktionieren soll, weil es ansonsten durch die Vendor String Abfrage überschrieben wird.

Wenn Du spass drann hast, Matlab ist 30 Tage kostenlos testbar. Im Reddit Artikel ist ein Matlab Script zum Benchmarken verlinkt. Matlab hat auch einen internen Benchmark der auch deutlich darauf anspricht.

Man kann in Matlab auch den verwendeten Codepath abfragen, mit "version -blas"

Auf meinem Zen resultiert das in:

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

Auf einem aktuellen Intel Sys resultiert das in:

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

Gruss,

Ned

 

[Taxxor]

@Tzk Schon, dann kann die Vendor-ID Abfrage aber auch an einer anderen Stelle kommen, wo es um entsprechende Optimierungen geht, und muss nicht vor der Abfrage des Featuresets sitzen.

 

[Tzk]

@Taxxor
Kurz und knapp: Jop

 

[pipip]

Intel macht sich doch nur Sorgen um ihre Kunden. Stellt euch vor, so ein Programm würde von einer CPU gestartet die Security Probleme hat. Mit der Abfrage wird sichergestellt, dass man die volle Sicherheit und Support hat die sonst keiner liefern kann


Finde interessant, dass man Leute von Mathlab jetzt den Schwarzen Peter zuschieben. Die nützten ja eine Bibliothek um sich nicht mehr Gedanken machen zu müssen, ob die aktuellsten Feature-Set abgefragt werden. Glaube kaum dass sie die Bibliothek debugged haben um zu kontrollieren, ob diese Lib funktioniert.
Eigentlich zeigt das, wie wichtig es ist heutzutage wenn möglich offene Bibliotheken zu verwenden.

@Ned Flanders
Seit welcher Version existiert diese Abfrage?

 

[Ripcord]

Intel macht sich doch nur Sorgen um ihre Kunden. Stellt euch vor, so ein Programm würde von einer CPU gestartet die Security Probleme hat. Mit der Abfrage wird sichergestellt, dass man die volle Sicherheit und Support hat die sonst keiner liefern kann

Sorgen um die Kunden und Sicherheit die kein anderer liefern kann in einem Satz mit Intel?

YMMD

 

[Ron Reviewt]

Bin gespannt wann die Codezeile gefunden wird, welche die künstliche Raytracing Schranke von Nvidia aushebelt.

Ansonsten super gemacht und melde dich bei Amd. Da wird eine Provision für dich fällig 👏

 

[blöderidiot]

Würde man beispielsweise den CPU-Typ auf 7 setzen, wäre das Äquivalent zu AVX512.

AMD hat imho kein AVX_512.

Weiterhin ist es so, dass erst Zen2 AVX2_256 in 256bit unterstützt. Das ist also sehr neu im Mainstream. Bis dahin hat AMD AVX und AVX2 nur in 128bit-Registern unterstützt und erforderte einen eigenen Codepath, um mit den 128bit-Instruktionen vernünftige Performance herauszuholen.
https://www.agner.org/optimize/blog/read.php?i=838
"AMD has four 128-bit units for floating point and vector operations. Two of these can do addition and two can do multiplication. Intel has two 256-bit units, both of which can do addition as well as multiplication. This means that floating point code with scalars or vectors of up to 128 bits will execute on the AMD processor at a maximum rate of four instructions per clock (two additions and two multiplications), while the Intel processor can do only two. With 256-bit vectors, AMD and Intel can both do two instructions per clock. Intel beats AMD on 256-bit fused multiply-and-add instructions, where AMD can do one while Intel can do two per clock. Intel is also better than AMD on 256-bit memory writes, where Intel has one 256-bit write port while the AMD processor has one 128-bit write port. "

Kaum jemand hatte sowas implementiert. Die einzige Software, die so etwas (imho seit 2016) geboten hat (von der ich das weiß), ist das Simulationsprogramm "GROMACS", bei denen findet sich ein vollständig durchgestylter AMD-128bit-AVX2-codepath (https://github.com/gromacs/gromacs/blob/master/src/gromacs/simd/support.cpp):

        { SimdType::X86_Avx128Fma, "AVX_128_FMA" },
        { SimdType::X86_Avx, "AVX_256" },
        { SimdType::X86_Avx2, "AVX2_256" },
        { SimdType::X86_Avx2_128, "AVX2_128" },

wobei kurz nach der Einführung von Zen1 bei GROMACS klar wurde, dass AVX2_256 darauf doch nicht so langsam ist, wie man glaubte: https://redmine.gromacs.org/issues/2328
Das paßt also auch sehr gut zu den Resultaten von @Ned Flanders . Nun wäre es an der Zeit, dass AMD und MathWorks kooperieren, um AMD-Prozessoren in MatLab aufzuwerten. Dass das weder MathWorks noch AMD bisher gemacht haben, kann man wohl schwerlich Intel ankreiden.

 

[DocWindows]

AMD hat imho kein AVX_512.

Darum geht es gar nicht, sondern um die Methode wie der MKL Code funktioniert. Und der unterstützt nunmal AVX512. Somit gilt: Wenn man CPU Typ 7 forciert, will MKL AVX512 instruktionen ausführen. Wenn die CPU das nicht kann (viele Intels können das auch nicht) crasht das Programm oder wird irre langsam.

 

[Benji18]

Ich frage mich, warum Intel das prüfen müsste, solange sie auf ihrer Seite (Software) alles korrekt und gleichberechtigt umsetzen.
Sollte die AVX Implementierung bei AMD nicht in Ordnung sein, dann hätte AMD den Bock geschossen. Während Intel berechtigterweise jegliche Schuld und Verantwortung von sich weisen könnte.

AVX ist wie SSE eine Befehlsatz erweiterung der x86 Architektur, diese wurde von Intel entwickelt und im zuge der Partnerschaft zwischen AMD und Intel zurverfügunggestellt umgekehrt hat Intel auch von der x64 Erweiterung (auch bekannt als AMD64) profitiert.

Daher ist davon auszugehen das AMD die Befehlsatzerweitung wie von Intel vorgesehen implementiert hat und somit sollte auch hier (vorrausgesetzt es gibt keinen HW Bug) beide CPUs zum selben Ergebnis kommen.

 

[pipip]

Benji18
if(Hochleistungshardware mit Hochfrequenzkerne){..AVX ==true...}, hust* @zeedy

DocWindows
Ich denke mal, der Grund für die Codezeile wird nur derjenige wissen, der sie eingebaut hat. Wie sie dahin gekommen ist, ist meiner Meinung völlig egal. Kann ja auch unbedacht gewesen sein (sogar von einer Einzelperson).
Wichtiger ist, dass es aufgefallen ist und eventuell auch wo anders passieren könnte und nachbessern. Und ja, AMD selbst sollte da was tun. Immerhin wollen sie ja dass ihre CPUs optimal laufen (Wobei das ziemlich dem Suchen einer Nadel im Heuhaufen entspricht). Natürlich sollte man aber auch nicht unterschätzen, was so Communities leisten können. Immerhin sind oft jene User meist eben technikaffine User.

 

[duskstalker]

Starcraft 2 war das prominenteste Spiel mit nachgewiesener Benachteiligung durch einen vendor id check.

Das geschummel mit den compilern und libraries ist so alt wie Intel selbst. Daher ist das hier wenig überraschend, aber gut, dass das wieder etwas medial beleuchtet wird.

 

[DocWindows]

Auf meinem Zen resultiert das in:

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

Auf einem aktuellen Intel Sys resultiert das in:

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

Eieieiei. Ich habe gerade mit Matlab und deinem Script getestet. Aber nur die 5000 weil ich heute auch noch andere Sachen zu tun hab

CPU ist Xeon E3-1226v3

Original MKL Code:
version: Intel(R) Math Kernel Library Version 2018.0.3 Product Build 20180406 for Intel(R) 64 architecture
applications, CNR branch AVX2

TIME IN SECONDS (SIZE: 5000):
SVD: 35.858645
Cholesky: 0.282643
QR: 1.408898
100 matrix products: 153.901173
Inverse: 2.125072
Pseudo-inverse: 46.703255

Gepatchter MKL Code (Fenuine statt Genuine, sonst nichts, also nur 1 Byte geändert):
version: Intel(R) Math Kernel Library Version 2018.0.3 Product Build 20180406 for Intel(R) 64 architecture
applications, CNR branch auto

TIME IN SECONDS (SIZE: 5000):
SVD: 37.629060
Cholesky: 1.096114
QR: 4.531531
100 matrix products: 615.803780
Inverse: 7.732193
Pseudo-inverse: 67.917214

 

[Ned Flanders]

Würde man beispielsweise den CPU-Typ auf 7 setzen, wäre das Äquivalent zu AVX512.

Hast Du eigentlich den Value für AVX zur Hand? (also AVX1)? Dann kann ich den Workaround auch noch spezifisch für Bulldozer Derivate ergänzen. Da gibts sicherlich auch noch ein paar glückliche Abnehmer für.

4?

Eieieiei. Ich habe gerade mit Matlab und deinem Script getestet. Aber nur die 5000 weil ich heute auch noch andere Sachen zu tun hab

Ok, das ist wohl ziemlich eindeutig. Danke fürs checken. Das überschreitet erheblich meine Fähigkeiten. Hatte es gestern kurz mit @Hallo32 davon. @pipin

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