News Intel MKL: Matlab R2020a beinhaltet offiziellen AMD-Workaround

[Denniss]

Klar ersichtlich ein Verstoß gegen die Bedingungen in 2.3 obwohl Intel das findig zu umgehen versucht wenn sie angeben daß die MKL nur auf Intel läuft.

 

[jemandanders]

AMD müsste halt (noch) mehr in Sachen Software tätig werden. Aber mit 25% Marktanteil und entsprechend schmaleren Gewinnen ist da natürlich nicht so viel möglich, wie beim Wettbewerb.

Das ist ein Laienbefund hier im Forum. Sorry. Irgendetwas Handfestes wäre gut.

Laienbefund?
Das ist ein Original Intel Dokument. Wenn Du dem nicht glaubst, wem denn dann?

 

[calluna]

...eine positive technische oder konstruktive Maßnahme von Intel (jedoch keine Untätigkeit), die (i) die Leistung oder den Betrieb eines spezifizierten AMD-Produkts verschlechtert...

Ist das Prüfen auf die Vendor-ID nach Intel eine "positive technische oder konstruktive Maßnahme" oder eine "Untätigkeit"? ;-) Der Unterschied scheint banal... aber das ist er am Ende bei so rechtlichen Dingen nicht. Die Prüfung nach Vendor-ID AMD und dann der Rückfall auf SSE wäre dagegen tatsächlich eine "positive" Maßnahme.

Wie auch immer... AMD hat eine Rechtsabteilung... wenn das für die auch nur irgendwie relevant / interessant wäre, hätten sie etwas dagegen tun können.

Ich hatte mich mal dem Trugbild hingegeben, sie hätten sich irgendwie geändert.
Aber wie Blöd kann man sein, daran zu glauben?

Sorry, aber das finde ich ziemlich naiv... 1.) ist dieses Verhalten von Intel harmlos, vor allem im Verhältnis zu dem, was viele Unternehmen so machen - auch viele deutsche Großkonzerne -, was Menschen direkt oder indirekt physisch und psychisch schädigt. 2.) Folgen alle Aktienunternehmen mehr oder weniger derselben Logik.

 

[Ned Flanders]

AMD müsste halt (noch) mehr in Sachen Software tätig werden.

Unbedingt! Bei nummerischen Libs wird sich das hoffentlich durch die zwei Exascale Systeme El Capitan und Frontier bald erledigt haben. Ich kann mir jedenfalls nicht vorstellen, dass AMD da den Zuschlag bekommen hat ohne das eine MKL equivalente LA Unterstützung mit eingeplant ist. Ich hoffe ja das AMD hier über die OpenBLAS gehen wird und nicht auch etwas proprietäres raushaut. Die OpenBLAS kann garnicht gut genug sein.

 

[gaelic]

Laienbefund?
Das ist ein Original Intel Dokument. Wenn Du dem nicht glaubst, wem denn dann?

Natürlich ist der text valide. Was dieser nun rechtlich genau bedeutet erschließt sich mir als Laien nicht. Und ich nehme an auch du bist ein Rechtslaie.
Mich wundert ja: AMD ist seit mehr als einem halben Jahr bezüglich MKL nicht tätig geworden. Welchen Grund hat das?

 

[calluna]

@Ned Flanders

AMD hat die AOCL speziell für "AMD EPYC™ processor family" rausgegeben.... eine bessere OpenBLAS fände ich auch besser.

@gaelic

Das ist nicht erst seit einem halben Jahr bekannt... sondern seit vielen Jahren.

 

[gaelic]

Ich hoffe ja das AMD hier über die OpenBLAS gehen wird und nicht auch etwas proprietäres raushaut. Die OpenBLAS kann garnicht gut genug sein.

Ich hoffe das ja auch. Meine Tests am Threadripper im Vergleich zur MKL zeigen hier noch einiges an Potential.
Weiters: in meinem conda environment mit mkl muss ich keine Environment Variable setzen um AVX zu aktivieren ...

 

