[News] Intel: Programmbibliothek Math Kernel Library MKL durch Trick auf Intel optimiert.

[Gamer1969]

Es gibt doch eine ganz einfache Möglichkeit dieses Dilemma aus der Welt zu schaffen.
Die Softwarehersteller müssen nur 2 Versionen ihrer Software produzieren, einmal Intel optimiert und einmal für AMD.
Damit würde dieser ganze …...vergleich wer den Längsten …. Balken hat aufhören und die Leute müssten dann genau überlegen welchen Hersteller sie kaufen. Bei einem Wechsel der Hardware steht auch ein Wechsel der Software an.
Eine Vergleichbarkeit zwischen den Systemen der Hersteller wäre ja so gut wie unmöglich da es dann darauf ankommt wie gut die Software auf den jeweiligen Hersteller optimiert ist. Oder ist das gerade der Vorteil?

 

[fdsonne]

Der Witz ist, das gibts doch... In Form von eben jenen Libs. Nur kannst du eben keinen Softwareentwickler der Welt zwingen, nur weil eine AMD mal wieder ein paar Produkte an den Markt bringt, die durchaus Erfolgreich sind/Perspektive haben, dass man immer alles stehen und liegen lässt und auf deren Zeugs hin agiert. Das ist ein langer Prozess, der meist mit Marktanteilen einher geht. Und das meint nicht irgendwelche MF-Verkaufszahlen an Schrauberbubies, sondern an real ausgelieferte CPUs im Feld in messbaren Zeiträumen. Meist Jahre bis Jahrzente.

Auch interessant, wenn man sich mal von Mathlab löst und einfach nur nach MKL vs. Alternativen bzw. genauer nach realen Benchergebnissen sucht, sieht das Bild auch wieder mal ein bisschen anders aus, als die Hardliner da wieder schüren.
Sowas hier bspw.:
OpenBLAS is faster than Intel MKL on AMD Hardware (Ryzen) - Performance - JuliaLang
Da ist dann MKL auch mal schneller als die Alternative auf dem AMD, definitiv nicht immer, aber manchmal.

 

[Gamer1969]

Da es ja den Hinweis gab das Theme ist ja schon von 2009, hier mal 2 Dokumente:

Hier mal eine Vereinbarung zwischen AMD und Intel

http://download.intel.com/pressroom/legal/AMD_settlement_agreement.pdf


Hier noch was aus 2009.

Zitat:

„Intel’s Unfair Methods of Competition and Deceptive Practices Maintained and Strengthened Intel’s Monopoly Position in the Relevant Markets“

„Intels unlautere Wettbewerbsmethoden und irreführende Praktiken behaupteten und stärkten Intels Monopolstellung auf den relevanten Märkten.“

Quelle:

https://www.ftc.gov/sites/default/files/documents/cases/091216intelcmpt.pdf

 

[Holzmann]

Naja wir werden sehen, falls sich jedoch heraus stellen sollte, dass eine Spende oder dergleichen Matlab zum ignorieren dieses Fehlers verleitet hat, sehe ich Schwarz, zumindest jedoch aber ist es im höchsten Maße moralisch fragwürdig.

 

[Holt]

Bei den eignen CPUs weiß man, welche Features unterstützt werden

Man kann es die Unterstützung über den Variable MKL_DEBUG_CPU_TYP (auf 5 setzen) auch bei anderen CPUs aktivieren, dann ist Intel aber raus, wenn die Lib Fehler wie Abstütze oder gar Rechenfehler erzeugt. Viele denken hier ja immer nur an die Performance, aber es kommt auch auf die Stabilität und korrekte Ergebnisse an und wenn Intel diese Features bei CPUs von AMD per Default nutzt, muss es eben auch sicherstellen das dies gegeben ist.

