News Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround

[usb2_2]

Die von dir behauptete Abfrage von Featuresets gab es nie, also musste nie etwas deaktiviert werden

Wenn es das nicht gibt und nur sortiert wird, ob es eine Intel oder AMD CPU ist, dann ist das wohl ein sehr ähnlicher Verstoß zu den Benchmark Spielchen, die Intel früher schon getrieben hat. Das war damals ja illegal also müsste es das heute auch sein. Mal sehen, ob da was passiert.

 

[Piktogramm]

dann muss es da ja einen entsprechenden Eintrag geben für Ryzen oder Zen geben, und den sehr ich in deiner Liste halt nicht.

Wenn "not intel" den default Pfad bekommt, muss man nicht auf AMD/Via bzw deren CPU-Familien testen. Die sind mit dem Catchall -> Default einfach ausreichend behandelt. Entsprechend wird sich da auch genau keine entsprechende Funktion finden.
Das es eine Unterscheidung für Bulldozer gibt, liegt allenfalls daran, dass Bulldozer mit dem default Pfad Probleme hatte.

und die saltyness, die gleichen Leute behaupten den gleichen unbelegten Unsinn wie schon zur Meldung vom 19.11 . Das ist schon ein bisschen hart.. Und zugegebenermaßen ist meine Grundlaune im Eimer. Zuhause rumsitzen ist doof, und 2Tage am Stück Software beim kompilieren zuschauen auch.

 

[Schattenspender]

Ist es hier nicht egal, wie Intel seine MKL programmiert? Schließlich weisen sie darauf hin, für welche Prozessoren das Ding programmiert wurde. Man könnte auch sagen, das alle anderen CPUs trotzdem mitlaufen ist doch ein feines Ding. Na gut, Helden sind sie trotzdem nicht.

Wenn sich jemand vor lauter Blödheit die Hand vor den Kopf knallen müsste, das sind doch wohl die Programmierer von Mathlab u.ä. Die benutzen eine Bibliothek ohne zu wissen, was die eigentlich macht. Und müssen erst durch @Ned Flanders darauf aufmerksam gemacht werden? Na ich weiß ja nicht.

 

[Piktogramm]

Wenn es das nicht gibt und nur sortiert wird, ob es eine Intel oder AMD CPU ist, dann ist das wohl ein sehr ähnlicher Verstoß zu den Benchmark Spielchen, die Intel früher schon getrieben hat. Das war damals ja illegal also müsste es das heute auch sein. Mal sehen, ob da was passiert.

In https://www.computerbase.de/forum/t...iziellen-amd-workaround.1933817/post-23908815 (Post #95) hat jemand die entsprechende Vereinbarung heraus gekramt.
Aktive Benachteiligung ist nicht erlaubte, das Unterlassen von Optimierungen für Mitbewerber ist jedoch ok (solang es kommuniziert wird).
Aktiv ist es erst dann, wenn jemand Codeschnipsel findet, die nur auf AMD Systemen laufen und dort für besonders schlechte Ergebnisse sorgen. Das wird aber eher nicht vorkommen. So wie die Bibliotheken aussehen, wenn man sie etwas auseinander nimmt, nehmen AMD CPUs die selben Pfade die z.B. auch Pentium4 Prozessoren nehmen würden.

 

[pipip]

Schattenspender
Matlab sollte sich Gedanken machen. Und dass man das nicht hat, ist ihnen Support scheinbar nur auf Intel CPUs wichtig gewesen. Jetzt wo Ryzen aber immer mehr Aufwind bekommt, mussten sie nun langsam handeln. Besonders dann als man in den Medien erwähnt wurde.

Piktogramm
Wie sieht es eigentlich bei Octave und Ryzen aus ?

 

[Ned Flanders]

Und zugegebenermaßen ist meine Grundlaune im Eimer. Zuhause rumsitzen ist doof, und 2Tage am Stück Software beim kompilieren zuschauen auch.

Hehe... Ja das klingt wenig beneidenswert! Mach dir noch ein Glas wein auf, bei mir hat's geholfen!

Was mich da halt wundert, ist, dass eine gepatchte mkl, bei der das akzeptierte Ergebnis der Vendor Abfrage auf 'AuthenticAMD' geändert ist korrekt mit AVX2 auf einem Ryzen läuft und korrekt mit AVX auf einem AMD FX. Die Info muss sie ja irgendwo her bekommen wenn's keine Feature Set Abfrage ist.

Gruss!

 

[Piktogramm]

@pipip
Keine Ahnung, mir sagt ohne den Einsatz einer Suchmaschine "Octave" noch nicht einmal etwas..

Ergänzung (30. März 2020)

