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

[yummycandy]

Im Zusammenhang mit den weiter unten geposteten minimalen Systemanforderungen, wenn der x64 Support die Mindestvoraussetzung ist und SSE

Puh, ich kann mir nicht vorstellen, daß SSE ein Bestandteil von X86_64 ist. Aber zumindest widersprechen ihre eigenen Anforderungen der MKL.

 

[Alphanerd]

Und so hat Intel wie seit Jahren, einen Pfeil im Köcher.

Krumm. Ohne Federn und Spitze.

Aber immerhin einen Pfeil.

 

[Ned Flanders]

Endlich mal eine eindeutige Aussage!

Wenn man denen das per Support mitteilt, was ich natürlich ebenfalls getan hab nachdem ich den Workaround zum laufen bekommen habe, wundert man sich allerdings ernsthaft, wie das bei so großen Firmen eigentlich läuft. Die haben Augen bekommen, so gross wie Untertassen und sind sich bis dato offensichtlich der Problematik der MKL gar nicht bewusst gewesen.

Zumindest wirkt das in der Antwort so.

Aber: "Die Thematik wird intern bereits diskutiert und ich bespreche dies aktuell mit unserer Entwicklungsabteilung."

Man darf also gespannt sein.

 

[Wadenbeisser]

@yummycandy

Ich habe nochmal bei Wikipedia reingesehen

Architektur
Alle Register haben bei AMD64 eine Breite von 64 Bit. Wenn der Prozessor im 32-Bit-Kompatibilitätsmodus läuft, werden die obersten 32 Bit jedes Registers auf 0 gesetzt. Im 64-Bit-Modus bietet der Prozessor außerdem je 8 zusätzliche Integer- und SSE-Register, die im 32-Bit-Modus aus Kompatibilitätsgründen nicht verfügbar sind.

https://de.wikipedia.org/wiki/X64

 

[yummycandy]

@Wadenbeisser Ah cool, wußte ich gar nicht!

 

[catch 22]

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

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.

Anmerkung:
Mit "Gleichberechtigt" ist nicht gemeint, dass Intel für AMD optimieren soll oder gar muss, sondern lediglich dass die Prozessoren nicht in ihren Möglichkeiten zusätzlich durch eine gezielte und vor allem auch technisch überflüssige Abfrage künstlich limitiert werden.
->> Wenn Feature X drin ist, soll es genutzt werden. Wenn nicht, fällt es natürlich weg. Ist Feature X fehlerhaft implementiert, bitte an den Hersteller der CPU wenden. Mit der Fehlermeldung Y kann er sich auf die Suche nach einer Lösung für sein Problem machen.
Punkt aus Nikolaus.

 

[NameHere]

Wenn man denen das per Support mitteilt, was ich natürlich ebenfalls getan hab nachdem ich den Workaround zum laufen bekommen habe, wundert man sich allerdings ernsthaft, wie das bei so großen Firmen eigentlich läuft. Die haben Augen bekommen, so gross wie Untertassen und sind sich bis dato offensichtlich der Problematik der MKL gar nicht bewusst gewesen.

Zumindest wirkt das in der Antwort so.

Aber: "Die Thematik wird intern bereits diskutiert und ich bespreche dies aktuell mit unserer Entwicklungsabteilung."

Man darf also gespannt sein.

Finde ich gut das du auch deren Meinung zu den Thema angesprochen hast.

Ganz egal wie sie es später öffentlich beantworten, stehen sie im schlechten Licht da.

 

[Tzk]

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?

Wenn man dieser Argumentation umfassend folgt, dann dürfte niemand mehr auf diesem Planeten Software schreiben, weil die Hardwarehersteller ja eventuell Bugs eingebaut haben. Generell sollte man als Softwarehersteller doch eher davon ausgehen das der "Standard" erfüllt ist und die Befehlssätze korrekt funktionieren?! Und falls nicht, dann ist doch eher AMD am Zug die Bugs in ihrer Implementierung zu fixen!?

