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

[Dai6oro]

Was ich aber schon wieder geil finde ist, dass Intel legitreviews vorgeschlagen hat MATLAB fürs CPU testing zu nehmen. Ein dickmove von der Firma nach dem anderen. Alles! was dieser Verein vorschlägt sollte 2x-3x geprüft und im Zweifelsfalle nicht verwendet werden.

 

[Krautmaster]

so wichtig kann der Sachverhalt ja nicht sein wenn es 10 Jahre braucht bis man darüber mal diskutiert, zumal das Prob ja bekannt war. Schon sehr strange das ganze.

 

[nille02]

Unterm Strich heißt die Intel MKL nicht umsonst Intel MKL.

So Funktioniert es in der x86 Welt aber nicht. Da wird das Feature abgefragt und nicht der Vendor um zu bestimmen welche Funktionen ich nutzen kann. Intel macht hier aber etwas exotisches und schaut nur auf den Vendor. Als größter Anbieter von x86 CPUs nutzen sie hier klar ihre Position aus und als Entwickler würde ich auch nicht davon ausgehen das Intel hier so arbeitet denn das macht niemand so.

 

[Che-Tah]

Na vor 10 Jahren wurde schon über Intel MKL und AMD LibM disskutiert.
AMD LibM konnte zwar AVX... Intel Prozessoren liefen aber mit SSE weil AMD nur das FMA4 abgefragt hatte was nur AMD hatte.
Intel hatte dafür schon damals die Vendor ID abfrage drinnen...

 

[SVΞN]

@DocWindows die Frage die sich mir stellt und die man vielleicht ganz allgemein mal stellen sollte, warum existiert ein solches Problem seit 10 Jahren und warum unternimmt niemand etwas dagegen?

Weshalb akzeptieren Unternehmen wie MathWorks, dass ihre Software mit um bis zu 75 Prozent geminderter Leistung auf AMD-Prozessoren läuft? Zumal der Workaround den Ned Flanders hier ,wohlgemerkt als absoluter "Non-IT-Professional", präsentiert hat, so einfach wie simple ist?

Weshalb das so ist und zwar nicht nur bei Matlab/MathWorks, sondern bei so gut wie allen Softwarelösungen die auf MKL basieren, darüber darf sich gerne jeder sein eigenes Bild machen. Keine der betroffenen Firmen wollte also, dass seine Software abseits von Intel-CPUs performant läuft? Das lass ich dann mal so stehen.

Das Intel LegitReviews in der letzten Woche sogar vorgeschlagen hat, Matlab als Benchmark für CPU-Leistung zu nutzen, muss man wohl auch nicht weiter kommentieren.

"Last week @Intel suggested that we take a look at MATLAB workloads for CPU testing!", LegitReviews

 

[Dai6oro]

Evt. liegt es daran dass von den letzten 10 Jahren in 8 AMD gar keine Rolle gespielt hat. Das ändert sich nun und Ergebnisse die außer der Norm sind werden genauer betrachtet und das ist verdammt nochmal an der Zeit.

 

[Che-Tah]

@SV3N:
Kannst du hier nachlesen:
https://www.agner.org/optimize/blog/read.php?i=49

 

[Ned Flanders]

Man muss Intel in der Tat zugutehalten, dass sie nicht gerade damit werben, dass die MKL Universal auf allen CPUs schnell läuft. Sie ist in erster Linie eines. Ein Verkaufsinstrument von Intel.

Warum man eine Vendor String Abfrage braucht erschließt sich eben nur aus dieser Sicht. Die macht die Software in keinem einzigen Fall schneller. Der einzige Grund warum man diese einbaut ist den Code unter Vorraussetzung X gezielt langsamer zu machen.

Wie du sagst, jetzt kann man diskutieren ob das legal, egal oder normal ist.

Die Welt wäre besser wenn es so etwas nicht geben würde.

Evt. liegt es daran dass von den letzten 10 Jahren in 8 AMD gar keine Rolle gespielt hat. Das ändert sich nun und Ergebnisse die außer der Norm sind werden genauer betrachtet und das ist verdammt nochmal an der Zeit.

So ist es.

 

[corvus]

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

Das ist mir sogar nun neu, hast evtl. eine Quelle dazu? Ging komplett an mir vorbei. Obwohl ich SC2 ausschließlich auf AMD gezockt habe.

 

[gaelic]

Funktioniert die environment variable auch unter Linux. Ich und meine Kollegen nutzen zuhauf Numpy und GAMS/gurobi und sind hier sicherlich massiv betroffen.

Ah, gefunden:

export MKL_DEBUG_CPU_TYPE=5

 

[MaverickM]

Ich fände es letztlich deutlich ehrlicher, wenn Intel die Ausführung der MKL auf Nicht-Intel-Prozessoren generell verweigert, statt sie künstlich zu behindern. Damit gäbe es wenigstens klare Verhältnisse.

 

[Taxxor]

Hätte es sich für sie finanziell rentiert den Aufwand zu betreiben, bei dem vergleichsweise geringen Marktanteil von AMD im Businessumfeld oder gar in wissenschaftlichen Einrichtungen? Eher nein. Also hat man sich das gespart.

Ach komm das Problem war anscheinend lange bekannt und die Lösung sind drei Zeilen Code, wo ist da finanzieller Aufwand?

 

[Benji18]

Das Intel LegitReviews in der letzten Woche sogar vorgeschlagen hat, Matlab als Benchmark für CPU-Leistung zu nutzen, muss man wohl auch nicht weiter kommentieren.

"Last week @Intel suggested that we take a look at MATLAB workloads for CPU testing!", LegitReviews

