News Intel MKL 2020.2: Neuer AMD-Workaround schneller als Zen-Kernel

@Ned Flanders Verschleierung sehe ich nur bei den Intel Compilern, aber nicht bei der MKL und um die gehts hier ja. Auf der Homepage sind viele Hinweise dass es sich um eine Bibliothek für Intel Prozessoren handelt, und der Code macht kein Geheimnis daraus dass es eine Verzweigung des Codes je nach CPU-Hersteller gibt. Wir hatten das ja schonmal zusammen bei der letzten MKL News angeschaut.
 
  • Gefällt mir
Reaktionen: Holt
@mace1978

Ich kann mich da nicht einfach für einen Standpunkt entscheiden: ich finde Intels Verhalten in Bezug auf die MKL nachvollziehbar und vielleicht ist es auch moralisch fragwürdig, doch bisher habe ich es nicht so empfunden, weil ich die MKL als Produktpflege wahrnehme, ähnlich CUDA von Nvidia - zumal die Software offiziell nur Intel-Systeme unterstützt. (Etwas anderes wäre eine Software für mich, die beide Systeme offiziell unterstützt und dann absichtlich ein System benachteiligt - das fände ich moralisch verwerflich und es wäre zudem illegal.)
Und rein aus Sicht eines Unternehmens gäbe es gar keine Motivation mehr (glaube ich), so etwas wie die MKL zu entwickeln, wenn man damit seinen eigenen Produkten nicht einen Vorteil verschaffen kann.

Aus meiner Kundenperspektive wäre es natürlich wünschenswert, wenn ich die MKL mit einer AMD CPU verwenden kann und eine gute Leistung habe - was aber unter anderem daran liegt, dass die MKL die beste Bibliothek ist... deswegen wäre die ideale Lösung eine bessere Open-Source-Bibliothek.
 
An die Autoren vom Artikel:
Warum wird sich in dem Artikel auf Update 2 bezogen wenn es seit fast einem Monat Update 3 gibt

Update 3

  • Addressed performance regressions issue introduced in Intel® MKL 2020 Update 2.
bei denen man bzgl. Update 2 folgendes scheinbar behoben hat?
Update 2
Known Limitations



  • Issue: Performance regressions may occur on non-Intel x86-compatible processors. These regressions will be addressed in a future release.
Hat das Update keinerlei Relevanz beim dem Problem?
 
Rickmer schrieb:
Wie kann denn der R5 2600X im ersten Screenshot signifikant schneller sein als der R7 3700X?

Um das kurz aufzulösen: Siehe Benchmark Slide 6. Als ich den 2600x hab laufen lassen, lief dieser 3600MHz CL15 RAM GDM disabled. Das wird sicherlich den Großteil des Effekts den man hier sieht ausmachen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Rickmer
DocWindows schrieb:
Das hat nichts mit Intel vs. AMD zu tun, sondern mit der ganz einfachen Tatsache dass Intel seinen Kunden einen Mehrwert bieten will und deshalb diese Funktionssammlung kostenfrei zur Verfügung stellt. Seinen Kunden! Nicht den Kunden von AMD. Das hat auch nichts mit gutem oder schlechtem Softwaredesign zu tun, sondern mit der Idee unter der die Bibliothek entwickelt wurde.
Und was hat der intel-User davon, dass intel die Software auf anderen CPUs absichtlich langsamer läuft?
Gar nichts. Das einzige was er davon hat, er wird von intel verarscht, weil intel suggeriert ihm er hätte so einen Leistungsstarken Prozessor. BTW. dieses den Konkurrenten schwächer machen kostet Ressourcen, die könnte man tatsächlich in die eigene Entwicklung stecken, dann hätte der Kunde etwas davon.
Allerdings reden wir hier von intel. Da gibt es das Prinzip Gewinnmaximierung. Dem Kunden einen möglichst potenten Prozessor zu servieren ist gar kein Firmenziel. Das ist wohl auch der einzige Grund, warum AMD wieder aufschliessen konnte.



calluna schrieb:
Und rein aus Sicht eines Unternehmens gäbe es gar keine Motivation mehr (glaube ich), so etwas wie die MKL zu entwickeln, wenn man damit seinen eigenen Produkten nicht einen Vorteil verschaffen kann.
Wie oben geschrieben, den Mehrwert für den Kunden liefert die Leistung auf intel-Produkten. Die geringere Leistung auf AMD-Systemen bringt den intel-Kunden nichts.

