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

[blöderidiot]

So viel Blödsinn hier im Thread, zum Glück einige gute und durchdachte Aussagen. Fakt ist, der besagte Patch (Nutzung dieser Umgebungsvariablen) findet sich im MatLab-Forum schon vor 2018 und bei MatLab wusste man schon immer, dass Intel auf "seiner" MKL viel schneller rechnet als AMD (jeder wußte das) und MatLab hat genau nichts unternommen, um die AMD-BLAS zu integrieren, genauso wenig wie AMD dabei irgend eine Unterstützung angeboten hätte. Und diese Info findet sich hier mehrfach im Thread, ich habe es nur noch mal zusammengefasst. Nun könnte der Moralist kommen und sagen: HAAA, aber MKL fällt nicht automatisch auf die bestmögliche "AMD-Capability" zurück und das ist böse. Da entgegne ich: Ja, aber Intel ermöglicht es immerhin, diese bei Bedarf zu nutzen, obwohl es eine AMD-CPU ist (MKL_DEBUG - flags). 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?

 

[gimmix]

Bitte nochmal für die Nicht-Mattlab-User unter uns:

1) Hat die Vendor-ID-Abfrage irgendeinen Sinn, außer den augenscheinlichen, dass Intel keine Produkthaftung für Fremdhersteller übernehmen will, und damit en passant einen Wettbewerbsnachteil für AMD "billigend in Kauf nimmt"?

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

 

[nagus]

Herzlichen Glückwunsch Intel. Ganz prima, wie ihr euch weiter immer unsymphatischer macht bei mir. Ich frage mich langsam warum Intel in den USA nicht mit Sammelklagen überhäuft wird!!!

 

[bronks]

Ein anderer legitimier Weg, wäre die komplette Ignorierung fremder CPUs, die damit dann gar nicht mit der MKL laufen würden.

Die Lib wurde irgendwann vor knapp 20 Jahren programmiert. Das was AMD zu der Zeit unterstützt hat, berücksichtigten die Leute von Intel. So wie es programmiert wurde funktioniert es heute noch. Es gibt keinen Grund daran herumzubasteln. Das schon garnicht auf eigene Kosten.

Dann müßten die Entwickler standardmäßig zusätzlich OpenBLAS einsetzen.

Selbstverständlich wollen die sich das bei einem funktionierenden Programm antun.

 

[jemandanders]

Ich sehe den schwarzen Peter jetzt nicht zwingend bei Intel. Die müssten ihre Bibliothek dann doch auch für AMDs Implementierung verifizieren? Warum sollten sie das tun?

Den schwarzen Peter sehe ich bei MathWorks.
Wenn ich dort nach der Hardware Unterstützung schaue, wird AMD überhaupt nicht aufgeführt. Gefühlt wird jede kleine "Klitsche" aufgeführt. Nur AMD fehlt.
Finde ich ein wenig seltsam.

MatLab hat genau nichts unternommen, um die AMD-BLAS zu integrieren, genauso wenig wie AMD dabei irgend eine Unterstützung angeboten hätte.

Aha, hast Du da Insiderwissen? Wenn AMD sich da auf die faule Haut legt, braucht man sich nicht wundern.

 

[blöderidiot]

Den schwarzen Peter sehe ich bei MathWorks.
Wenn ich dort nach der Hardware Unterstützung schaue, wird AMD überhaupt nicht aufgeführt. Gefühlt wird jede kleine "Klitsche" aufgeführt. Nur AMD fehlt.

Waaaaaa. Tatsächlich! Hätte ich jetzt nicht vermutet, ist aber tatsächlich so.

Außerdem verüble ich AMD immer noch, dass sie OpenCL eingestampft haben (wahrscheinlich von Apple angeordnet) und man sich dafür seit Ewigkeiten mit dem halbgaren ROCm herumschlagen muss.

 

[gimmix]

Edit: Hier stand Quatsch. Wikipedia ist schlauer als ich.

 

[yummycandy]

Die Lib wurde irgendwann vor knapp 20 Jahren programmiert. Das was AMD zu der Zeit unterstützt hat, berücksichtigten die Leute von Intel.

Die Lib wurde doch weiterhin gepflegt, d.h. neue SSE und auch AVX Versionen wurden hinzugefügt. Ich wette, sie haben die SSE Unterstützung für nicht Intel CPUs auch nicht extra definiert, sondern lassen die auf der Intel Version laufen. (egal wie gut sie damit läuft) Gibt also keinen Grund in der Abfrage nicht den Intel AVX2 Code laufen zu lassen.

 

[Sun_set_1]

Genau, ich habe nichts anderes geschrieben. Und der Workaround ist seit Monaten bekannt, oh Aufschrei.

Googlen um jemanden ggf. zu diskreditieren hat ja ganz gut funktioniert. Genaue Quellenprüfung, und sehen, dass die Ersterwähnung letztes Jahr aus einem Mailverkehr zwischen Entwicklern einer Bibliothek und dem deutschen FZ Jülich resultiert, dann wohl doch nicht mehr.