das braucht dich auch nicht wundern bei den Praktiken die weit über die dubiosität hinausgehen, z.b. das absichtliche verschweigen mittels NDA siehe Cascade Lake Sicherheitslücken (obowhl Intel den als "fixed" verkauft hat).

od. das man embedded Atom Chips mit wissentlichen HW Bug der zum Totalausfall führt an Enterprise Kunden geliefert hat und das über jahre --> das wurde auch erst public weil Cisco mittels reverese Engeneering Intel die sprichwörtliche Pistole auf die Brust gesetzt hat und wie man sieht 3gen später und der BUG ist nach wie vor in der HW drinnen .....

 

[ZRUF]

@MaverickM @SV3N
Das kann ganz einfach eine wirtschaftliche Entscheidung sein. 5% globaler Computer Sales = AMD. 2-3% globaler Computer Sales in Business. Vermutlich noch weniger im wissenschaftlichen Umfeld. Der Mehraufwand hätte sich für MathWorks wohl einfach nicht gelohnt.
Wie gesagt: Inzwischen schaut das schon wieder anders aus. Und MathWorks täte gut daran, dass sie das Problem angehen, da ihnen sonst zukünftig ziemlich rauer Wind entgegenblasen könnte.

Und um es klarzustellen: ich schließe nicht aus, dass es irgendwelche Schmiergeldzahlungen etc. gegeben haben könnte. Es kann nur schlichtweg viel banaler sein. Wenn ich ein Unternehmen leite und weiß, dass 99% meiner spezifischen Kundschaft Produkte der Firma I verwenden und nur 1% Produkte der Firma A, dann würde ich aus wirtschaftlicher Sicht auch einfach sagen: dieses 1% muss mit der schlechteren Performance leben oder ein anderes Produkt erwerben. Einfache Kosten-Nutzen-Rechnung.
Wechseln bei meiner Kundschaft auf einmal aber viele zu Firma A, dann wird das ganze schwieriger zu beurteilen. Ab wann habe ich ein positives ROI oder alternativ: Ab wann schadet es meinem Unternehmen, wenn man weiß, dass es bei Konkurrenten die Einschränkungen eventuell nicht gibt, auch wenn die auf Produkten der Firma I vielleicht nicht ganz so performant laufen, dafür aber eben nur wenig langsamer auf I und 300+% schneller auf A.
Dann kann es auch ohne direkt positiven ROI wichtig sein gegenzusteuern, weil es eben der Zukunftssicherung dient.

Dass ich die VendorID-Abfrage seitens Intel für völlig überflüssig halte, ist ein anderer Punkt. Rechtlich bin ich Laie. Das traue ich mich nicht zu bewerten.

 

[gaelic]

So, abseits von Matlab starte ich heute (eher morgen) eine Reihe von Tests mit NumPy, GAMS und gurobi unter Linux auf einem Threadripper2950X. Ich meld mich dann ob und welche Unterschiede ich erlebe.

 

[v_ossi]

[...] Damit gäbe es wenigstens klare Verhältnisse.

Klare Verhältnisse sind aber das Letzte, wenn man haben will, wenn man sowas abzieht.

Moralisch ist das verwerflich, auf legaler Ebene aber wohl nicht direkt strafbar.

@Ned Flanders Starke Arbeit. Zeigt mal wieder, dass man gar nicht genug Skepsis den IT Größen gegenüber haben kann.

 

[ZRUF]

Ach komm das Problem war anscheinend lange bekannt und die Lösung sind drei Zeilen Code, wo ist da finanzieller Aufwand?

Das Problem ist eben nicht mit 3 Zeilen Code gelöst. Die Lösung von @Ned Flanders ist eben nichts, was man implementieren darf, weil eine Veränderung der Intel MKL laut Lizenzbedingungen nicht erlaubt ist. Bliebe also auf OpenBLAS zu setzen für AMD. Ein separater Codepfad, der auch gepflegt werden will. Das verursacht Kosten.
Wie gerade geschrieben: Lohnt nicht, wenn 95+% der eigenen Kundschaft auf Produkte von Intel setzen (negativer ROI).
Alternativ OpenBLAS für alle. Wäre eine gangbare Möglichkeit kostet aber auf Intel CPUs Performance. Bei gleichbleibendem Kundenstamm also auch keine wirkliche Alternative. Das Geschrei der bestehenden Kunden mit Intelmaschinen wäre riesig.

Dass es theoretisch mit minimalem Aufwand gefixt werden könnte... das ist eine andere Sache und da kann und will ich dir auch nicht widersprechen.

 

[MaverickM]

Ab wann habe ich ein positives ROI

Diese ganzen Überlegungen scheitern aber an der Tatsache, dass - wie von Externen Leuten hier bewiesen wird - die Bremse mit einfachsten Mitteln behoben werden kann. Das ist rein vom Investitionsaufwand buchstäblich gar nichts für die Entwickler.

Ich sehe da wenn überhaupt ein Hinderniss seitens Intel. Das will man dort natürlich nicht. Und verbietet ggf. per Nutzungsbestimmungen das Rumdoktoren an der API.

 

[Ned Flanders]

So, abseits von Matlab starte ich heute (eher morgen) eine Reihe von Tests mit NumPy, GAMS und gurobi unter Linux auf einem Threadripper2950X. Ich meld mich dann ob und welche Unterschiede ich erlebe.

Das wäre sehr gut! Du kannst ja dafür den Sammelthread nehmen.

 

[gaelic]

Das Problem ist eben nicht mit 3 Zeilen Code gelöst. Die Lösung von @Ned Flanders ist eben nichts, was man implementieren darf, weil eine Veränderung der Intel MKL laut Lizenzbedingungen nicht erlaubt ist.

Was wird denn verändert? Es wird eine Environment Variable gesetzt, nichts weiter. Mach dich nicht lächerlich.