Ob intel mit diesen Mogeleien tatsächlich Kunden fängt, das kann ich nicht beurteilen. Ich denke der Mainstream kriegt davon wenig mit, ob nun eine solche Software auf AMD nun etwas langsamer läuft oder nicht.
Die Leute, die ein solches Verhalten aber Ekelhaft finden, wird man dafür wohl eher nicht aus dem AMD-Lager locken können.
 
  • Gefällt mir
Reaktionen: CableGuy82
mace1978 schrieb:
Und was hat der intel-User davon, dass intel die Software auf anderen CPUs absichtlich langsamer läuft?

Der Intel-User hat etwas davon dass die MKL auf seinen Systemen schnell läuft. So rum ists richtig.

mace1978 schrieb:
Das einzige was er davon hat, er wird von intel verarscht, weil intel suggeriert ihm er hätte so einen Leistungsstarken Prozessor.

Frag dich mal was Intel davon hat Entwicklungsressourcen in so eine Bibliothek zu stecken, die dann auf Fremdsystemen möglicherweise schneller läuft als auf den eigenen.
Das ist kein gemeinnütziges Open Source Projekt wo Entwickler in ihrer Freizeit dran sitzen.

Ich finde Intel sollte noch eine kommerzielle Version dieser Lib anbieten. Für alle die kein Intel System haben. Die können dann einen Lizenzcode eingeben und auch die schnellen Pfade nutzen. Preis müsste man noch überlegen. Vielleicht 50- 100 Euro pro Nase? Wer sich nicht auf diese Weise an den Kosten beteiligen will, kann immer noch langsam rechnen lassen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Holt
Intel kann es einfach nicht lassen... Die schreien doch regelrecht, dass ihnen jemand auf die Finger haut.

Holt schrieb:
Wieso sollte Intel seine Lib überhaupt für CPUs der Konkurrenz optimieren? Soll doch AMD eine eigene Lib oder wenigstens einen Plug In für die mkl anbieten die dann auf AMD CPUs genutzt wird, damit das Thema endlich beerdigt werden kann. Muss etwa Intels Treiber für die Xe demnächst auch noch für die Radeon GPUs optimiert sein? Doch wohl hoffentlich nicht.

Ach Holt... wir wissen ja, dass dein Hirn schon das Logo von Intel traegt, aber ganz so strunzdumm musst du dich wirklich nicht anstellen.

Aber extra fuer dich:
  • Intel optimiert nicht fuer AMD
  • Intel bremst AMD CPUs in MKL aktiv aus
  • Intel nutzt keine Feature Abfrage
  • AMD hat eine eigene Lib

Wuerde Intel eine Feature Abfrage und keine Vendor Abfrage nutzen, kein Problem. Dann koennen sie auch soviel sie wollen fuer ihre eigenen CPUs optimieren. Aber aktiv Features ausschliessen weil es keine Intel CPU ist, obwohl die CPU das kann ist schlichtweg Marktmachtausnutzung.

calluna schrieb:
AMD hat eine eigene Lib, die nur für Zen gedacht ist... und AMD sollte ohnehin in diesem Bereich mehr liefern, vor allem bei der GPU... denn da hat Nvidia das bessere Paket aus Hard- und Software.

Tun sie, wenn man sich nicht komplett blind stellt. OpenBLAS ist die MKL Alternative, ROCm ist die CUDA Alternative. Bloss hat kein Framework Lust den gleichen Aufwand fuer ROCm zu betreiben wie fuer CUDA.

calluna schrieb:
Ach komm... läuft die AMD Bibliothek mit Intel CPUs? Diese Diskussion hatten wir schon unzählige Male.

Ja.

calluna schrieb:
Und es werden sich hier jetzt sicher wieder unzählige Leute aufregen, die mit der MKL niemals in Kontakt kommen.

Ja, ueber Marktmachtmissbrauch kann man sich aufregen ganz ohne das Produkt zu nutzen.

calluna schrieb:
Das mit dem Zen-Kernel ist eine Vermutung, keine Tatsache...

Nein.

0x8100 schrieb:
zur verteidung intels muss man immerhin sagen, dass ihnen das problem bekannt ist und sie das noch angehen wollen:

edit: ist das thema eigentlich noch aktuell? der blogeintrag ist vom 31.8. vor ca. 3 wochen wurde aber mkl 2020.3 released mit diesem changelog:

Muesste man testen, falls das nicht schon wer hat. Mich wuerde es aber nicht wundern wenn der Fix es noch schlechter macht.