Also gäbe es (außer den Wettbewerber auszubremsen) keinen vernünftigen Grund statt auf Instructionset zu prüfen lieber die VendorID vorzuziehen?!

Darüber hinaus gibts am x86 Markt ja nur 2 Anbieter. Eine Abfrage auf Vendor ID ist also automatisch ne Abfrage für Intel als auch gegen AMD. Man kann in diesem Fall also durchaus vom bewussten Ausbremsen sprechen. Zumal danach ja trotzdem noch ne Insctructionset Abfrage kommen muss, da nicht alle Intels Cpus auch AVX2 beherrschen. Also: Warum muss man dann vorher noch auf VendorID abfragen?

 

[SubZero22]

Intel programmiert extra die MKL um den Einsatz CPU's des Konkureneten zu verhindern? War das die Aussage?
Ich bin kein Intel Freund und sehe eher bei Matlab den Fehler, da sie auch AMD CPU's für Ihre Software empfehlen obwohl diese garnicht richtig durch die Software unterstützt wird. Intel sagt es werden nur Intel CPU's unterstützt.
Wer hat jetzt falsche Informationen zu seinen Gunsten benutzt? Intel oder Matlab?

Intel baut ja auch eigene Benchmarks um die Konkurrenz anzupatzen oder schmiert halt Firmen damit eben nur deren Produkte gekauft werden, oder schaltet Standard Flags aus damit eben die Konkurrenz nicht die Grundperformance erreicht, mittlerweile sollte man sich Fragen was Intel nicht macht um die Konkurrenz schlecht darstehen zu lassen. Also du bist ein Intel Freund weil egal welche Kritik man anbringt die Konkurrenz ist ja immer schuld.

 

[Ned Flanders]

Ganz egal wie sie es später öffentlich beantworten, stehen sie im schlechten Licht da.

Und es werden leider noch einige folgen. Die MKL ist halt nicht nur in Matlab enthalten sondern auch in Conda/Anaconda, Numpy, Microsoft R, ...

Meine konkrete Hoffnung ist, dass die Hersteller und Communities aufwachen, und ihre Software nicht mehr fest mit der MKL verdongeln sondern beispielsweise OpenBLAS benutzen, oder eben dem User beim Installieren die Auswahl lassen. Das Intel aufhört eine Vendor String Abfrage zu benutzen glaube ich definitiv nicht, zumindest nicht bis ersteres Eintritt.

 

[gimmix]

Mit "Gleichberechtigt" ist nicht gemeint, dass Intel für AMD optimieren soll oder gar muss, sondern lediglich dass die Prozessoren nicht in ihren Möglichkeiten zusätzlich durch eine gezielte und vor allem auch technisch überflüssige Abfrage künstlich limitiert werden.

Ob diese "Gleichberechtigung", die du ansprichst, Bestandteil des x86-Lizenzvertrags zwischen Intel und AMD ist?
Intel wird sich darauf herausreden, dass MKL ausschließlich intel-Prozessoren "optimiert", nicht alle 64-Bit-x86-Prozessoren mit AVX2. Guckt euch mal die fishy Werbezeile auf der entsprechenden Seite an: https://software.intel.com/en-us/mkl.
Doch auch wenn Intel juristisch im sicheren Fahrwasser sein sollte, entstehen dem Konkurrenten durch die technisch überflüssige Vendor-Abfrage objektiv Wettbewerbsnachteile.

 

[max9123]

2) Welche Software nutzt denn sonst noch Intel-Bibliotheken mit eingebauter Vendor-ID-Abfrage?

Anaconda Python (auf Linux gibt es zumindest eine noMKL Version auf Windows nicht), Mathematica, diverse FEM Solver (zB: Abaqus, Ansys). , etc.