Sonst hätte man kurz drüber nachgedacht, dass vllt ein User seinen Klarnamen nicht auf der CB Homepage haben wollte, der geht aus diesem SV nämlich hervor.

Weiterhin war es halt Mail-Verkehr und nicht öffentlich bekannt. Erst im Anschluss finden sich ein paar mutige, die es getestet haben und jetzt schließlich die echte VO.

Für mich von der Seite aus also alles gut gelaufen und genau so, wie man es von wissenschaftlichen Angestellten auch erwarten würde. Ist halt eben genau nicht die BILD-Zeitung, die den Mörder vor dem Mord präsentiert und den Aufschrei erzeugen will.

 

[Ned Flanders]

Ich sehe den schwarzen Peter jetzt nicht zwingend bei Intel. Die müssten ihre Bibliothek dann doch auch für AMDs Implementierung verifizieren? Warum sollten sie das tun?

Den schwarzen Peter sehe ich bei MathWorks.

Ich denke beides ist richtig. Es ist ja nicht so, als das AVX2 Code irgendeiner verifizierung bedarf. AMD muss sicherstellen, dass AVX2 Code auf ihren Prozessoren wie vorgesehen läuft. Aber es gibt ja nicht 3 Arten von AVX2 Code, der jedesmal auf Lauffähigkeit hin verifiziert werden müsste.

Und auch spiezifische Architektur Optimierungen betreffen typischerweise nur die Performance Charakteristika einer Architektur, wie beispielsweise Cache Größen, Latenz, etc... Das kann und soll Intel gerne optimieren mit der Folge, dass der Code dann auf Intel Systemen besser läuft als auf AMD Systemen. Jeder würde das machen. Dafür unterhält man typischerweise solche Produktlinien. ABER, in meinen Augen ist und bleibt das gezielte Abschalten ganzer Befehlssatzerweiterungen nach Vendor String einfach ein Unding, dass dringend abgestellt gehört, bzw. die Benutzung solcher Software in frei verkäuflicher Software gehört eingestellt, denn:

Man stelle sich folgendes vor: Wenn AMD in 2 Jahren eine marktbeherrschende Stellung bei High-End Grafikkarten ereichen würde (sagen wir so wie Nvidia heute bei High End GraKas wie der 2080 Ti oder Titan) und in ihrem Treiber eine CPU Vendor String Abfrage implementieren würde, die die Leistung des Renderpfads auf Intel CPUs um auch nur 15% reduzieren würde.... Würde man das auch verteidigen?... Hier, reden wir von 400% und die MKL ist quasi die 2080 Ti der nummerischen Libraries.

Der Vergleich ist nicht perfekt, aber Intel benutzt ihre MKL nicht dafür das maximale aus ihren eigenen CPUs rauszuholen, sondern den Einsatz von CPUs des Konkurenten zu verhindern. Zu nichts anderem ist diese Vendor String Abfrage gut. Sie macht Intel CPUs nicht schneller. Sie macht AMD CPUs langsamer.

------------

Unabhängig davon hat Mathworks bzw. Matlab definitiv ein Problem, denn die geben für ihr aktuelles Matlab Release als System Requirements an:

Und die letzte Zeile wirkt jetzt halt wirklich bizarr, wenn man überlegt, das auf deren Produkt AVX2 auf AMD CPUs bislang überhaupt nicht zum Einsatz kam.

Man könnte meinen denen wäre dieser Umstand garnicht bewusst gewesen, was aber auch nicht besser ist.

 

[DaZpoon]

Solche Weichen werden in etlichen Softwaren drin sein, ich würde da jetzt mal den Ball flach halten an Aufregung und Spekulation über genaue Hintergründe. Gerade bei Matlab kann ich mir vorstellen, dass einige Sachen im Auftrag entwickelt worden sind. Da würde ich mir auch nur den Hut aufsetzen, den ich verantworten muss. Man muss da auch im Hinterkopf behalten dass Matlab-"Code" in kompilierter Form auch auf diversen embedded Systemen kursiert, teils mit Echtzeitanforderungen. Da ist Verantwortung vor allem für Code nicht zu unterschätzen.

 

[Sun_set_1]

Ich denke beides ist richtig. Es ist ja nicht so, als das AVX2 Code irgendeiner verifizierung bedarf. AMD muss sicherstellen, dass AVX2 Code auf ihren Prozessoren wie vorgesehen läuft. Aber es gibt ja nicht 3 Arten von AVX2 Code, der jedesmal auf Lauffähigkeit hin verifiziert werden müsste.

Aber Mathworks oder Matlab hat definitiv ein Problem, denn die geben für ihr aktuelles Release als System Requirements an:

Anhang anzeigen 843324

Und die letzte Zeile wirkt jetzt halt wirklich bizarr, wenn man überlegt, das auf deren Produkt AVX2 auf AMD CPUs bislang überhaupt nicht zum Einsatz kam.

Man könnte meinen denen wäre dieser Umstand garnicht bewusst gewesen, was aber auch nicht besser ist.

