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

[calluna]

Meiner Auffassung nach, dürfen sie den Pfad bei negativer Vendor ID Abfrage aber nicht "Blind" auf SSE2 setzen und sagen: Nach mir die Sintflut.
Das wäre dann wieder eine positive Entscheidung im Sinne von Benachteiligung.

Also für mich ist das "Untätigkeit", wenn alles, was bestimmten Kriterien nicht entspricht, in Default landet. ;-)

Jetzt einen Pfad für Zen einzubauen wäre geradezu dumm von Intel und ergibt keinen Sinn (weil Zen dann nicht benachteiligt werden darf), zumal es offensichtlich keiner extra Optimierungen für Zen bedarf.

@Ned Flanders ... ok, danke, werde ich mir durchlesen.

Ergänzung (28. September 2020)

es ist ein pdf, benenne es einfach um. da avx eine erfindung von intel ist, bekommst du die offizielle doku auch von denen.

Ok... das ist die Referenz in dem Dokument für Entwickler... deswegen wird AVX aber nicht zu einem genormten Standard.

 

[Neodar]

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.

Es geht hier aber nicht um Optimierungen, sondern um das gezielte Ausbremsen der Konkurrenz, indem die Software bei Einsatz einer AMD CPU anders operiert, als mit Intel CPU.
Das ist eine ganz andere Nummer.

 

[jonderson]

Am einfachsten ist es, wenn die Entwickler die CPU abfragen und dann die entsprechende Bibliothek verwenden...

Nein, am einfachsten wäre es, wenn die Entwickler einfach abfragen würden, ob die CPU die entsprechende Erweiterung beherrscht und wenn nicht den default Pfad benutzt.

Genau so hat man es früher auch gemacht...
Wo ist nur die gute alte Zeit hin, als man noch versucht hat mit guten Produkten zu überzeugen....

 

[TrueAzrael]

Dir scheint entgangen zu sein, dass Intel und Microsoft unterschiedliche Unternehmen sind, die z.B. beide eigene Compiler haben. Zu deren Compilern und auch zu der MKL gibt es Open Source Alternativen, ebenso wie auch zu MS Windows und Office, AMD hat sogar selbst eine Alternative zu MKL, pflegt und optimiert diese nur noch und auch bei Compilern hat AMD nicht gerade mit Ruhm bekleckert und mal diesen und mal jenen Open Source Compiler unterstützt, meist aber auch nur halbherzig.

So sehr ich deine Beiträge auch schätze, aber das klingt beinahe so als ob es keine marktbeherrschende Stellung geben kann so lange es auch nur eine Alternative gibt.
Nicht das ich mit der Aussage des von dir zitierten Posts übereinstimme, aber die Aussage von dir schlägt sich dann doch auf meinen Magen.

 

[SeppoE]

alternativ sie einfach genauso laufen zu lassen wie Intel CPUs auch.

Nur so als mögliche Erklärung (im Zweifel für den Angeklagten). Intel hält sich bei seiner Hardwareimplementierung nicht exakt an einen Standard und kann sich dafür Fehlerabfragen sparen. Wenn sie jetzt andere CPUs auch über diesen Pfad schicken, könnte es zu Fehlern kommen, die dann wieder auf Intelunf ihre lib zrückfallen. Dann würde ich den Pfad auch erst mal für NonIntel schließen. Wie gesagt, nur ein Erklärungsversuch mit einer nicht belegbaren These.

 

[jemandanders]

@calluna Ich denke, eine einfache Funktionsabfrage ohne extra Vendor ID würde reichen.
In die Beschreibung kommt dann noch ein Hinweis: Keine Gewähr bei Betrieb mit nicht Intel CPU und fertig.

Warum denn überhaupt die Vendor ID? Bei x86 sind die Funktionen doch standardisiert?
Ich könnte mir auch vorstellen, das Intel nun für seine CPUs noch einmal extra einzeln optimiert?, was sie für ZEN verständlicherweise nicht tun werden.

 

[jonderson]