@Ned Flanders
Wein hilft nicht, riesen Softwareprojekt und ich sitze dran nur wenige Bits am richtigen Ort zur richtigen Zeit in die richtige Richtung zu bewegen :/

Nunja, wie schaut der Patch denn genau aus?

 

[Ned Flanders]

Der Patch ändert die Zeichenfolge des akzeptierten Vendor Strings von 'GenuineIntel' in die Zeichenfolge 'AuthenticAMD'. Das ist alles.

Diese mkl.dll wirft auf meinem 2600x bei Abfrage Version -blas - AVX2 aus und auf einem FX 8350 AVX, auf einem i7 dann aber AUTO (SSe) aus. Also das komplett invertierte Verhalten.

 

[Denniss]

Die MKL gibt aktuell in 2019 update 5 und 2020 - hat die schonmal jemand getestet ob die Vendorabfrage noch drin ist und der Workaround noch funktioniert?

 

[Discovery_1]

Ich sage zu der Thematik nur eines. Um Intel werde ich in Zukunft erstmal einen riesen Bogen machen. Viel Positives gibt es imho wirklich nicht von dem Konzern zu berichten, schade. Vielen Dank an @Ned Flanders !

 

[Taxxor]

Es wurde nichts deaktiviert. Die von dir behauptete Abfrage von Featuresets gab es nie, also musste nie etwas deaktiviert werden.

Dann wäre es doch in der Tat interessant, zu erörtern, wie denn sonst die unterschiedlichen Featuresets von verschiedenen AMD CPUs korrekt erkannt werden, sobald die Vendor ID Abfrage positiv abgeschlossen wurde, wo es doch danach im Code gar keine Abfrage von AMD Prozessorfamilien gibt.


Da man ja nur den zu akzeptierenden Vendor String verändert hat, müsste danach trotzdem noch die Abfrage der Prozessorfamilien kommen.
In der Abfrage stehen aber natürlich nur Intel Prozessoren drin, da man hier ja eigentlich nur landet, wenn die Vendor Abfrage "GenuineIntel" ergeben hat

Durch das Ändern des zu akzeptierenden Strings in "AuthenticAMD" haben jetzt aber mit einer AMD CPU diese Abfrage bestanden, sämtliche Checks die jetzt hier gemacht werden, müssten also fehlschlagen.
Für die MKL hat man nun einen akzeptierten (Intel-)Prozessor, der aber keiner Prozessorfamilie zugeordnet werden kann.
Trotzdem wird das Featureset der AMD CPUs im Anschluss korrekt angewendet und kein Fallback auf SSE2 gemacht.

Der generelle Fallback auf SSE2 ohne Prüfung erfolgt im Original also nur, wenn die Vendor Abfrage ergibt, dass es keine Intel CPU ist.
Sobald die Vendor ID aber eine Intel CPU anzeigt, gibt es keinen generellen Fallback, auch dann nicht, wenn die Prozesorfamilie überhaupt nicht zugeordnet werden kann, sondern das Featureset wird ausgelesen, anders könnte es für die AMD CPUs nach manipulierter Vendor Abfrage ja nicht erkannt werden.

 

[Piktogramm]

https://en.wikipedia.org/wiki/CPUID

Die CPUID gibt genügend Möglichkeiten. Entweder man checkt Vendor und Family oder checkt alle Features einzeln.
Eine Möglichkeit ist, dass AMD für Family einfach Werte von vergleichbaren Intel CPUs nimmt. Womit die AMD CPUs bei geänderten Vendorcheck die selben Pfade nehmen würden wie Intels Produkte.
Eine andere Möglichkeit wäre, dass wirklich alle Features geprüft werden um dann retour die CPU Familie abzuleiten.
Als jemand der gelegentlich programmiert, wäre ich aber stark für die erste Möglichkeit. Macht weniger Arbeit

Ansonsten: http://www.gesetze-im-internet.de/urhg/__69e.html
Angenommen ich wäre so kackdreist und werfe da ein Decompiler drauf, darf ich die erhaltenen Kenntnisse nun veröffentlichen oder nicht?

Edit: Ok, ich war ein "ganz kleinen Hauch" naiv in meiner Annahme, dass sich da mal eben feststellen lässt was da genau geprüft wird. An einigen Stellen schaut es aus wie ein simpler Check auf die CPU Familie, an anderen Stellen ist es aber auch Voodoo (lies: Ich verstehe deutlich zu wenig von Assembler)

 

[Piktogramm]

Mein Zeitmanagement ist miserabel, aber...

Ok, da dachte ich mir, wieso nicht mal schauen, wo/wie die Umgebungsvariablen behandelt werden, dass "MKL_DEBUG_CPU_TYPE" muss sich ja wiederfinden. Klappt halt nicht, es gibt zwar eine "mkl_serv_getenv" funktion, die häufiger verwendet wird wenn es um Features geht (z.B. in der mkl_serv_is_avx2enabled ) aber ein paar Funktionsaufrufe und vor allem Goto später ist es für mich vorbei.