Man stelle sich den Skandal vor, wenn es dazu kommen würde, dass Programme mit der MKL auf AMD Rechnern abstürzen oder falsche Ergebnis berechnen. Damit dies nicht passiert, müsste Intel die MKL auch komplett auf den ganzen AMD CPUs validieren, wenn dort Befehlserweiterungen genutzt werden und das kann man Intel nun wirklich nicht verlangen.

Nochmal: Es ist AMDs und nicht Intels Aufgabe für eine ordentliche Softwareunterstützung seine Hardware zu sorgen, nur hat AMD da eben bisher nicht gerade geglänzt und überlässt es eher anderen dies zu machen bzw. arbeitet nur halbherzig an irgendwelchen Open-Source Lösungen mit. Neben der Lib kommt es ja auch auf die Compiler an, da hat Intel eben seinen eigenen und AMD macht was?

 

[DTX xxx]

Hypothetische Behauptungen machen nicht den Fakt ungültig, dass AVX bei AMD das gleiche ist, wie AVX bei Intel. Wenn also die gleichen Befehlsätze zum Einsatz kommen, welche bei AMD, als auch bei Intel gleich sind, warum sollen dann Unzuverlässigkeiten auftreten?

Das einzige was dann unzuverlässig wird, der Geldkoffer von Intel

 

[Tzk]

Man kann es die Unterstützung über den Variable MKL_DEBUG_CPU_TYP (auf 5 setzen) auch bei anderen CPUs aktivieren, dann ist Intel aber raus, wenn die Lib Fehler wie Abstütze oder gar Rechenfehler erzeugt.

Korrekt. Aber sofern AVX korrekt von Intel als auch AMD implementiert wurde: Warum sollte da irgendwas Abstürzen? Und falls es abstürzt weil AMD einen Bug im AVX hat: Warum sollte das dann Intels Problem sein?

---

Generell sehe ich hier zwei Probleme:
a) Intel checkt einfach auf "GenuineIntel" und lädt im Zweifelsfall halt "nur" SSE3 statt das eigentliche Instruktionset der Cpu zu prüfen. Das ist grenzwertig aber anscheinend legal machbar.
b) Softwarehersteller nutzen MKL blind und machen sich keine weiteren Gedanken. Das führt dazu das Matlab angeblich AVX2 Support auf AMD hat, durch MKL aber faktisch nur SSE2 genutzt wird (ohh, the irony!).

Intel muss davon abgesehn auch nach dem check auf "genuineintel" noch das Instructionset abfragen. Denn nicht alle Intel Cpus beherrschen AVX2... Das Gange bekommt dadurch halt ein Geschmäckle.

 

[DTX xxx]

Es sind schwache Argumente, nein billige Argumente zu sagen, wegen möglicher unzuverlässiger Ergebnisse. AVX ist in Intels CPU, als auch in AMDs CPU gleich. Das Programm fragt den Befehlsatz eh ab und der schnellste wird benutzt. Um die Worte fdsonne zu nutzen.
Wenn eben so ein Inteljünger wie fdsonne die anderen als AMD Fanboys bezeichnet, muss man natürlich mit Behauptungen seinen Standpunkt rechtfertigen, auch wenn es Fakt bleibt, AVX ist AVX, egal ob bei Intel, oder AMD.

 

[fortunes]

Btw.: Auch finde ich es geil, wie der Redakteur von CB einfach mal ganz dreist hier abgeschrieben hat bzw. den Artikel einfach nur übersetzt hat, ohne dies zu vermerken..

Und wenn die eigenen Argumente baden gehen bzw. jeder widerspricht, versuchst du abzulenken.

 

[Tzk]

Intel muss nur darauf hinweisen, dass die CPUs von anderen Herstellern keine Optimierungen erfahren.

Wobei sich hier schon die Frage stellt was eine "Optimierung" ist. Das Intel den Programmcode nicht speziell umschreibt damit er auf AMD schneller läuft sollte klar sein und ist selbstverständlich. Das dagegen ein verfügbares und im Code implementiertes Instructionset nicht genutzt wird ist für mich keine Frage der "Optimierung" sondern schlichtweg absichtliches Ausbremsen von unternehmensfremden Prozessoren.

