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

[Gamefaq]

Was ist für dich "mkl_blas_def_dgemm_kernel_zen", wenn das keine Optimierung für AMD sein soll? Und warum läuft diese dann so gut auf AMD-Prozessoren?

Ohh Mann du redest grade gehörig am Thema vorbei. Das ist eine Erkennung, keine Optimierung. Denn du hast nicht verstanden das OHNE diese Erkennung es auf AMD Prozessoren BESSER läuft!

 

[calluna]

Entwickler, die auf Vendor oder Device IDs optimieren, sollten Branche wechseln.

Ja, das wäre der Fall, wenn der Entwickler nicht für die Firma arbeitet, für deren Hardware er Software entwickeln soll.

Und mein "ich würde es genau so machen" bezog sich nicht auf das Entwickeln von Software, sondern darauf, nur eigenen Produkten einen Vorteil zu verschaffen - was aus unternehmerischer Sicht für mich rational nachvollziehbar ist. Als Kunde finde ich das natürlich Mist.

 

[0x8100]

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


Known Limitations

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

https://software.intel.com/content/...l-library-release-notes-and-new-features.html

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:

Update 3

• Addressed performance regressions issue introduced in Intel® MKL 2020 Update 2.

 

[Powl_0]

Aha, aber von Intel verlangt man dass sie Entwicklungsaufwand betreiben von dem ihr Konkurrenz profitiert?

Nein, von Intel erwartet man hochwertiges Softwaredesign. Ein Nebeneffekt davon wäre, dass die Lib auch auf anderen Prozessoren schneller liefe.

Nicht umsonst wird dir bei jeder großen low level API geraten, die Feature Sets zu prüfen. Ist zB bei Vulkan und DX12 auch so. Da wird nicht geprüft ob Vendor=Nvidia oder Vendor= AMD, sondern da wird geprüft welche Features die Hardware unterstützt und entsprechend der Pfad gewählt. Wenn die Ausführung des Features auf der Hardware dann falsch erfolgt, beschuldigt man korrekterweise den jeweilige Hersteller.

Ergänzung (28. September 2020)

Ja, das wäre der Fall, wenn der Entwickler nicht für die Firma arbeitet, für deren Hardware er Software entwickeln soll.

Schlechte Ausrede. Nur weil ich für Firma X arbeite, entschuldigt das kein schlechtes Design. Du magst kein Problem mit dieser Gier und der daraus folgenden beschissenen Software haben, aber dann bleibt das trotzdem nur eine Ausrede. Gute Entwicklung sollte Vorrang haben. Und Vendor checks sind nunmal kein gutes Design.

 

[Vindoriel]

Da sieht man wieder die typischen dreckigen Machenschaften seitens Intel. Aber ist ja "Standard", wie uns die Geschichte lehrt...

 

[Ned Flanders]

Weil sie sonst validieren müssten ob dies stabil ist und die Ergebnisse auch wirklich immer stimmen

Das hat ja Mathworks bereits für sie erledigt. Eigentlich wäre es doch viel einfacher für Intel diese Ganze Diskriminierung per Vendor String an den Nagel zu hängen, die Validierung den Software Anbietern zu überlassen (siehe Mathworks) und sich zurückzulehnen weil ihre CPUs auch ohne diesen ganzen Quatsch dank AVX512 Exklusivität bei der MKL schneller als die Konkurenz mit AVX2 sind.

Genau da verstehe ich Intel nicht. Warum tun die sich und uns diesen Quark an?

Einfach AVX512 in jeder CPU anbieten und nicht nur in der Server/HEDT Reihe (kommt ja mit Tiger Lake eh) und sich selbst aus der Schussbahn nehmen. Dieses antikompettitive Gemurkse ist doch absolut unwürdig bei einer gescheiten Produktstrategie auch absolut unnötig. Zumal Produktsegmentierung per SIMD support doch nur dafür sorgt, dass die entsprechende SIMD Unterstützung sich am Softwaremarkt nicht durchsetzt --> AVX512 - was wiederum nur Nvidia und CUDA in die Karten spielt.

Das ganze ist imho einfach eine völlig unausgegorene Produktstrategie die noch nichtmal ihren Zweck erfüllt.

 

[Powl_0]

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

Nix Verteidigung. Das machen sie jetzt ja nur, weil sie ordentlich Gegenwind bekommen haben. Lob gibts nur, wenn aus eigener Kraft gut entwickelt wird.

 

[Wadenbeisser]

Weil sie sonst validieren müssten ob dies stabil ist und die Ergebnisse auch wirklich immer stimmen, denn es ist ja Intels lib und Intel wäre schuld wenn dem nicht so ist. Warum sollte sich Intel diese mühe machen? Soll doch AMD dies selbst für seine keinen Lib machen.