Es bleibt, nichts Genaues weiß man nicht

 

[calluna]

In der MKL-DNN ist es nach Feature-Set... auch wenn das vermutlich wenig über die MKL aussagt, da diese Bibliothek im Vergleich zur MKL "einfacher" ist und es darum geht AVX512 für die verschiedenen ML-Frameworks bereitzustellen.

IF_HANDLE_CASE(isa_all);
ELSEIF_HANDLE_CASE(sse41);
ELSEIF_HANDLE_CASE(avx);
ELSEIF_HANDLE_CASE(avx2);
ELSEIF_HANDLE_CASE(avx512_mic);
ELSEIF_HANDLE_CASE(avx512_mic_4ops);
ELSEIF_HANDLE_CASE(avx512_core);
ELSEIF_HANDLE_CASE(avx512_core_vnni);
ELSEIF_HANDLE_CASE(avx512_core_bf16);

Viel Positives gibt es imho wirklich nicht von dem Konzern zu berichten, schade.

Das Negative, worüber wir hier sprechen, sind aber nun auch schon seit Jahren dieselben Sachen, die eben nur immer wieder aufgewärmt werden, um sich darüber aufregen zu können.

Ebenso haben wir hier schon mehr als einmal darüber gesprochen, dass diese Geschichte mit den Compilern und der MKL von der US-Wettbewerbsaufsicht FTC untersucht wurde und Intel seitdem darauf hinweisen muss, dass so ein Produkt wie die MKL nur für Intel Produkte gedacht ist - was auch auf deren Webseite erfolgt. (Und nichts anderes macht auch AMD bei der AOCL).

Und trotzdem wird es immer wieder Personen hier geben, die Themen von vor 10 Jahren hervorkramen und meinen, das müsse unbedingt gerichtlich untersucht werden, es wäre illegal etc.

 

[ZeroStrat]

Intel, das ist so ein Sauhaufen, die machen doch glatt Hardware von AMD unter Linux rund 10% schneller: https://www.pcgamer.com/intel-ports-amd-compiler-code-for-a-10-performance-boost-in-linux-gaming/

Demnach wäre es auch okay wenn AMD in einer eigenen Lib nach der Intel ID abfragen würde und in dem Fall den takt um 400MHz reduziert?

Das wird ja so nicht gemacht, warum also der sonderbare Vergleich?

Immerhin wäre es ein Produktvorteil wenn man Intel CPUs ihr volles Potenzial nutzen lassen würde

Nein, Intel verfügt über eine eigene Lib. Die brauchen, im Gegensatz zu AMD, keine Fremdsoftware. Das was AMD bietet, kann hinsichtlich Performance und Stabilität nicht mit dem Wettbewerber mithalten. Wie so oft übrigens...

Aber so wie es scheint, liegt hier einfach eine ältere Version der MKL vor, in der die entsprechenden Prozessorfamilien einfach nicht eingepflegt waren. Also nichts mit böswilliger Sabotage. Dass Intel es so implementiert hat, also nicht direkt über die Featuresets, kann man ihnen nur schwer vorhalten. Es ist ihr eigenes Produkt, was sie teuer bezahlt haben.

 

[Denniss]

Hä ? Hast du die verlinkte Meldung nicht verstanden?
Bitte mal zeigen wo Deine Behauptung in der Meldung steht.
Ich sehe da 10% Mehrleistung unter Spielen für Intel-Grafik durch Nutzung einer für AMD-Compiler geschrieben Bibliothek

 

[biohaufen]

Intel, das ist so ein Sauhaufen, die machen doch glatt Hardware von AMD unter Linux rund 10% schneller: https://www.pcgamer.com/intel-ports-amd-compiler-code-for-a-10-performance-boost-in-linux-gaming/

Ich schätze du hast den Artikel nicht gelesen. Dort steht das sie den AMD Code in Ihrem Grafiktreiber unter Linux verwenden und dabei 10% mehr Performance gesehen haben.
Nicht das sie für AMD Hardware optimieren...

Falls du mir nicht glaubst zitiere ich mal direkt aus dem Artikel --> "As spotted by Phoronix, Ekstrand has enabled an I/O vectorization pass in an Intel driver for Linux, based on open source code originally written for ACO for use in AMD's Radeon Vulkan drivers."

Nein, Intel verfügt über eine eigene Lib. Die brauchen, im Gegensatz zu AMD, keine Fremdsoftware. Das was AMD bietet, kann hinsichtlich Performance und Stabilität nicht mit dem Wettbewerber mithalten. Wie so oft übrigens...