Nur so als mögliche Erklärung (im Zweifel für den Angeklagten). Intel hält sich bei seiner Hardwareimplementierung nicht exakt an einen Standard und kann sich dafür Fehlerabfragen sparen. Wenn sie jetzt andere CPUs auch über diesen Pfad schicken, könnte es zu Fehlern kommen, die dann wieder auf Intelunf ihre lib zrückfallen. Dann würde ich den Pfad auch erst mal für NonIntel schließen. Wie gesagt, nur ein Erklärungsversuch mit einer nicht belegbaren These.

Wofür hat man denn Standards? Damit sich keiner daran hält? oO

 

[Salutos]

Wenn es die eigene Hardware nicht mehr hergibt, dann limitiert man den Wettbewerb mittels Software.
Ich nenne das armseelig.

 

[calluna]

In die Beschreibung kommt dann noch ein Hinweis: Keine Gewähr bei Betrieb mit nicht Intel CPU und fertig.

Du meinst also etwas wie das Folgende: (Zitat von der Produktseite zur MKL)

Supported Hardware

Intel® Xeon® processor
Intel® Core™ processor family
Intel Atom® processor
Intel® Xeon Phi™ processor

Und bei AMD auf der Produktseite für deren Bibliothek steht:

AOCL are a set of numerical libraries tuned specifically for AMD EPYCTM processor family.

 

[SeppoE]

mit guten Produkten zu überzeugen....

Das Produkt ist in dem Fall die Intel CPU in Verbindung mit dem eingepreisten Softwarepaket.

 

[jonderson]

Das Produkt ist in dem Fall die Intel CPU in Verbindung mit dem eingepreisten Softwarepaket.

Und genau diese Praxis darf sich nicht durchsetzen, denn es sorgt dafür, dass sich Monopole noch schneller etablieren können!
Das hat nichts mit gutem Produkt zu tun.

Auch deswegen gibt es eine genormte X86 Architektur mit standardisierten Erweiterungen.
Aber das gleiche Spiel kennen wir ja schon von Nvidia...

Aber:
Wie immer sind eigentlich auch die zu Blamen, die diese in ihren Produkten nutzen...

 

[DocWindows]

Warum denn überhaupt die Vendor ID? Bei x86 sind die Funktionen doch standardisiert?
Ich könnte mir auch vorstellen, das Intel nun für seine CPUs noch einmal extra einzeln optimiert?, was sie für ZEN verständlicherweise nicht tun werden.

Ein einfacher Blick auf die Produktseite erklärt doch alles

Intel® Math Kernel Library
The fastest and most-used math library for Intel®-based systems

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

Und die Supported Hardware hat @calluna ja schon aufgelistet.

Diese Bibliothek ist ein Intel Softwareprodukt für Kunden von Intel. Und nicht für Kunden eines anderen Prozessorherstellers. Das Zugeständnis dass es auch auf CPUs anderer Hersteller läuft dürfe auf eventuelle Wettbewerbsfragen zurückzuführen sein.

Es gibt eine ganz einfache Lösung für die meisten Anwendungsfälle der MKL diese Problematik zu umgehen: Umsatteln auf OpenBLAS.

 

[vander]

Ich sehe bei der MKL hauptsächlich die Nutzer der Bibliothek (z.B. Matlab) in der Pflicht. Inzwischen ist allgemein bekannt wie die MKL/Intel auf unterschiedliche Hardware reagiert.
Also entweder sie reagieren darauf, z.B. indem sie eine Alternative einbauen die andere CPUs nicht benachteiligt (was gab es da von AMD und anderen?) oder sie benachteiligen alle indem sie auf die MKL verzichten oder sie verzichten/benachteiligen Kunden denen AMD Support wichtig ist.
Hmm, könnte schwierig werden ... für AMD.

 

[jemandanders]

Du meinst also etwas wie das Folgende: (Zitat von der Produktseite zur MKL)

Aha.
Wenn das dort so steht, wäredas erstmal soweit in Ordung.
Dann läuft die Nutzung auf "Eigene Gefahr"
AMD und Intel haben aber auch ein Patent-Austauschabkommen. Von daher könnte man schon meinen, das die zueinander kompatibel sind.
Wie die weitere Rechtslage aussieht entzieht sich aber meine Kenntnis.

@DocWindows
Ich will hier ja nicht irgendwelche Rechte für AMD ausfechten.
Im Prinzip ist der Softwarehersteller dafür verantwortlich, das er die richtigen Bibliotheken nutzt.
Ich kann dir jetzt auch nicht sagen, seit wann das bei Intel SO da steht. Früher stand das da wohl auch mal anders?

 