[Volkimann]

Wie auch immer... AMD hat eine Rechtsabteilung... wenn das für die auch nur irgendwie relevant / interessant wäre, hätten sie etwas dagegen tun können.

AMD hat auch jahrelang, wenn nicht sogar ein Jahrzehnt gebraucht damit was in Richtung Intel, der EU und den Verstößen passiert.

Natürlich treibt Intel irgendeinen Schundluder, das ist nun seit Jahrzehnten deren Geschäftspraktik, ebenso das sie Prozesse verschleppen, verhindern etc bis soviel Zeit ins Land gestrichen ist und der Konkurrent finanziell am Boden und/oder die Strafzahlungen schon mit in die Produktpreise eingerechnet sind.

Wie man als Konsument also dies befürworten oder gar verteidigen kann, indem man mit dem im besten Fall selbst erarbeiteten Geld so ne Scheisse unterstützen oder befürworten kann, entzieht sich meiner Logik.

 

[gaelic]

@gaelic

Das ist nicht erst seit einem halben Jahr bekannt... sondern seit vielen Jahren.

Also daß die Abfrage dermaßen simpel erfolgt und eigentlich nichts mit "Optimierung" zu tun hat ist erst seit @NedFlanders bekannt.

 

[Piktogramm]

Mal für all jene, welche Intel hier so sehr im Recht sehen:

Die haben 2009 mit AMD eine Vereinbarung getroffen.(Settlement Agreement)
Danach hat sich Intel verpflichtet in seinen Produkten keine Maßnahmen zu ergreifen, welche AMD Produkte benachteiligen.

Link:> http://download.intel.com/pressroom/legal/AMD_settlement_agreement.pdf <

[...]

Das hatten wir schon in der ursprünglichen Meldung, inkl. dass ich mir da mal die Mühe gemacht habe die Binaries abzuklopfen. Intel baut den Kram halt genau so auf, dass Intel CPUs optimierte Programmpfade nutzen können und AMD (wie alte Intel CPUs oder jene von Via) vergleichsweise langsame Pfade nutzen (SSE2 oder 4 ist da das höchste der Gefühle).
Intel hält sich damit an das was ihnen auferlegt wurde, also keine aktive Benachteiligung.

Auf jeden Fall danke an Alle, das Ganze ist interessant genug, dass ich es mir nochmal genauer angeschaut habe.

Funktionen der Intel libmkl_core.so der Version 2019.4.243-1

0000000000209140 T mkl_serv_cpuisatomsse4_2
0000000000209230 T mkl_serv_cpuisatomssse3
0000000000209050 T mkl_serv_cpuisbulldozer
0000000000209490 T mkl_serv_cpuisclx
00000000002092b0 T mkl_serv_cpuisitbarcelona
0000000000209420 T mkl_serv_cpuisknm
00000000002093a0 T mkl_serv_cpuisskl
0000000000209020 T mkl_serv_cpuhasnhm
0000000000209600 T mkl_serv_cpuhaspnr
0000000000209630 T mkl_serv_cpuhaspnr_true

Laut Funktionsnamen, erkennt das Ding wirklich nur die CPU Familie aber nicht direkt die Featurelevel.
Genau genommen gibt es mkl_serv_ mit cpuis/cpuhas über verschiedene Objectfiles hinweg:

$ nm -gC libmkl_*.so | grep cpuhas                                              
0000000000209020 T mkl_serv_cpuhasnhm
0000000000209600 T mkl_serv_cpuhaspnr
0000000000209630 T mkl_serv_cpuhaspnr_true
                 U mkl_serv_cpuhaspnr
                 U mkl_serv_cpuhaspnr
                 U mkl_serv_cpuhaspnr
                 U mkl_serv_cpuhaspnr