@DocWindows Dann braucht es aber keine aktive Benachteiligung fuer nicht Intel CPUs. Optimierung fuer Intel CPUs und nicht optimierte Befehle wie AVX auf nicht Intel CPUs zu nutzen widerspricht sich nicht. Aktive Benachteiligung im Sinne von vorhandenen Features ueberhaupt nicht nutzen bei nicht Intel CPUs ist etwas komplett anderes. Wenn man den Unterschied nicht verstehen will, dann sollte man ernsthaft in sich hingehen und reflektieren.
 
  • Gefällt mir
Reaktionen: CableGuy82, Schraube24, s0UL1 und eine weitere Person
Holt schrieb:
Wieso sollte Intel seine Lib überhaupt für CPUs der Konkurrenz optimieren?
Will doch keiner, der Trick für besser AMD Performance ist doch gerade nicht den "optimierten" AMD Pfad zu nehmen sondern sich als Intel CPU auszugeben.


Deine Frage müsste ehr sein: "Warum sollte Intel nicht die CPUs der Konkurrenz sabotieren?"
 
  • Gefällt mir
Reaktionen: CableGuy82
Kacha schrieb:
Aber extra fuer dich:
  • Intel optimiert nicht fuer AMD
  • Intel bremst AMD CPUs in MKL aktiv aus
  • Intel nutzt keine Feature Abfrage
  • AMD hat eine eigene Lib

1. Falsch. In der Bibliothek sind Zen-Pfade enthalten. Man findet auch Pfade die "Barcelona" heißen.
Barcelona-CPUs sind ja schon etwas älter.
2. Falsch. Intel ignoriert die Extensions aller CPUs die nicht von Intel kommen.
Das betrifft theoretisch nicht nur AMD. Gäbe es morgen eine chinesische x86-CPU wäre sie ebenfalls betroffen (die sollen ja an einer arbeiten hab ich gehört)
3. Falsch. Es gibt Featureabfragen im Code
4. Weiß ich nicht. Aber es gibt auf jeden Fall noch ein alternatives Projekt OpenBLAS

Kacha schrieb:
Dann braucht es aber keine aktive Benachteiligung fuer nicht Intel CPUs.

Es ist eher eine aktive Bevorzugung von Intel CPUs als eine aktive Benachteiligung anderer CPUs, weil der Generische Weg der Default-Weg ist und der optimierte Weg explizit gewählt wird wenn eine Intel-CPU drin ist. Aber das geht schon in Richtung Haarspalterei.

Kacha schrieb:
Wenn man den Unterschied nicht verstehen will, dann sollte man ernsthaft in sich hingehen und reflektieren.

Wenn man den Unterschied von generischer Software für eine Prozessorarchitektur und spezieller Software für eine bestimmte CPU-Reihe nicht versteht, wird man nie begreifen warum die Dinge sind wie sie sind und warum das nicht sonderlich schlimm ist.
Das alles ist keine technische Frage, sondern eine strategische/kaufmännische Frage.
 
Zuletzt bearbeitet:
abcddcba schrieb:
Warum wird sich in dem Artikel auf Update 2 bezogen wenn es seit fast einem Monat Update 3 gibt

AFAIK ist die MKL 2020.3 zwar released aber bislang in keinem Packet enthalten, also (für mich) nicht ohne weiteres zu testen. Ich hab mir aber sagen lassen, dass das Problem auch in 2020.3 weiter besteht, der Eintrag im Update bezieht sich also scheinbar auf etwas anderes. Der Artikel ist zum aktuellen Zeitpunkt völlig korrekt. Ob und wie sich die Unterstützung weiter verbessert müssen wir abwarten. Ich bin aber hoffnungsvoll, denn wenn Intel sich anfängt zu bewegen, gehe ich davon aus, dass sie das auch wirklich umsetzten. Halbgar macht ja keinen Sinn und noch weniger es dann vorher anzukündigen.

In anderen Worten, um aktuell vollständigen AVX2 Support auf AMD CPUs zu bekommen bedarf es wohl auch mit 2020.3 dem neuen Workaround von DdK.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CableGuy82, Iscaran und SVΞN
mace1978 schrieb:
Das einzige was er davon hat, er wird von intel verarscht, weil intel suggeriert ihm er hätte so einen Leistungsstarken Prozessor.