[0x8100]

Ok... das ist die Referenz in dem Dokument für Entwickler... deswegen wird AVX aber nicht zu einem genormten Standard.

ich glaube, du hast eine falsche vorstellung von "genormten standards" in dem bereich. es gibt keine din, ansi oder itu, die prozessorerweiterungen spezifiert. es ist alles vendorspezifisch, x86 und avx kommt von intel, amd64 von amd - und von der jeweiligen firma bekommst du die specs. und wenn die öffentlich dokumentiert sind, hast du den jeweiligen standard.

 

[ruthi91]

Als Info: Mit rotgrün Sehschwäche Ist für mich die ~Hälfte der erstellten Diagramme und Balken nicht einem entsprechenden Prozessor zuordbar.
Könnte aber eh nicht glauben warum ein 5820K da noch so gut abschneiden sollte 😅

 

[Volkimann]

Ok... das ist die Referenz in dem Dokument für Entwickler... deswegen wird AVX aber nicht zu einem genormten Standard.

Also wenn Intel und AMD beide AVX anbieten, und sogar VIA mit ihrem Ableger Centaur einen x86 mit AVX 512 angekündigt hat, aber somit die wirklich einzig relevanten x86er Hersteller AVX nutzen und unterstützen durch Lizenzabkommen....

Wie genau ist dann Definition für AVX, wenn nicht Standard, wenn 99,99% der x86er Fertiger diesen Befehlssatz nutzen? 🤔

Oder ist AMD x86-64 auch kein Standard?

 

[Dragon0001]

Also man möchte Intel hier ja ungern böse Absicht unterstellen, aber einen "Fix" ein zu bauen der noch langsamer läuft kann keine ernst gemeinte Lösung sein, zumal sich die Ergebnisse doch sehr einfach überprüfen lassen.
Eine eigene Software generell nur für seine Produkte zu optimieren kann ich ja verstehen, aber extra einen Zen Kernel einbauen um die eigenen CPUs besser dastehen zu lassen ist schon ein wenig hart.

Es geht nicht darum, dass Intel nicht für AMD-CPUs optimiert, sondern darum, dass sie AMD-CPUs künstlich ausbremsen. Sie wenden also Zeit auf, um AMD absichtlich langsamer zu machen, sie "optimieren" ihre Software also dahingehend, dass die Konkurrenz darauf künstlich ausgebremst wird.

Wo bremst der Fix AMD aus? Die Teile, die bereits für AMD optimiert sind, funktionieren (laut Autor des Workarounds) offenbar sehr gut: "For instance, if we run the ACES dgemm benchmark with MKL 2020.2.254 on a Ryzen 3700X, performance is good: [...]A quick inspection with perf shows that most cycles are spent in a Zen-optimized kernel: "
Allerdings nutzen noch nicht alle Teile die Optimierungen (das "noch" stammt ebenfalls vom Autor des Workarounds).

 

[47cmArmumfang]

Was das hier wieder für Diskussionen sind, meine Güte. Nur, weil Intel eine Art Monopolstellung im Bereich x86-CPUs inne hat(te), heißt das nicht, dass ihre Lib nun sämtliche Konkurrenzhardware unterstützen oder gar darauf optimiert sein muss. Denn soweit ich weiß, gibt es genügend alternative Librarys, die genutzt werden können. Eine Monopolstellung in diesem Bereich ist schlicht nicht vorhanden. Daher unverständlich, wie die wettbewerbshassenden Nerds hier wieder irgendwas von Monopol faseln können. Das entbehrt jeglicher Grundlage.

AMD und Intel haben aber auch ein Patent-Austauschabkommen. Von daher könnte man schon meinen, das die zueinander kompatibel sind.

Also statt zu schauen, welche CPUs unterstützt werden, geht man als jemand, der diese Software vmtl. professionell einsetzt, einfach mal davon aus, dass alles unterstützt wird? Okay.

 

[Spandi]

@0x8100

Hast du auch einen lesbaren Link? Davon abgesehen, erwarte ich bei einer Norm keine Seite von Intel.

lol. warum darf intel keine normen definieren?