Btw.: Auch finde ich es geil, wie der Redakteur von CB einfach mal ganz dreist hier abgeschrieben hat bzw. den Artikel einfach nur übersetzt hat, ohne dies zu vermerken..

Nur das TPU nicht die Primärquelle ist sondern NedFlanders1976 auf Reddit, der im Übrigen der gleiche NedFlanders bei CB ist.

 

[fortunes]

Wenn man eine AMD CPU hat, kann man doch einfach die AMD Math Library (LibM), wieso sollte man da erwarten das die Intel Lib auf AMD optimiert ist? Es wird auch keiner von der AMD Math Library erwarten, dass sie auf Intel CPUs optimiert sein wird. Was soll also der Sturm im Wasserglas?

Intel hat aber an der Stelle nicht "optimiert", sondern einfach nur die Konkurrenz "ausgeschaltet".

Intel prüft "Intel oder nicht-Intel".

Intel prüft nicht "AVX ja oder nein".

Letzteres wäre der richtige Weg gewesen. Man kann nämlich auch von der Software prüfen lassen, ob das System AVX unterstützt.

 

[Tzk]

Das wäre wohl der bessere Weg gewesen. Wobei die Softwareentwickler bei Mathworks und numpy halt auch gepennt haben, da die einfach ohne nachzudenken die MKL nutzen.

 

[reppetstoH]

Ich lass das jetzt einfach mal unkommentiert hier stehen.

Nathan Kirsch auf Twitter

Last week @intel suggested that we take a look at MATLAB workloads for CPU testing. A recent post on Reddit shows that @AMDRyzen CPUs do poorly with Intel MKL. A proposed 'fix' runs AMD CPUs in AVX2 mode. Perf gains on 2600x are between 20% and 300%.

Man kann nämlich auch von der Software prüfen lassen, ob das System AVX unterstützt.

Und das steht so auch empfohlen in jedem Programmers Guide ... auch denen von Intel.

 

[sch4kal]

Intel hat aber an der Stelle nicht "optimiert", sondern einfach nur die Konkurrenz "ausgeschaltet".

Intel prüft "Intel oder nicht-Intel".

Intel prüft nicht "AVX ja oder nein".

Letzteres wäre der richtige Weg gewesen. Man kann nämlich auch von der Software prüfen lassen, ob das System AVX unterstützt.

Und wieso sollte Intel eine tiefergehende Prüfung auf Instruktionen einbauen, wenn sie es viel einfacher anhand der CPUID/VendorID für die eigenen CPUs implementieren können ? Wer zwingt dich, die Intel MKL zu nutzen ? Blame Matlab für ihre kurzsichtige Entscheidung, numpy kann auch gegen OpenBLAS gelinkt werden, da FOSS.

 

[fortunes]

Und wieso sollte Intel eine tiefergehende Prüfung auf Instruktionen einbauen, wenn sie es viel einfacher anhand der CPUID/VendorID für die eigenen CPUs implementieren können ? Wer zwingt dich, die Intel MKL zu nutzen ? Blame Matlab für ihre kurzsichtige Entscheidung, numpy kann auch gegen OpenBLAS gelinkt werden, da FOSS.

Deine Ausreden sind ja echt der Oberhammer.

Jede Software, jedes Game prüft die Voraussetzungen, die zum Start notwendig sind. CPUs in Reihe anhand von CPU-Flags auszuschließen ist seit Jahrzehnten überholt - und ich kenne nur noch Intel, die das tun.

Wie man es besser macht:
Destiny 2: Spiel verlangt CPUs mit SSSE3-Befehlssatz oder neuer - ComputerBase
Da wird die verbaute CPU auf SSSE3 geprüft - und wenn sie es nicht kann, startet Destiny2 nicht.