Es geht um die Nutzung standardisierter Befehlssätze.
Sofern also nicht grundsätzlich damit falsch gerechnet wird sehe ich keinen Grund warum sie nicht genutzt werden sollten, es sei denn Intel hält sich nicht an die eigenen Standards und macht ne extra Wurst daraus.

 

[Miuwa]

Jetzt mal eine generelle Frage, die mir bei manchen Diskussionen hier immer wieder aufkommt:

Darf man sich eigentlich nur über Verhalten von Firmen beschweren, wenn es gegen Gesetze verstößt?

Generell bin ja schon der Meinung, dass man moralisch fragwürdiges, verwerfliches, kundenfeindliches, unfaires, asoziales etc. ... Verhalten durchaus anprangern sollte, selbst Wenn es nicht gegen Gesetze versößt oder man das zumindest nicht nachweisen kann. Dabei finde ich es auch in Ordung, wenn in einer vernünftigen Diskussion unterschiedliche Ansichten darüber aufeinandertreffen, ob das Verhalten jetzt tatsächlich moralisch fragwürdig, verwerflich, kundenfeindlich, unfair ... ist. Aber eine Gesellschaft, die alles in Ordnung findet, was nicht gegen die momentanen Gesetze verstößt braucht sich nicht wundern, wenn sie irgendwann von vorne bis hinten ausgebeutet wird und die Gesetzte selbst moralisch fragwürdiges, verwerfliches, kundenfeindliches, unfaires Verhalten fördern.

Sorry, wenn das etwas OT ist, aber das musste mal raus.

 

[Salamimander]

Weil sie sonst validieren müssten ob dies stabil ist und die Ergebnisse auch wirklich immer stimmen, denn es ist ja Intels lib und Intel wäre schuld wenn dem nicht so ist. Warum sollte sich Intel diese mühe machen? Soll doch AMD dies selbst für seine keinen Lib machen.

Schwachsinnsargument. Wenn es so wäre, wäre AMD schuld. Es IST ABER NICHT SO! AVX ist spezifiziert. Punkt.

 

[Dragon0001]

Ohh Mann du redest grade gehörig am Thema vorbei. Das ist eine Erkennung, keine Optimierung. Denn du hast nicht verstanden das OHNE diese Erkennung es auf AMD Prozessoren BESSER läuft!

Entweder hast du die Quelle des Artikels nicht gelesen oder du lügst ganz bewusst. "mkl_blas_def_dgemm_kernel_zen" ist der "Zen-optimized kernel", der aber noch nicht für alle Funktionen verwendet wird.
https://danieldk.eu/Posts/2020-08-31-MKL-Zen.html

 

[Powl_0]

Auch so, zwei Codepfade zum Preise von einem, wo gibt es denn dies Sonderangebot gerade?

Du willst es nicht verstehen...

Intel unterstützt offiziell eh keine AMD CPUs, also müssen sie da auch nichts validieren. Und wenn sie sich den Aufwand der Validierung machen, na dann sollen sie halt den AVX Pfad validieren. Unterstützen die relevanten AMDs ja alle, also können sie sich dafür das Validieren des x64 Pfads auf AMD sparen. Egal wie du es drehst und wendest, der Aufwand für Intel bleibt der gleiche.

 

[Wadenbeisser]

Aha, aber von Intel verlangt man dass sie Entwicklungsaufwand betreiben von dem ihr Konkurrenz profitiert?

Nö, als Kunden von Intel verlangen dass das genutzt wird was auch vorhanden und von der Software prinzipiell unterstützt wird. Man hat schließlich auch für die Software gezahlt die sie nutzt.

 

[Holt]

AVX ist spezifiziert. Punkt.

Und alle Implementierungen sind garantiert immer fehlerfrei, träume weiter!

 

[Powl_0]

Klar und die werden auch garantiert niemals einen Fehler der in der MKL passiert auf Intel abwälzen wollen, nie

Noch einer für die IL. Wieso sollte Intel AMD unterstützen? Muss Mercedes in der Formel 1 nun auch Ferrari verraten wie man in den Grauzonen des Reglements mehr Leistung aus dem Motor damit sie wieder wettbewerbsfähiger werden? Nein, also wieso sollte Intel SW auch auf fremden CPUs optimal laufen müssen?

Meine Güte...intel soll AMD doch nicht unterstützen. Stellst du dich grad absichtlich so an?

Anständiges Software design statt beschissenen Vendor locks und fertig. Dann gäbs das ganze Gekeife nicht.

Ergänzung (28. September 2020)

Und alle Implementierungen sind garantiert immer fehlerfrei, träume weiter!