Mich hat schon gewundert warum zB, hier Epyc verbaut wird, da dieses Problem bei diverser closed-Source Software nicht so einfach zu vermeiden ist.

 

[NameHere]

Also du bist ein Intel Freund weil egal welche Kritik man anbringt die Konkurrenz ist ja immer schuld.

Das Intel nicht sauber arbeitet ist hinlänglich bekannt. Sie wissen aber auch wie sie ihren Schindluder Rechtskonform verpacken. In diesem Fall ist es eher Matlab und andere die bewusst oder unbewusst falsche Aussagen gegenüber den Kunden treffen.
Intel sagt unsere Software unterstützt nur Intel CPU's. Matlab sagt unsere Software unterstützt auch AMD CPU's mit AVX2 Befehlssaatz, dabei wird dieser auf AMD CPU in der Software ignoriert.
Nochmal deutlicher, Intel ist böse aber in diesem Fall ist der schwarze Peter eher den anderen zu zuschieben.

 

[DocWindows]

Man darf also gespannt sein.

Ich habe die MKL Core Library mal genauer angesehen.

Sie unterscheidet offensichtlich nicht nur 6x zwischen AMD und Intel, sondern auch sehr fein zwischen CPU-Architekturen. So gibt es CPU-Einordnungsfunktionen für

• Atom mit SSE 4.2 (Funktion mkl_serv_cpuisatomssse4_2)
• Atom mit SSE 3 (Funktion mkl_serv_cpuisatomssse3)
• Bulldozer (Funktion mkl_serv_cpuisbulldozer)
• CLX (Keine Ahnung was das ist. Vielleich Cascade Lake X?) Funktion: mkl_serv_cpuisclx
• Barcelona (Funktion mkl_serv_cpuisbarcelona)
• KNM (No Clue) (Funktion mkl_serv_cpuisknm)
• SKL (Analog zu CLX womöglich Skylake) (Funktion mkl_serv_cpuisskl)
• Zen (Funktion mkl_serv_cpuiszen)

Die VendorID wird über 3 Vergleiche zu 756e6547, 6C65746E, 49656E69 geprüft.
756e6547 = Hex für "uneG"
6C65746E = Hex für "letn"
49656E69 = Hex für "Ieni"

Zusammen: Genu ineI ntel

Ich kann aber nicht erkennen ob das dazu benutzt wird AVX2 zu disablen.
Für mich sieht es im Moment wie ein einfacher Bug aus.

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.

 

[catch 22]

Endlich mal eine eindeutige Aussage!

?
Du hast aber den Artikel schon gelesen und inhaltlich verstanden, oder? Diese von dir endlich entdeckte "eindeutige Aussage" geht doch klar aus der Artikel hervor.

... Standardmäßig fragt die Intel Math Kernel Library die Vendor-ID-Zeichenfolge des genutzten Prozessors ab. Wenn eine andere Zeichenfolge als „GenuineIntel“, wie beispielsweise „AuthenticAMD“, ausgelesen wird, greift die Bibliothek in einer Art Fallback-Modus auf gewöhnliches SSE zurück, ohne die von der CPU real unterstützten Befehlssatzerweiterungen zu beachten, was einen erheblichen Leistungsnachteil für Prozessoren vom Typ AMD Ryzen mit ihrer vollen SSE4-, AVX- sowie AVX2-Implementierung mit sich bringt. ...

https://www.computerbase.de/2019-11/mkl-workaround-erhoeht-leistung-auf-amd-ryzen/

 

[yummycandy]

Anaconda Python (auf Linux gibt es zumindest eine noMKL Version auf Windows nicht), Mathematica, diverse FEM Solver (zB: Abaqus, Ansys). , etc.

Nein, aber es gibt sowas. https://github.com/fo40225/Anaconda-Windows-AMD

 

[NameHere]

?
Du hast aber den Artikel schon gelesen und inhaltlich verstanden, oder? Diese von dir endlich entdeckte "eindeutige Aussage" geht doch klar aus der Artikel hervor.