Aber Hauptsache mal wieder eine fadenscheinige Ausrede von dir.

 

[DTX xxx]

sch4kal
Anstatt man sich sagt, schön wäre es Software zu nutzen und als Kunde kann ich entscheiden welche Hardware, konstruiert man irgendwelche Behauptungen inkl. keinerlei Fakten, um sich der Abhängigkeit eines Herstellers zu unterwerfen. Nennt man das Fanboy sein?

 

[Holzmann]

So wie es aussieht, Stand Heute, wird man Intel rein rechtlich wohl für das Vorgehen nicht belangen können, was aber bleibt sind die moralischen Aspekte und hier muss jeder selber entscheiden, ob er dies weiter unterstützten möchte oder eben nicht.

update im cb Artikel:
Intel MKL: Workaround erhöht Leistung auf AMD Ryzen signifikant - ComputerBase

Weiterhin darf man auf die offiziellen Antworten der Betroffenen gespannt sein.

 

[fortunes]

Natürlich wird sich Intel auf den Standpunkt "unsere Compiler, unsere MKL, unsere Entscheidung" zurückziehen.

Arroganz eines Ex-Monopolisten wie sie im Buche steht.

Verstehen hier im Forum ja einige ganz gut.

 

[Holzmann]

Letztlich gilt es die Umständen zu beleuchten, die es möglich gemacht haben, dass ein solches Problem 10 Jahre lang bestehen konnte, ohne das jmd. dangen was unternommen hat.

 

[sch4kal]

Es wurde was dagegen unternommen, Intel muss (und tut es!) überall erwähnen, das ihre Libs und Compiler auf non-Intel x86-CPUs nicht optimiert werden:



aus Folie 3, Tuning Workshop @ RWTH Aachen: https://doc.itc.rwth-aachen.de/download/attachments/3475020/00_Introduction.pdf?version=1&modificationDate=1389174351000&api=v2

Das hat die FTC schon 2010 festgestellt:

[...]In addition, the FTC settlement order will require Intel to:
...
disclose to software developers that Intel computer compilers discriminate between Intel chips and non-Intel chips, and that they may not register all the features of non-Intel chips.
[...]

FTC Settles Charges of Anticompetitive Conduct Against Intel | Federal Trade Commission

Und genau das haben sie auch mit der MKL getan, hat euch nur scheinbar 9 Jahre lang nicht gejuckt, oder warum kommt jetzt der große Aufschrei "wuääähhh wuäähhhh Intel tut in ihren eigenen Libraries AMD ausbremsen wuähhh".

 

[Paddy92]

Und wenn die eigenen Argumente baden gehen bzw. jeder widerspricht, versuchst du abzulenken.

Schon scheiße, dass ich in dem Beitrag Argumente geliefert habe und dieser, im Gegensatz zu deinem hier, nicht rein polemischer Natur war..
Aber du schießt dich ja selber gerne in Abseits.

Wobei sich hier schon die Frage stellt was eine "Optimierung" ist. Das Intel den Programmcode nicht speziell umschreibt damit er auf AMD schneller läuft sollte klar sein und ist selbstverständlich. Das dagegen ein verfügbares und im Code implementiertes Instructionset nicht genutzt wird ist für mich keine Frage der "Optimierung" sondern schlichtweg absichtliches Ausbremsen von unternehmensfremden Prozessoren.

Nein, es werden ganz einfach bei CPUs, welche offiziell nicht unterstützt werden, keine Optimierungen angewendet.

Nur das TPU nicht die Primärquelle ist sondern NedFlanders1976 auf Reddit, der im Übrigen der gleiche NedFlanders bei CB ist.

Das ist mir schon bewusst. Nur berechtigt dies den Redakteur nicht einfach nur einen Artikel zu übersetzen, ohne auf das Original hinzuweisen, nur weil die über das Gleiche berichten.