nm -gC libmkl_*.so | grep cpuis
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisclx
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisbulldozer
0000000000209140 T mkl_serv_cpuisatomsse4_2
0000000000209230 T mkl_serv_cpuisatomssse3
0000000000209050 T mkl_serv_cpuisbulldozer
0000000000209490 T mkl_serv_cpuisclx
00000000002092b0 T mkl_serv_cpuisitbarcelona
0000000000209420 T mkl_serv_cpuisknm
00000000002093a0 T mkl_serv_cpuisskl
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisitbarcelona
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisitbarcelona
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisitbarcelona
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisbulldozer
                 U mkl_serv_cpuisitbarcelona
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisknm
                 U mkl_serv_cpuisknm

Eine Prüfung auf Haswell (HSW?) habe ich nicht gefunden, nm -gC libmkl_*.so | grep hsw gibt nichts zurück.

Weiter ins Detail gehe ich nicht, habe kein Bock für euch §69e vom Urhebergesetz zu testen

 

[ZeroStrat]

Aus dem SETTLEMENT AGREEMENT:

"Intel wird keine künstliche Leistungsbeeinträchtigung in ein Intel Produkt aufnehmen oder von einer Drittpartei verlangen, eine künstliche Leistungsbeeinträchtigung in das Produkt der Drittpartei aufzunehmen. Wie in diesem Abschnitt 2.3 verwendet, bedeutet "künstliche Leistungsbeeinträchtigung" eine positive technische oder konstruktive Maßnahme von Intel (jedoch keine Untätigkeit*), die (i) die Leistung oder den Betrieb eines spezifizierten AMD-Produkts verschlechtert, (ii) nicht die Folge eines Produktvorteils von Intel ist und (iii) absichtlich die Leistung oder den Betrieb eines spezifizierten AMD-Produkts verschlechtert. Für die Zwecke dieses Abschnitts 2.3 bedeutet "Produktvorteil" alle Vorteile, Nutzen oder Verbesserungen in Bezug auf Leistung, Betrieb, Preis, Kosten, Herstellbarkeit, Zuverlässigkeit, Kompatibilität oder die Fähigkeit zum Betrieb oder zur Verbesserung des Betriebs eines anderen Produkts.

Dieser Abschnitt 2.3 verpflichtet Intel unter keinen Umständen dazu, (i) eine Handlung vorzunehmen, die einen Produktvorteil für ein AMD oder ein anderes Nicht-Intel-Produkt bietet, entweder wenn dieses AMD oder Nicht-Intel-Produkt allein oder in Kombination mit einem anderen Produkt verwendet wird, (ii) Produkte für bestimmte AMD-Produkte zu optimieren* oder (iii) technische Informationen, Dokumente oder Know-how an AMD weiterzugeben. "

* Aha, ist doch schon dehnbar. Das nicht Unterstützen von AVX kann doch bereits als Untätigkeit ausgelegt werden.
** Da AMD selbst keine konkurrenzfähige Lib hat, wäre es ein Produktvorteil für AMD, dass deren CPUs ihr volles Potential entfalten können. Konkurrenzfähigkeit der AMD eigenen Libs kann leicht über mangelnde Stabilität und/oder Verbreitung angefochten werden.
*** Support von AVX kann als Optimierung ausgelegt werden.

Ist das Settlement Agreement überhaupt noch gültig??

 

[jemandanders]

Sorry, aber das finde ich ziemlich naiv... 1.) ist dieses Verhalten von Intel harmlos, vor allem im Verhältnis zu dem, was viele Unternehmen so machen - auch viele deutsche Großkonzerne -, was Menschen direkt oder indirekt physisch und psychisch schädigt. 2.) Folgen alle Aktienunternehmen mehr oder weniger derselben Logik.