https://www.computerbase.de/2019-11/mkl-workaround-erhoeht-leistung-auf-amd-ryzen/

Was meinst du warum der Beitragstitel "Intel MKL: Workaround erhöht Leistung auf AMD Ryzen signifikant" heißt und nicht "Intel MKL: Intel betrügt wieder und benachteiligt AMD"

INTEL IST BÖÖÖÖÖSSSSSEEEEEE!
MatLab und andere aber auch

 

[Sun_set_1]

Ich habe die MKL Core Library mal genauer angesehen.

Sie unterscheidet offensichtlich nicht nur 6x zwischen AMD und Intel, sondern auch sehr fein zwischen CPU-Architekturen. So gibt es CPU-Einordnungsfunktionen für

• Atom mit SSE 4.2 (Funktion mkl_serv_cpuisatomssse4_2)
• Atom mit SSE 3 (Funktion mkl_serv_cpuisatomssse3)
• Bulldozer (Funktion mkl_serv_cpuisbulldozer, Power -100%)
• CLX (Keine Ahnung was das ist. Vielleich Cascade Lake X?) Funktion: mkl_serv_cpuisclx
• Barcelona (Funktion mkl_serv_cpuisbarcelona, Power -50%)
• KNM (No Clue) (Funktion mkl_serv_cpuisknm)
• SKL (Analog zu CLX womöglich Skylake) (Funktion mkl_serv_cpuisskl)
• Zen (Funktion mkl_serv_cpuiszen, Power -200%)

SCNR

 

[catch 22]

Ob diese "Gleichberechtigung", die du ansprichst, Bestandteil des x86-Lizenzvertrags zwischen Intel und AMD ist?
Intel wird sich darauf herausreden, dass MKL ausschließlich intel-Prozessoren "optimiert", nicht alle 64-Bit-x86-Prozessoren mit AVX2. Guckt euch mal die fishy Werbezeile auf der entsprechenden Seite an: https://software.intel.com/en-us/mkl.
Doch auch wenn Intel juristisch im sicheren Fahrwasser sein sollte, entstehen dem Konkurrenten durch die technisch überflüssige Vendor-Abfrage objektiv Wettbewerbsnachteile.

Wenn MKL ausschließlich auf Intel Prozessoren hin optimiert wäre, also spitzfindig betrachtet nur auf Intel Prozessoren lauffähig wäre, dann sollte Intel das auch entsprechend kommunizieren, so dass die Nutzer von MKL, wie z.B. The MathWorks, Inc. mit MatLab, für Nicht-Intel Prozessoren zusätzlich eine vergleichbare Lösung parallel implementieren, oder von vorneherein MKL nicht nutzen, sondern eine Lösung die Herstellerübergreifend funktioniert.

Nochmal, Intel darf und soll gerne abseits der Funktionsbereitstellung in MKL für Intel Prozessoren optimieren (= Fähigkeiten der eigenen Prozessoren nutzen, um bessere Ergebnisse zu erzielen). Aber das bedeutet nicht, um es mal platt auf die Benchmarks herunterzudrücken, dass man die 100% Leistung der Intel CPU dadurch beeindruckender macht, indem man anderen Prozessorherstellern derart Stöcke zwischen die Beine wirft, dass deren Prozessoren lediglich auf 25% kommen, während sie ohne dies Stöcke ebenfalls auf 100% Leistung kämen, womit der Anreiz für Intel Prozessoren in diesen Anwendungsfällen gehörig sinkt (erheblicher Verlust des Kaufanreizes eines Intel Produktes zu übertriebenen Preisen, wie uns ZEN2 und die Preisnachlässe der Intel Prozessoren seit Zen2 gezeigt haben).

 

[Cr@zed^]

Intel Compiler 2.0 ...

Die Vergangenheit ruft