Aber hey, er hat den Artikel ja nicht komplett übernommen, sondern sich nur inspirieren lassen.

Es wurde was dagegen unternommen, Intel muss (und tut es!) überall erwähnen, das ihre Libs und Compiler auf non-Intel x86-CPUs nicht optimiert werden:

Darauf habe ich Holzi gestern schon hingewiesen. Scheint ihn nicht zu interessieren..

 

[Holzmann]

Darauf habe ich Holzi gestern schon hingewiesen. Scheint ihn nicht zu interessieren..

Doch interessiert mich schon, wenn Intel hier letztlich nichts vor zu werfen ist, ist das eben so.
Was hat AMD nur dazu gebracht 9 Jahre lang soviel Potential brach liegen zu lassen, ist mir völlig unverständlich. /:

Anwendungen mit Intel MKL lassen AMD-CPUs oft schlecht darstehen - Hardwareluxx

 

[Holt]

Das hat die FTC schon 2010 festgestellt:

Eben, selbst die FTC hat Intel nicht zu etwas gezwungen was manche hier im Forum von Intel verlangen. Demnächst verlange die wohl auch nicht, dass NVidia in seinem Treiber auch noch AMD Grakas optimal unterstützt

Jeder Hersteller ist selbst in der Pflicht, AMD hat eine eigene Math Lib, die Hersteller von Software wie Mathlab sollten dann eben eine Version mit der Intel Lib für Intel CPUs und eine mit der AMD Lib (oder eine anderen, die von AMD scheint ja nicht sehr gut zu sein) anbieten um CPUs beider Hersteller vernünftig zu unterstützen und wenn man jemanden angreifen sollte, dann eben die Hersteller der Software die dies eben nicht tun, sondern auch Kunden mit AMD CPUs nur mit einer Version bedienen die Intels MKL enthält.

 

[Mordrac]

wundert mich nicht.
ich denke sowas gehört zu intels werbekosten.

 

[Holt]

Willst du damit der FTC Bestechlichkeit vorwerfen? Oder denkst du wirklich ein Hersteller wäre verpflichtet seine Software für Hardware eines Wettbewerbers zu optimieren? Wo ist denn der AMD Graka Treiber der für NVidia Grakas optimiert ist oder umgekehrt der NVidia Treiber für AMD Grakas? Da ist es vielmehr so, dass die Treiber nur mit der jeweiligen Hardware laufen, Intel könnte die MKL auch einfach nur auf Intel CPUs lauffähig machen und bei Verwendung auf einer CPU eines anderen Herstellers einfach einen Fehlercode ausgeben, dass keine unterstützte Hardware vorhanden ist. Wäre dies nun besser?

 

[Ceiber3]

Willst du damit der FTC Bestechlichkeit vorwerfen? Oder denkst du wirklich ein Hersteller wäre verpflichtet seine Software für Hardware eines Wettbewerbers zu optimieren? Wo ist denn der AMD Graka Treiber der für NVidia Grakas optimiert ist oder umgekehrt der NVidia Treiber für AMD Grakas? Da ist es vielmehr so, dass die Treiber nur mit der jeweiligen Hardware laufen, Intel könnte die MKL auch einfach nur auf Intel CPUs lauffähig machen und bei Verwendung auf einer CPU eines anderen Herstellers einfach einen Fehlercode ausgeben, dass keine unterstützte Hardware vorhanden ist. Wäre dies nun besser?

So schauts aus, AMD könnte das selbe machen. Und bei Intel CPU's eine Fehlermeldung ausgeben. Frag mich ob das besser wer.

 

[flxmmr]

Und genau das haben sie auch mit der MKL getan, hat euch nur scheinbar 9 Jahre lang nicht gejuckt, oder warum kommt jetzt der große Aufschrei "wuääähhh wuäähhhh Intel tut in ihren eigenen Libraries AMD ausbremsen wuähhh".