Natürlich war das Naiv. Ich bin aber mittlerweile geheilt.
Ich habe aber auch nicht geglaubt, das die sofort vom Saulus zum Paulus mutieren, sich aber zumindest an getroffene Vereinbarungen bzw Gerichtsurteile halten, wäre ja schon mal was gewesen.
So verhalten sich eigentlich im allgemeinen andere Großkonzerne, sofern sie nicht richtig abewichst sind.
Harmlos ist das eigentlich nicht. Es ist eine klitzekleine Änderung mit deutlicher Auswirkung.
Sie suggerieren Kompatibilität, in Wahrheit wird das Wettbewerbsprodukt auf die ältestmögliche (langsame) Funktion zurück gestuft.
Aber Hey, ich bin nicht AMDs Anwalt. Ich habe vor einiger Zeit meine persönlichen Schlüsse gezogen, verhalte mich entsprechend und gut ist.

 

[calluna]

Sie suggerieren Kompatibilität

Nein, tun sie nicht.

Auf der MKL Seite von Intel steht:

"Intel® Math Kernel Library (Intel® MKL) optimizes code with minimal effort for future generations of Intel® processors."

Auf der AOCL Seite von AMD steht:

"AOCL are a set of numerical libraries tuned specifically for AMD EPYC™ processor family."

Das da aber eine Kompatibilität besteht, liegt eben daran, dass beide Unternehem aufgrund der Lizenzvereinbarungen dasselbe "Interface" (mehr oder weniger) verwenden. Aus diesem Grund dürfte wohl umgekehrt die AOCL auch auf Intel CPUs laufen.

Ich bin auch nicht mit jedem Geschäftgebahren von Intel einverstanden, aber die MKL und andere gute Software-Bibliotheken stellen für mich eine gute Arbeit da. Ich sehe das als Produktpflege, welches durchaus - und zurecht! - die Kaufentscheidung beeinflussen kann.

Ergänzung (30. März 2020)

Also daß die Abfrage dermaßen simpel erfolgt und eigentlich nichts mit "Optimierung" zu tun hat ist erst seit @NedFlanders bekannt.

Ist schon mindestens seit 2010 bekannt.

The CPU dispatcher for the vector math library has a new branch for non-Intel processors with SSE2. Unlike the generic branch, the new non-Intel SSE2 branch is used only on non-Intel processors, and it is inferior in many cases to the branch used by Intel processors with the same instruction set. The non-Intel SSE2 branch is implemented in the 32-bit Windows version and the 32-bit Linux version, but not in the 64-bit versions of the library.

Und der "CPU dispatcher" wird von den Intel-Compilern eingefügt - das ist also sowieso nichts Spezifisches für die MKL.

https://www.agner.org/optimize/blog/read.php?i=49#73

Und was meinst du mit Optimierung? Die Optimierung der MKL besteht darin, dass die Algorithmen handoptimiert sind für die Verwendung mit AVX 1 / 2 und 512 etc. Natürlich läuft das auch auf einer AMD CPU, wenn es auf einer Intel-CPU mit demselben Befehlssatz läuft.

 

[Ned Flanders]

Ist schon mindestens seit 2010 bekannt.

Richtig und ich hab auch den Debug Mode nicht "erfunden". Aber "bekannt" würde ich dazu jetzt auch nicht sagen. Veröffentlicht trifft es eher, gewusst haben das aber letzlich sehr wenige und die meisten gingen einfach von mangelhafter Optimierung oder schlicht miserabler AMD Performance aus. I.d.R. letzteres.

 

[jemandanders]

Ist das Settlement Agreement überhaupt noch gültig??

Ich sehe da keine Zeitliche Beschränkung. Du?

Nein, tun sie nicht.

Auf der MKL Seite von Intel steht:

"Intel® Math Kernel Library (Intel® MKL) optimizes code with minimal effort for future generations of Intel® processors."

Auf der AOCL Seite von AMD steht:

"AOCL are a set of numerical libraries tuned specifically for AMD EPYC™ processor family."