Das sehe ich nicht so, zumal die MKL nicht von normalen Benutzern verwendet wird, sondern überwiegend von Personen, die Matlab verwenden, oder Python in der Anaconda-Distribution, bei der automatisch für NumPy und allen darauf aufbauenden Bibliotheken die MKL verwendet wird... oder als Backend für PyTorch und Tensorflow.
(Wobei jeder, der mit solchen Dingen zu tun hat, wissen sollte, was für Alternativen er hat... das sind ja alles keine unbedarften Anwender.)

Wer CPUs vergleichen will, der kann sich Benchmarks mit OpenBLAS anschauen.

Und an genau dem Leistungs-Unterschied zwischen OpenBLAS und der MKL kann man sehr gut erkennen, wie viel KnowHow in die MKL geflossen sein muss, denn an der OpenBLAS arbeiten auch keine Anfänger. (Die ja trotzdem eine gute Alternative ist!)
 
Zuletzt bearbeitet:
DocWindows schrieb:
Das hat nichts mit Intel vs. AMD zu tun, sondern mit der ganz einfachen Tatsache dass Intel seinen Kunden einen Mehrwert bieten will und deshalb diese Funktionssammlung kostenfrei zur Verfügung stellt. Seinen Kunden! Nicht den Kunden von AMD.
Etwas nitpicking, aber im Kern ist die MKL eigentlich keine Software für die Kunden von Intel (-CPUs), sondern eine Hilfe für Softwareentwickler um sicher zu stellen, dass deren Software (z.B. Matlab) so schnell wie müglich auf Intel CPUs läuft. Tendenziell eher vergleichbar mit dingen wie NVIDIA Turf Effects/Waterworks (mir fällt grad der Oberbegriff nicht ein).
 
  • Gefällt mir
Reaktionen: CableGuy82
Holt schrieb:
Apple iOS läuft nur auf Apple Rechnern und wo schreiten da die Wettbewerbshüter ein? Auch taugen die Treiber für AMDs und NVidias GPUs nur für deren eigenen GPUs, wo ist da das Problem?
Apple iOS kannst Du auf anderer Hardware zum Laufen bringen, wo ist das Problem? Der Unterschied ist der, entweder läuft es, oder nicht.
Holt schrieb:
Keine Ahnung woher man eine Verpflichtung ableitet, dass Intel seine Software auch auf den CPUs anderer Hersteller lauffähig machen muss, geschweigen denn das sie auch noch optimal darauf laufen muss,
Es wurde zwar schon oft gesagt:
Niemand sagt, daß Intel für andere Optimierungen erstellen muß. Wenn aber eine "Optimierung" des eigenen Produktes nur darin besteht, einen langsameren Pfad für Konkurrenz zu wählen und dies anhand des Brandings zu definieren, dann ist die Ausbremsen. Insbesondere daran erkennbar, daß die Konkurrenz in der Vorversion schneller lief. Und die Optimierung hat Intel nicht schnellwr gemacht, nur AMD langsamer. Andernfalls wäre es etwas anderes gewesen.
 
  • Gefällt mir
Reaktionen: CableGuy82 und Vindoriel
bad_sign schrieb:
Jetzt baut Intel schon explizit AMD Pfade, mal schauen welche Fehler sie einbauen ^^

Wenn Intel explizite Pfade für AMD einbaut, dürfen sie keine Fehler mehr einbauen. Das bisherige vorgehen war nur legal - ob es moralisch korrekt ist, ist eine andere Diskussion - weil es als "Untätigkeit" ausgelegt werden konnte, wenn explizit nur Intel-CPUs abgefragt werden und der Rest unter Default fällt.

Ergänzung ()

Forum-Fraggle schrieb:
Wenn aber eine "Optimierung" des eigenen Produktes nur darin besteht, einen langsameren Pfad für Konkurrenz zu

Schau dir den Unterschied zwischen OpenBLAS und MKL an... genau das ist der Grad an Optimierung. Aber ja, ich vermute, du meinst, dass diese Optimierung auf AMD Zen ebenso gut funktioniert, was nicht überraschend ist.
 
Zuletzt bearbeitet:
Miuwa schrieb:
Wenn Intel AMD CPUs supporten will, aber Angst davor hat, dass dort nicht alle Instruktionen korrekt umgestzt sind, dann müssten sie ihren Code so oder so auf AMD CPUs validieren
Warum müssen sie das? Ich arbeite in der Medizindiagnosetechnikbranche. Wir haben z.B. einen Test, der verschiedene Marker bei Krebs analysiert. 4 Marker sind dabei validiert, 3 nicht. Der Kunde kann den Test für die 4 Marker direkt zur Diagnose verwenden. Will er die anderen auch verwenden, muß er seober validieren.
Dies kann Intel auch machen: mkl ist nur für Intel Chips validiert.
 
  • Gefällt mir