Korrekt. Einen kleinen Kritikpunkt habe ich aber auch. Habe mir den SV zwischen FZ Jülich und den Lib-Devs durchgelesen. Was ja bei Fundus von Bugs und Lücken üblich ist, wieso wurde ML nicht um Prüfung / Statement gebeten? Ich meine im Prinzip machen Kunde und 3rd Party eine Entdeckung, bestätigen sich das gegenseitig... und fragen dann nicht beim SoftwareLieferanten nach?

 

[jemandanders]

Ich könnte mir gut vorstellen, das es in der Beziehung AMD / Mathworks "nicht ganz rund läuft" und die Prozessorempfehlung schon fast ein "Versehen" war.
Oder sie waren wirklich so Dumm, die Folgen der GenuineIntel Abfrage nicht zu bemerken?
Obwohl man so Dumm eigentlich nicht sein kann.

 

[Novasun]

Und das schlimme daran:
Niemand im professionellen Umfeld wird diesen Workaround nutzen, weil immer die Frage bleibt, ob trotzdem richtig gerechnet wird...

Das ist Quatsch. AMD kann AVX in Hardware. Wenn was falsch gerechnet werden würde - würde es an der Bibliothek dann liegen (und Intel würde sich an seinen eigenen Standard nicht halten).

 

[NameHere]

Der Vergleich ist nicht perfekt, aber Intel benutzt ihre MKL nicht dafür das maximale aus ihren eigenen CPUs rauszuholen, sondern den Einsatz von CPUs des Konkurenten zu verhindern. Zu nichts anderem ist diese Vendor String Abfrage gut. Sie macht Intel CPUs nicht schneller. Sie macht AMD CPUs langsamer.

------------
Unabhängig davon hat Mathworks bzw. Matlab definitiv ein Problem, denn die geben für ihr aktuelles Matlab Release als System Requirements an:


Und die letzte Zeile wirkt jetzt halt wirklich bizarr, wenn man überlegt, das auf deren Produkt AVX2 auf AMD CPUs bislang überhaupt nicht zum Einsatz kam.

Man könnte meinen denen wäre dieser Umstand garnicht bewusst gewesen, was aber auch nicht besser ist.

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?

 

[Wadenbeisser]

Die Lib wurde doch weiterhin gepflegt, d.h. neue SSE und auch AVX Versionen wurden hinzugefügt. Ich wette, sie haben die SSE Unterstützung für nicht Intel CPUs auch nicht extra definiert, sondern lassen die auf der Intel Version laufen. (egal wie gut sie damit läuft) Gibt also keinen Grund in der Abfrage nicht den Intel AVX2 Code laufen zu lassen.

Im Zusammenhang mit den weiter unten geposteten minimalen Systemanforderungen, wenn der x64 Support die Mindestvoraussetzung ist und SSE (sofern ich mich richtig erinnere) ein Bestandteil dessen ist, würde jene Mindestvoraussetzung dann nicht durch AMDs x64 Spezifikationen festgelegt worden sein? Ich bin mal gespannt wie die Verfechter dieser Ausschlussfunktion (das hat schließlich nichts mit Optimierung zu tuen solange sich Intel an die eigenen Standards hält) jetzt argumentieren wollen.

 

[Ned Flanders]

Intel programmiert extra die MKL um den Einsatz CPU's des Konkureneten zu verhindern?

Lass es mich so formulieren. Sie benutzen IMO extra keine Feature Set Abfrage, um den Einsatz von nicht Intel CPUs zu erschweren.

Wer hat jetzt falsche Informationen zu seinen Gunsten benutzt? Intel oder Matlab?

Matlab, keine Frage.

 

[PS828]

Seltsam dass mir so ein Thema gestern Abend entgangen ist
Ich bin schon davon überzeugt dass die Verantwortlichen bei AMD bezüglich dieses Umstandes sich bei Mathworks erkundigen, damit gewisse "Probleme" behoben werden. Es ist schlicht nicht angebracht CPUs eines Herstellers die bekanntermaßen die nötigen Befehlssätze unterstützen nur auszusperren weil nicht Intel drauf steht. Das sind marktmethoden wie ich sie vom Marktführer kenne
Da es spätestens jetzt hinreichend bekannt ist wird schon ein gewisser Druck ausgeübt werden. Ich hoffe dass hier auch bald entsprechende Nachbesserungen von offizieller Seite folgen werden

 

[NameHere]

Lass es mich so formulieren. Sie benutzen IMO extra keine Feature Set Abfrage, um den Einsatz von nicht Intel CPUs zu erschweren.



Matlab, keine Frage.

Endlich mal eine eindeutige Aussage!

 

[DaZpoon]

MATLAB läuft doch auf AMD, also wo ist da ein Problem? Ob es nun alle Features ausnutzt ist eine ganz andere Sache. Da liegen sicherlich noch weitere Features brach die man nutzen könnte - auch bei Intel Prozessoren.

Interessanter wäre aus meiner Sicht mal ein breitbandiger Test mit geänderter CPUID. Kann man das mit VMs hinbekommen? Ich vermute mal dass vor allem die ganzen proprietären Sachen ein solches Verhalten aufweisen.