Das da aber eine Kompatibilität besteht, liegt eben daran, dass beide Unternehem aufgrund der Lizenzvereinbarungen dasselbe "Interface" (mehr oder weniger) verwenden. Aus diesem Grund dürfte wohl umgekehrt die AOCL auch auf Intel CPUs laufen.

Ich bin auch nicht mit jedem Geschäftgebahren von Intel einverstanden, aber die MKL und andere gute Software-Bibliotheken stellen für mich eine gute Arbeit da. Ich sehe das als Produktpflege, welches durchaus - und zurecht! - die Kaufentscheidung beeinflussen kann.

Selbstverständlich können und sollen sie für ihre Produkte optimieren.
Sie dürfen den Wettbewerb lt. Vereinbarung nur nicht benachteiligen. Daher müsste die Abfrage eigentlich etwas anders aussehen. Den gleichen Stiefel machen sie ja auch mit ihrem Compiler. (Oder haben sie gemacht)
Aber das sollen die Anwälte klären, sofern Bedarf besteht.
Dieses Verhalten muss nur mal wieder den richtigen Köpfen bewusst werden, dann werden irgendwann auch die AMD CPUs gleichwertig behandelt.

Ergänzung (30. März 2020)

Aber "bekannt" würde ich dazu jetzt auch nicht sagen. Veröffentlicht trifft es eher, gewusst haben das aber letzlich sehr wenige und die meisten gingen einfach von mangelhafter Optimierung oder schlicht miserabler AMD Performance aus.

Jepp.
Das wurde mir auch erst im laufe der Forendiskussion im November bewusst.

 

[denglisch]

Sowas gibt's ja wirklich nur einmal in der Software Welt und es wäre eine Unsitte wenn so ein Mist Schule macht.

Gab es schon lange, gerade bei früheren Spielen oder auch Creative Soundkarten, die nur mit Intel zusammenarbeiten. Ein kleiner selbstgemachter Softwarepatch und es ging.

 

[calluna]

Dieses Verhalten muss nur mal wieder den richtigen Köpfen bewusst werden, dann werden irgendwann auch die AMD CPUs gleichwertig behandelt.

Unter Linux und AMD benutze ich Dask + OpenBLAS. Es geht auch ohne MKL.

 

[Rockstar85]

Danke @Ned Flanders für deine Mühe
Auch wenn du sonst dämlicher Flanders bist ^^

 

[denglisch]

So eine millionenschwere Software gibt es btw. auch von AMD.

Das ist das beste Gegenargument. AMD investiert auch, ist aber davon abhängig was beliebte Software verwendet um gut dazustehen. Ist bei CUDA auch nicht anders...

 

[Kacha]

Diese Art von Alltagspsychologie, also den anderen Menschen Motive für ihre Handlungen zu unterstellen, funktioniert schon im Alltag nicht besonders gut. Ich glaube, in Bezug auf Firmen funktioniert das noch viel weniger. ;-)

Das ist nur 1:1 die selbe Strategie, die sie schon mehrfach gefahren haben und zweimal deswegen auf die Finger bekommen haben. Das erste war die Geschichte mit den OEMs die AMD entweder komplett ausgeschlossen hat, oder nur erlaubt hat in schlecht konfigurierte Systeme zu kommen und die zweite eben die Geschichte mit dem Compiler. Diesen winzig kleinen Schritt zu gehen der dem ganzen Absicht unterstellt mit dem Ziel AMD schlecht dastehen zu lassen ist jetzt nicht so weit her.

Wie Ned Flanders schon schrieb... es gibt da verschiedene legitime Sichtweisen. Für mich ist die MKL Produktpflege, so wie CUDA bei Nvidia.

Nein, da CUDA eben nur auf Nvidia laeuft. Wuerde MKL nur auf Intel laufen und sonst einen Fehler geben, dann waere es Produktpflege. Wenn du den zitierten Kommentar nach diesem Absatz liest wird es erst recht klar. Das ganze laeuft ohne Probleme auf AMD mit deren vollem Featureset. Das einzige das es verhindert ist die Vendorabfrage.