Kann doch Intel egal sein! Die garantieren nur die Funktion auf ihren CPUs. Ob der non-AVX Pfad auf fremden CPUs richtig funktioniert, garantieren sie ja auch nicht.

 

[0x8100]

Nix Verteidigung. Das machen sie jetzt ja nur, weil sie ordentlich Gegenwind bekommen haben. Lob gibts nur, wenn aus eigener Kraft gut entwickelt wird.

verteidigung in dem sinn, dass das problem zum release dokumentiert wurde. damit wird niemand überrascht, der die mkl in seinem programm implementiert. so konnte z.b. matlab bei der vorherigen versionen bleiben und mit dem bekannten workaround läuft alles richtig weiter.

 

[DocWindows]

Nein, von Intel erwartet man hochwertiges Softwaredesign. Ein Nebeneffekt davon wäre, dass die Lib auch auf anderen Prozessoren schneller liefe.

Nicht umsonst wird dir bei jeder großen low level API geraten, die Feature Sets zu prüfen. Ist zB bei Vulkan und DX12 auch so.

Es handelt sich hier aber nicht um eine allgemeine API, sondern um eine Bibliothek von Intel für Intel User. Der Zweck dieser Bibliothek ist, Intel Usern einen Mehrwert zu bieten. Daher ist für mich nicht ersichtlich warum AMD User auch diesen Mehrwert bekommen sollten.

Nö, als Kunden von Intel verlangen dass das genutzt wird was auch vorhanden und von der Software prinzipiell unterstützt wird.

Es ist von anfang an klar was die Bibliothek macht und welche CPUs unterstützt werden. Wenn man damit als Softwarehersteller nicht einverstanden ist, dann kann man sie eben nicht nutzen. Wenn ich mit der Lizenz einer Bibliothek für mein persönliches Projekt nicht einverstanden bin, muss ich eben auch weitersuchen.

 

[wayne_757]

Weil sie sonst validieren müssten ob dies stabil ist und die Ergebnisse auch wirklich immer stimmen, denn es ist ja Intels lib und Intel wäre schuld wenn dem nicht so ist.

Also Holt, ich schätze deine Expertise sehr, aber das was du hier verzapfst ist schon ziemlich hanebüchen.
Das Ergebnis von SIMD Integeroperationen ist auf allen Plattformen natürlich identisch. Wären sie es nicht dann hat man a) einen Softwarefehler der auf den getesteten Plattformen halt nicht aufgetreten ist (undefined behaviour) oder b) einen Hardwarebug.

a) sollte natürlich nicht auftreten, aber auf jeden Fall gefixt werden, da das bei zukünftigen eigenen CPU Generationen ebenso zu Fehlern führen kann
b) ist ein Problem des Hardwareherstellers.

Der Zusatzaufwand ist in der Praxis also 0,0 weil man davon ausgeht, dass die Software frei von undefiniertem Verhalten ist und das die Hardware das ausrechnet was man von ihr will.

Bleibt noch die Rundungsproblematik bei floating point, aber die ist immer vorhanden, egal ob SIMD oder x64.

 

[Powl_0]

Es handelt sich hier aber nicht um eine allgemeine API, sondern um eine Bibliothek von Intel für Intel User. Der Zweck dieser Bibliothek ist, Intel Usern einen Mehrwert zu bieten. Daher ist für mich nicht ersichtlich warum AMD User auch diesen Mehrwert bekommen sollten.

Weil es hier komplett wurst is ob es um unbekannte CPU von AMD oder Intel ES oder sonstwas geht. Löst euch doch endlich von diesem AMD vs Intel Blödsinn.

Die Forderung ist hier nach anständigem Software Design. Wofür sind denn all die ISA Extension flags und Feature flags der CPUs da, wenn eine Lib dann nur stumpf die Vendor/Device ID abfragt? Das ist einfach richtig schlechtes Design. Sowas erwarte ich von einem Praktikanten, nicht von hochbezahlten Entwicklern.

Mir ist dabei komplett egal ob die Lib von Intel, AMD oder dem Edeka um die Ecke kommt.

Man kann den eigenen Kunden den Mehrwert bieten, ohne dafür die Software absichtlich schlechter zu entwickeln. Es gibt Jahrzehnte an Erfahrung, Standards, Patterns, Conventions etc die alle darauf abzielen, gute Software zu schreiben, die sich all dieser Dinge bedient und nicht auf krumme Mittel zurückgreifen muss.

 

[Salamimander]

Und alle Implementierungen sind garantiert immer fehlerfrei, träume weiter!

Na ich hoffe du benutzt keine Intel CPU, denn wer sagt dir, dass AMD64 richtig implementiert ist?