Ups, laut deinem Artikel nutzen sie die aber anscheinend schon ganz gern

 

[ZeroStrat]

Leute, ich fasse es nicht. Dann hat AMD Intel GPUs ausgebremst. Wir müssen sofort einen Shitstorm starten und ne News dazu raushauen.

 

[Taxxor]

Das wird ja so nicht gemacht, warum also der sonderbare Vergleich?

Ja es wird so nicht gemacht, wäre aber im Kern das gleiche wie die Frage
"Intel CPU? -> Featureset abfragen"
"Keine Intel CPU? -> Fallback auf SSE2"

Gut, der korrektere Vergleich wäre nicht die Abfrage nach Intel CPUs sondern nach keine AMD CPUs.
"Keine AMD CPU? -> Takt reduzieren", oder alternativ sowas wie "Keine AMD CPU? -> kein SMT/HT nutzen"

Denn wie wir ja durch den Patch von @Ned Flanders wissen, wird das Featureset der AMD CPUs erkannt, wenn der Intel CPU Check erstmal bestanden wurde, also ist die MKL durchaus in der Lage das zu tun, tut es nur nicht wenn es halt keine Intel CPU ist.

Da dieses zitierte Agreement sich explizit auf AMD bezieht, könnten Juristen aber wohl tatsächlich argumentieren, dass es ja keine gezielte Verschlechterung von AMD Produkten ist, da ja generell "keine Intel CPU?" gefragt wird und nicht spezifisch "AMD CPU?"

 

[Iscaran]

Durch das Ändern des zu akzeptierenden Strings in "AuthenticAMD" haben jetzt aber mit einer AMD CPU diese Abfrage bestanden, sämtliche Checks die jetzt hier gemacht werden, müssten also fehlschlagen.
Für die MKL hat man nun einen akzeptierten (Intel-)Prozessor, der aber keiner Prozessorfamilie zugeordnet werden kann.
Trotzdem wird das Featureset der AMD CPUs im Anschluss korrekt angewendet und kein Fallback auf SSE2 gemacht.

Der generelle Fallback auf SSE2 ohne Prüfung erfolgt im Original also nur, wenn die Vendor Abfrage ergibt, dass es keine Intel CPU ist.
Sobald die Vendor ID aber eine Intel CPU anzeigt, gibt es keinen generellen Fallback, auch dann nicht, wenn die Prozesorfamilie überhaupt nicht zugeordnet werden kann, sondern das Featureset wird ausgelesen, anders könnte es für die AMD CPUs nach manipulierter Vendor Abfrage ja nicht erkannt werden.

Und genau hier sehe ich die Juristische Problematik.

Ist es ein aktives behindern des Gegners, wenn man die ohnehin, bei vorliegen einer "korrekten Vendor ID" durchgeführte (zumindest partielle) Feature Set Abfrage, nicht durchführt ?

Ich meine, JA. Aber das sollen andere Entscheiden.

Ich sehe hier aber auch wie von (EDIT, sorry falsche Person: Calluna) Schattenspender geschrieben, vor allem die Entwickler in der Pflicht, öffentlich auf dieses Fehlverhalten hinzuweisen und zweitens dahingehend auch zu prüfen, wenn man schon eine closed Library verwendet. ODER man müsste eben eigentlich auf seine Software draufschreiben "läuft nur zertifiziert auf Intel".
Das ist aber womöglich ja genau das was Intel damit bezweckt, es ist also seitens der Softwareentwickler schon ein entgegenkommen wenn man dann das ganze "trotzdem" noch auf AMD laufen lässt.

AMD ist sich dessen sicherlich bewusst und geht hier deswegen nicht aggressiv öffentlich dagegen vor.

Überlegt man was passiert wenn Intel plötzlich die Regel ausgibt und verschärft nachprüfen lässt dass alle Programme die mit Intel Compiler, Intel MKL etc. laufen/geschrieben werden nur noch mit dem "Siegel" verkauft werden dürfen "zertifiziert nur auf Intel CPUs".

Das wäre mit einem Schlag der Verlust des ganzen Softwaremarktes für AMD.

Deswegen sehe ich hier eben vor allem die Softwareentwickler in der Pflicht solches "einseitiges" De-Optimierungsverhalten öffentlich zu machen und an solchen Stellen einfach als alternative auf was anderes setzen das Intel und andere CPU's "gleich" behandelt. (z.B. openBLAS).

EDIT: So etwas kann man auch in sehr neutralem Tonfall und ohne großen Shitstorm machen. Wenn sich das dann erst in der Öffentlichkeit breitgemacht hat, dass Intel hier eben "ständig" anderen ein Bein stellt ist das soviel negatives Marketing, daß Intel das von ganz allein unterlassen wird.