Wenn man die mkl.dll patcht und die Zeichenfolge der korrekten Antwort der Vendor ID Abfrage von "GenuineIntel" auf "AuthenticAMD" ändert, läuft die MKL auf einem AMD FX mit AVX support, auf einem Ryzen mit AVX2 support und auf jeder Intel CPU im SSE Modus.

Also ganz bewusst Konkurrenz beschnitten obwohl die Funktionalitaet gegeben ist. Und mit der offensichtlichen Vendorabfrage ist die Absicht wohl auch ziemlich klar. Bin ja mal echt gespannt was ein Gericht da entscheidet. Und ich hoffe wirklich, dass es dazu kommt.

Das ist sie auch, mit dem Unterschied das CUDA auf AMD Karten nicht läuft (auch nicht im CUDA 1.0 Mode) und von Nvidia auch nicht mit "runs well on non Nvidia GPUs" beworben wird. Was ich meine, bei CUDA ist sich jeder klar was für eine Entscheidung er eingeht. Bei der MKL nicht wirklich und deswegen galt die MKL auch landläufig jahre lang als "schlecht optimiert" auf AMD CPUs dabei ist sie im grunde "gut pessimiert" wenn du weist was ich meine. Aber wir können uns da wirklich problemlos einigen das wir uns da nicht einig sind. Wie gesagt, beide Sichtweisen sind für mich absolut legitim.

Intel sagt schon auf deren Seite, dass es nur auf Intel laeuft. Im Gegensatz zu CUDA, dass wirklich komplett nicht auf AMD funktioniert, kannst du MKL auf AMD aber ausfuehren. Es ist auch recht klar warum Intel das macht wenn alle von "schlecht optimiert" ausgehen. Da wird halt am Intel Image poliert. Und ganz ehrlich, mit Intels Geschichte und Firmenkultur ist es schon naiv zu meinen, dass das in Ordnung geht. Deine Toleranz in aller Ehren, aber Intel lacht sich doch ins Faeustchen wenn sie die Kommentare ihrer Verteidiger hier lesen.

Sind sie das? Quelle?

MKL funktioniert mit AMD und derem kompletten Featureset durch abaendern der korrekten VendorID. Das heisst, das einzige was das verhindert ist die Abfrage des Herstellers. Dadurch, dass Intel auch der um einiges groessere Marktteilnehmer ist das mehr als duenn. Rechtliche Abhandlungen werden wahrscheinlich Jahre brauchen. Dazu muss es bei denen erstmal auf dem Radar auftauchen. Aber aehnlich gelegene Faelle, von Intel selber, zeigen doch recht deutlich wie duenn es ist.

Richtig und ich hab auch den Debug Mode nicht "erfunden". Aber "bekannt" würde ich dazu jetzt auch nicht sagen. Veröffentlicht trifft es eher, gewusst haben das aber letzlich sehr wenige und die meisten gingen einfach von mangelhafter Optimierung oder schlicht miserabler AMD Performance aus. I.d.R. letzteres.

Und gerade bei deinem letzten Satz sollte man in sich gehen und sich fragen: Koennte das das Ziel gewesen sein? Seinen Konkurrenten mit schlechter Performance zu assoziieren? Wieviel Auswirkung hat so eine Assoziation auf eine Kaufentscheidung? Wie genial das ganze funktioniert kann man hier im Forum taeglich beobachten. Das ganze wirkt Jahre, wenn nicht Jahrzehnte nach und setzt sich fest. Dagegen sind 1 Milliarde Strafzahlungen guenstig um solch ein Image zu etablieren. Vor allem da Veroeffentlichungen wie die hier an 99% der Menschen vorbei gehen. Als Firmenchef haette die Strategie mein Ja bevor der Vorschlag komplett ausgesprochen ist.