Weil keiner von diesen ganz schnell die Mistgabel rausholenden Typen vermutlich jemals Software im HPC-Bereich verwendet hat. Geschweige denn entwickelt... Und leider sieht das auch bei den meisten Leuten, die in typischen "Technik"-Magazinen CPU-Benchmarks machen, nicht besser aus.

Und ansonsten ist das halt auch das Problem dieser unsäglichen proprietären Ökosysteme, in denen ja schon das Grundversprechen ist, mit Geld Performance oder irgendetwas anderes zu bekommen . Die Menschen, die MATLAB-Lizenzen kaufen (also keiner von den Spezialisten hier - Mathlab, weil Mathe, gell ....), obwohl sie nicht an irgendwelche Toolboxen gebunden sind, kaufen auch zertifizierte Hardware - und da gab es bis vor einiger Zeit halt mal nur ... Intel (insofern relativ nachvollziehbar, dass Mathworks eben dieser Kundschaft auch bietet, was sie will...).

(ich verwende ja die MKL nur auf den HPC-Systemen, wo es einfach ein bisschen extra-Leistung gibt, ohne dass ich mich mit irgendwelchen OpenBLAS-Optimierungen herumschlagen muss, denn das ist nicht mein Job, wenn nötig kann ich aber auch die MKL einfach austauschen, die Core-API ist jetzt doch schon relativ "vintage")

 

[fortunes]

Es wurde was dagegen unternommen, Intel muss (und tut es!) überall erwähnen, das ihre Libs und Compiler auf non-Intel x86-CPUs nicht optimiert werden:

Nochmal für dich, ganz langsam zum Mitmeißeln:

Funktionen in einer Software per CPU-Flag zu deaktivieren ist keine Optimierung, sondern ein simpler OFF-Schalter. Eine "Optimierung" hätte sein können, die Software auf das Vorhandensein der jeweiligen Funktionen prüfen zu lassen.

 

[sch4kal]

Nochmal für dich, ganz langsam zum Mitmeißeln:

Funktionen in einer Software per CPU-Flag zu deaktivieren ist keine Optimierung, sondern ein simpler OFF-Schalter. Eine "Optimierung" hätte sein können, die Software auf das Vorhandensein der jeweiligen Funktionen prüfen zu lassen.

Natürlich sind das Schalter zur Optimierung, sonst wird der default Codepath benutzt, der aber läuft.

Da, ein bisschen Lektüre für dich: supported processors

[...]It's technically accurate that these may be "slower" versions, but it's not true that the other versions would be faster on a processor that can't run them... it would be accurateto say these are the versions (using SSE3 but not SSE4)"work" as opposed to "crash" (crash is likely if trying to run instructions that are not supported in a processor).[...]

also...OPTIMIERUNG

Ich seh dir aber nach und stimme @flxmmr zu, du kommst scheinbar nicht aus der (HPC-)SW-Entwicklung.

 

[fortunes]

Natürlich sind das Schalter zur Optimierung

Man könnte von einer Optimierung sprechen, wenn man sagt "die Software unterstützt jetzt AVX512-CPUs".

Dann hätte man die Software tatsächlich, im Vergleich zur Vorgänger-Generation, "optimiert", also verbessert.

Aber die Software für AVX-CPUs freizuschalten, gleichzeitig aber mit einem Vendorstring-Flag für ganze Hersteller zu deaktivieren, ist keine Optimierung.

Etwas abzuschalten oder wegzulassen ist keine Optimierung. Versteh' das doch endlich. Die Software ist auf AVX optimiert - wenn ich AVX wegnehme, ist sie nicht mehr optimiert.

Oh man. Ihr Intel-Fanboys redet euch echt alles schön.

- - - Updated - - -

Um das ganze abzukürzen, ob Optimierung oder nicht, geht es ja eher wieder einmal um das Verhalten von Intel:

Anwendungen mit Intel MKL lassen AMD-CPUs oft schlecht darstehen