Reaktionen: CableGuy82 und Holt
Artikel-Update: Auch Intel MKL R2020.3 benötigt Workaround
Auf Nachfrage von Community-Mitglied „0x8100“ hin, hat die Redaktion noch einmal seine entsprechenden Kontakte befragt, wie es sich mit der Performance auf AMD-CPUs unter Verwendung der neuesten Intel MKL R2020.3 verhält und erhielt prompt eine Anwort.

Auch wenn Intel bereits mit MKL R2020.2 angekündigt hat, auch x86-Prozessoren abseits des eigenen Portfolios in zukünftigen Veröffentlichungen besser zu unterstützen, ist dies mit Intel MKL R2020.3 noch nicht der Fall.

Intel schrieb:
Performance regressions may occur on non-Intel x86-compatible processors. These regressions will be addressed in a future release.

Auf AMD-CPUs wird weiterhin der spezifisch dafür vorgesehene Codepfad des neuen Zen-Kernels gewählt, der nach wie vor mit Leistungseinbußen behaftet ist. Auch mit Update 3 der Programmbibliothek laufen x86-Prozessoren, die nicht von Intel stammen, nur mit einem „Trick“ auf dem AVX2-Kernel, dann aber mit entsprechender Performance.

Der Workaround ist somit nach wie vor notwendig, wollen Anwender mit AMD-CPU die volle Leistung für mathematische Berechnungen mittels Intel MKL abrufen.

Die Redaktion dankt Community-Mitglied „0x8100“ für den Hinweis zu diesem Update.
 
  • Gefällt mir
Reaktionen: Schraube24, Iscaran, Rickmer und 2 andere
DocWindows schrieb:
Wenn ein Hersteller - sagen wir mal ein fiktiver Grafikkartenhersteller Pixeltech - eine Alt-gegen-Neu Upgrade-Aktion macht, wo du deine alte Grafikkarte einschicken kannst und dann eine neue rabattiert kaufen kannst, dann wird er dies wohl auf Altkarten der Marke Pixeltech beschränken. Diesen Rabatt-Vorteil wird er dir nicht gewähren wenn du ne Gigabyte-Karte einschickst
Der Vergleich paßt zwar sowieso nicht zum Thema, aber nein: i.d.R. will man gerade Kunden der Konkurrenz rüberziehen und lockt diese zu einem. Vgl Neukundenrabatte in der Telefonanbieterbranche.

Das Problem hier ist, würde Intel nur Funktionsabfragen stellen, würde AMD CPUs ungebremst laufen, oder gar nicht, daher wurde,gegen AMD optimiert. Letzteres kann Intel egal sein, ersteres aber nicht.
 
  • Gefällt mir
Reaktionen: CableGuy82
Forum-Fraggle schrieb:
Will er die anderen auch verwenden, muß er seober validieren.

Das wäre halt die vernünftige Lösung. Wenn Intel, wie Ihr, sagen würde, könnt ihr verwenden, müsst ihr allerdings selbst validieren, dann wäre das ja alles kein Prob. So macht es ja beispielsweise Mathworks. Die haben den Workaround selbst validiert und freigegeben. Nur hat Intel daraufhin Mathworks sprichwörtlich den Stecker gezogen - und allen anderen gleich mit.
 
  • Gefällt mir
Reaktionen: CableGuy82, Iscaran, Aldaris und 4 andere
HAse_ONE schrieb:
Intel soll einfach GAR NICHTS machen. Intel soll nichts für AMD Optimieren. Die sollen einfach "nicht Intel" CPUs nicht grundlos benachteiligen.
Knuddelbearli schrieb:
Wie oft den noch, nein Intel muss für AMD nicht optimieren, soll ihn aber eben auch nicht bewusst ausbremsen, was Intel hier aber macht.
Eben, was Intel hier macht, ist aktive Behinderung der Mitbewerber durch Manipulation. Das haben wir den Intel-Promotern wie HOLT auch schon zig mal gesagt. Aber offenbar will er das gar nicht verstehen: statt diesen Fakt abzuspeichern, bringt er immer wieder gleiche Leier der Sorte "Intel muss nicht extra arbeitsintensiv optimieren." (was ja nun niemand verlangt hat).

Man nennt es "Nebelkerzen werfen".
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CableGuy82, HolySkillet und Vindoriel
Zurück
Oben