Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsIntel MKL: Workaround erhöht Leistung auf AMD Ryzen signifikant
Das verwenden eines bereits vorhandenen Code-paths für AVX2 hat nichts aber auch wirklich gar nichts mit optimieren zu tun weshalb der benannte abschnitt hier keinerlei Relevanz hat.
Also wenn man durch die Nutzung perfekt (optimal) auf eine CPU passende Befehlssätze den Durchsatz steigert, dann ist das kein Optimieren? Wird dir eine andere Version von duden.de angezeigt als mir oder versuchst du gerade Teile der deutschen Sprache neu zu definieren?
Und wenn das Nutzen passender Codepfade keine Optimierung ist, dann ist es doch sowieso kein Problem, wenn AMD CPUs eben diese nicht optimierten Codepfade nicht nutzen können...
Es ist eine Optimierung, ja. Aber auf einen Befehlssatz, nicht auf eine spezielle CPU.
Wenn da spezielle Optimierungen in dem Pfad wären die Intel besser schmecken würde als AMD wär das was anderes. Aber den Pfad AMD komplett vorzuenthalten obwohl sie ihn ausführen können, das ist das Problem!
Also wenn man durch die Nutzung perfekt (optimal) auf eine CPU passende Befehlssätze den Durchsatz steigert, dann ist das kein Optimieren? Wird dir eine andere Version von duden.de angezeigt als mir oder versuchst du gerade Teile der deutschen Sprache neu zu definieren?
Und wenn das Nutzen passender Codepfade keine Optimierung ist, dann ist es doch sowieso kein Problem, wenn AMD CPUs eben diese nicht optimierten Codepfade nicht nutzen können...
1. Befehlssätze sind nicht auf Prozessoren optimiert sonder einfach nur definierte Standards für Prozessor Instruktionen
2. Habe ich langsam das Gefühl das du hier nur als Intel Troll unterwegs bist weshalb es für mich keinen sinn hat dir weiter etwas zu erklären das zu verstehen du nicht bereit bist denn ich werde hierfür schließlich nicht bezahlt ...
Es ist eine Optimierung, ja. Aber auf einen Befehlssatz, nicht auf eine spezielle CPU.
Wenn da spezielle Optimierungen in dem Pfad wären die Intel besser schmecken würde als AMD wär das was anderes. Aber den Pfad AMD komplett vorzuenthalten obwohl sie ihn ausführen können, das ist das Problem!
Ich sprach glaub nie von "eine CPU" sondern immer CPU Generationen. Genau danach unterscheidet die MKL ja auch wenn man sich mal deren Funktionen anschaut. Nicht Featuresets sondern Featurelevel anhand der CPU Generation.[2]
Ob AMD CPUs unter allen Umständen diese Codepfade problemlos nutzen können ist das was ich anzweifle. Ich würde halt nicht die Annahme treffen "läuft bestimmt" sondern "werde ich nicht ausliefern bevor ich es komplett getestet habe". Eben jenes Testing ist aufwendig und bedingt in der Regel Anpassungen [1]. Diesen Aufwand müsste Intel für die MKL leisten oder Mathlab. Intel kann man nicht dazu verdonnern den Aufwand für AMD zu betreiben und bei Matlab steigt der Aufwand eher noch, da sie eine Softwarelösung von Dritten (hier Intel) testen und gegebenenfalls anpassen müssen.
[1] Ich habe noch keine Intensive Testlandschaft gesehen, die bei solchen Änderungen keine Fehler aufzeigt
[2] Es gibt eine Funktion, die das Unterscheiden nach AVX Feature Level (AVX, AVX2, AVX512 inkl. div. Teilgrößen von AVX512) erlaubt. Die wird aber laut Doku vom Vendorcheck und bedingt durch den Check der CPU Generation überschrieben.
Ob AMD CPUs unter allen Umständen diese Codepfade problemlos nutzen können ist das was ich anzweifle.
...
[2] ... Die wird aber laut Doku vom Vendorcheck und bedingt durch den Check der CPU Generation überschrieben.
Alter, darum geht es doch. Es gibt eine Spezifikation von Intel. Einen Vertrag. Den erfüllt AMDs Implementierung! Da gibt es kein falsch rechnen, sonst würde Intel ebenfalls falsch rechnen.
Wie kommst du denn darauf AMD CPUs einfach mal zu unterstellen, sie haben Rechenfehler?
Es ist eine im Cross-Licence-Agreement von Intel lizenzierte Technologie. AMD dürfte nicht mal mit AVX werben wenn es da Fehler gäbe, da gibt es Zertifizierungen/TestSuites.
Woher kommt also deine Vermutung, AMD könnte falsch rechnen???
Es gibt nicht einen einzigen Anhaltspunkt dafür und AMD kann seit Jahren AVX, meinst du nicht, da wären Rechenfehler mal aufgefallen?
Und zu [2]. Genau das ist ja der Punkt, der aufregt! Aber irgendwie willst du das nicht verstehen!
1. MKL schaut: Ist CPU von Intel?
2. Wenn ja: Kann CPU AVX2, dann nutzen = sau schnell
3. Wenn nein: Langsamste Möglichkeit nehmen = schnarch
Und genau das ist die Schweinerei. Weil 1. gar nicht nötig wäre! Mann mann mann.
Ergänzung ()
Und das 1. ist da nicht aus Zufall reingeplumst. Irgendjemand hat das so aktiv entwickelt. Es werden also alle CPUs außer Intel aktiv benachteiligt. Verstehen?
Er will es einfach nicht verstehen, und spielt jetzt die Angstkarte. Solche Spielchen kenne ich sonst nur von (schlechten) Versicherungsvertretern. ((Selbst erlebt: "Was machen Sie denn, wenn Ihnen beim Rasen mähen ein Kieselstein weg fliegt und die Scheibe zertrümmert??"))
Einmal Gehaltsabrechnung vorzeigen, bitte.
Aahhhh, keine weiteren Fragen.
Alter, darum geht es doch. Es gibt eine Spezifikation von Intel. Einen Vertrag. Den erfüllt AMDs Implementierung! Da gibt es kein falsch rechnen, sonst würde Intel ebenfalls falsch rechnen.
Ich wiederhole mich... Intels MKL und Compiler unterscheiden CPU Generationen von Intel und machen daran Featuresets fest. Für AVX2 Code braucht es die Generation Haswell oder neuer. Dann geht aber Intels Software davon aus, dass die CPUs auch BMI 1/2 können. BMI 1/2 können aber nicht alle AMD CPUs die ebenfalls AVX2 können. Sprich, Intel Code der für Featurelevel Haswell oder neuer compiliert wurde kann Befehle enthalten, die einige AMD CPUs nicht interpretieren können.
Wie kommst du denn darauf AMD CPUs einfach mal zu unterstellen, sie haben Rechenfehler?
Und jaja, mir ist auch bekannt das Intel Errata hat und das die ganze Geschichte rund um Spectre scheiße ist. Ich gehe aber mal davon aus, dass Intel die eigenen Errata beachtet und auf eigenen CPUs testet.
Es ist eine im Cross-Licence-Agreement von Intel lizenzierte Technologie. AMD dürfte nicht mal mit AVX werben wenn es da Fehler gäbe, da gibt es Zertifizierungen/TestSuites.
1. x86 CPUs nutzen mehr als nur AVX
2. Es CPUs Bugs sind meist keine simplen Fehler. Da müssen meist bestimmte Zustände zur Laufzeit auftauchen, damit die Fehler geschehen. Es ist also durchaus möglich einen Tests für eine Spezifikation mit wehenden Fahnen zu schaffen, in realen Umgebung aber Bugs zu finden.
Woher kommt also deine Vermutung, AMD könnte falsch rechnen???
Wollen stimmt schon. Ich kann nicht wollen, dass wenn ich ein System für den Anwendungsfall X entwickle, dass dann irgendwer ankommt und sich beschwert, dass der Anwendungsfall G bei ihm nicht funktioniert hat.
1. MKL schaut: Ist CPU von Intel?
2. Wenn ja: Kann CPU AVX2, dann nutzen = sau schnell
3. Wenn nein: Langsamste Möglichkeit nehmen = schnarch
Und genau das ist die Schweinerei. Weil 1. gar nicht nötig wäre! Mann mann mann.
Genau das macht die MKL halt nicht. Es schaut eher so aus:
Code:
If vendor = intel then
if cpugen = haswell then
use math_haswell.dll
if cpugen= ivy
use math_ivy.dll
...
else
use math_sse2.dll
Damit landen div. Intel CPUs (Pentium4, Core(2), ...) auf dem use math_sse2.dll Pfad und nutzen den. Ebenso wie alle nicht Intel CPUs. Technisch ist das auch richtig, da math_haswell.dll mit march=haswell kompiliert wurde und die Kompatibilität nur mit dieser CPUgeneration getestet ist. Alles andere wäre einfach Fusch und privatwirtschaftlichen Unternehmen kann man halt nicht vorschreiben, dass sie das Ganze auch für die Konkurrenz erledigen müssen.
Ergänzung ()
Und das 1. ist da nicht aus Zufall reingeplumst. Irgendjemand hat das so aktiv entwickelt. Es werden also alle CPUs außer Intel aktiv benachteiligt. Verstehen?
Ich verstehe das keine Sorge, ich fabriziere gelegentlich Software . Was Intel an der Stelle macht ist aktiv für div. CPUgenerationen Optimierungen in die eigene Software zu implementieren und dies für den Wettbewerb nicht zu tun. Davon kann man halten was man will. Es ist aber KEINE aktive Benachteiligung von AMD. Das Intel das jedoch aktiv macht, ist das was bei vielen Nutzern im Forum anzukommen scheint. Entspricht aber nicht den Tatsachen.
Nur hat eine Abfrage nach dem Hersteller einer CPU nichts in dem Code zu suchen, wie schon 100x erläutert.
Und dann rennt Intel auch noch zu Legit Reviews und sagt, sie sollen doch mal MatLab testen. Weil das doch sooooooooo charakteristisch für moderne Software wäre.
Womit dann der eigentliche Zweck der ganzen Geschichte klar auf dem Tisch liegt.
Ziemlich peinlich.
Habe Zugriff auf Catia, NX und Solidworks durch die Uni. Wenn du mir sagst wie ich da was mit meinem 1800x testen soll, könnt ichs machen bei Gelegenheit.
Gut wäre es vor allem mal ne komplexe Baugruppe fem berechnen zu lassen.
Frage ist dann, ob jemand die gleiche baugruppe auf einem ähnlich starken Intel-pendant testen könnte und beide die zeitlichen Abläufe festhalten könnten.
Kleine Baugruppen eignen sich da leider eher weniger, außer man erhöht die Genauigkeit gegen unendlich.
Weil es damit nicht getan ist! Die Batch-Datei funktioniert nur mit AVX2-fähigen Prozessoren (Intel ab Haswell, AMD ab Excavator).
Piktogramm schrieb:
Und RDrand habe ich mir herausgesucht, weil das Erzeugen von gutem Zufall in hoher Geschwindigkeit durchaus ein Fall ist, der in der Mathematik gewünscht ist. Wobei das Erzeugen eines Seeds für den Pseudozufallsgenerator über RDrand schneller gehen dürfte als das Nutzen eines Seeds aus der Entropiequelle des Betriebssystems.
Schlechtes Beispiel. RDRAND ist eine Instruktion, die Anwendungen als Zufallsquelle tunlichst vermeiden sollten. Der Linux-Kernel etwa traut dieser Funktion standardmäßig nicht, kryptographisch sicheren Zufall zu erzeugen. Ordentlich programmierte Anwendungen nutzen daher die Funktionen des Betriebssystems, mit wenigen Ausnahmen bei denen ein besonderer dafür Grund vorhanden ist (z.B. systemd).
Die RDRAND-Probleme hat AMD übrigens mit BIOS-Updates behoben. Es ist wie bereits gesagt auch nicht Intels Aufgabe, auf AMD-Systemen zu testen. Wenn da irgendwo ein Bug sein sollte ist das an AMD, dort Abhilfe zu schaffen.
Piktogramm schrieb:
Ich gehe aber mal davon aus, dass Intel die eigenen Errata beachtet und auf eigenen CPUs testet.
Piktogramm fällt hier als jemand auf, der nüchtern argumentiert. Wenn jemand anderer Ansicht ist, kann er gerne dagegen argumentieren und die Argumente entkräften - so dass jeder, der das liest, sich ein eigenes Urteil bilden kann... es muss nicht zu einem abschließenden Konsens kommen... aber einige hier haben leider die Tendenz zu persönlichen Angriffen.
Was das Update deines Artikels betrifft... NumPy als grundlegende numerische Bibliothek wird von vielen anderen darauf aufbauenden wichtigen Bibliotheken verwendet, wie Pandas und SciPy - aber: im Gegensatz zu Matlab ist der Nutzer frei in seiner Wahl des Backends.
Sach mal... hier wird nirgends gefordert das Intel für AMD optimieren soll. Sie sollen nur nicht die von AMD unterstützten Featuresets (die sie ja auch auf ihren CPUs nutzen) brach liegen lassen mit ihren bescheuerten Abfragen.
Und jetzt soll auch noch AMD in Intels Code was ändern? Das dürfen die übrigens überhaupt nicht, Urheberrecht und so...
Habe ich das jetzt richtig verstanden? Intel hat LegitReviews vorgeschlagen mal die CPUs unter MATLAB zu benchen und wusste um die VendorID-Sache?
Musste gerade erst mal checken, ob es nicht ein CB_Retro-Artikel über K7/K8 ist, wo Intel ähnliches abgezogen hat >_>
Verstehe auch nicht die Probleme von einigen hier, den Sachverhalt zu begreifen. Man kann das Featureset einer jeden CPU auslesen, was Intel auch macht und dann die vorhandenen Features nutzt. Nur stellen sie vor diese Abfrage nochmal den Check, ob Intel-Hardware verbaut ist und überspringen anderweitige Checks - völlig unnötig an dieser Stelle.
Ob AMD CPUs unter allen Umständen diese Codepfade problemlos nutzen können ist das was ich anzweifle. Ich würde halt nicht die Annahme treffen "läuft bestimmt" sondern "werde ich nicht ausliefern bevor ich es komplett getestet habe". Eben jenes Testing ist aufwendig und bedingt in der Regel Anpassungen
Ich empfinde das aber nach wie vor für wenig überraschend, denn schlüssig erklärt warum x86-64 AVX2 Code auf Intel laufen, auf AMD aber nicht hast du noch immer nicht erklärt.
Ich würde halt nicht die Annahme treffen "läuft bestimmt" sondern "werde ich nicht ausliefern bevor ich es komplett getestet habe". Eben jenes Testing ist aufwendig und bedingt in der Regel Anpassungen
Wow, mit der Begründung kann Intel also komplett den Dienst auf einer AMD-CPU verweigern. Schließlich kann sich Intel nie 100%ig sicher sein, ob nicht auch die ALU/AGU-Implementierungen oder MOV bei AMD "richtig" implementiert sind. Wenn AMD sagt, sie unterstützen einen Befehl, dann ist das so. Falls AMD dann Probleme bei der Implementierung fest stellt, ist das ihr Problem.
Und kannst du einmal erklären, wo genau das Problem ist abgesehen von Matlab?
Ansonsten sieht es so aus:
Intel CPU -> MKL
AMD CPU -> Atlas, OpenBLAS oder bei EPYC -> AOCL
Davon abgesehen sind neuere Bibliotheken von Intel, wie mkl-dnn open source.
Ich sehe hier nur ein Problem mit Matlab und der Fehler liegt bei Mathworks, vor allem wenn bei den Systemanforderungen für 2019b steht, dass sowohl Intel als auch AMD mit AVX unterstützt wird -> bei den Lizenzkosten erwarte ich, dass das jeweils passende Backend ausgewählt wird.
Mal kurz meinen Senf dazu:
Intel unterscheidet nicht nach Generationen, sondern natürlich nach Featuresets (weil auch nicht alle CPUs einer Generation, die gleichen nutzen dürfen - sie kastrieren und segmentieren massiv innerhalb einer CPU Generation, das würde somit nicht funktionieren -> also müssen sie logischerweise auch über die Features segmentieren! Völlig normal, falls nicht, wäre das völlig bescheuert und unsicher (oder Absicht)
Selbst wenn, gäbe es keinen Grund AMD den Weg zu verwehren - niemand zwingt doch Intel irgendwas zu testen, wenn sie schon dazuschreiben, dass nur ihre CPUs supported werden.
Den schwarzen Peter hätte AMD, wenn Sachen auf ihren CPUs nicht funktionieren.
Ebenso betreibt Intel alleine schon mit dieser Abgrenzung aktiven Mehraufwand mit der Verhinderung der Ausführung - nicht umgekehrt.
Ebenso wenn argumentiert wird, dass Intel das für AMD testen müsse, dürften sie auch SSE2 nicht freigeben, oder eben gleich alle AMD verhindern - auch das könnten sie ja nicht garantieren auf Fehlerfreiheit
etc etc, einfach nur schwache mögliche Ausreden
Ich sprach glaub nie von "eine CPU" sondern immer CPU Generationen. Genau danach unterscheidet die MKL ja auch wenn man sich mal deren Funktionen anschaut. Nicht Featuresets sondern Featurelevel anhand der CPU Generation.[2]
Ob AMD CPUs unter allen Umständen diese Codepfade problemlos nutzen können ist das was ich anzweifle. Ich würde halt nicht die Annahme treffen "läuft bestimmt" sondern "werde ich nicht ausliefern bevor ich es komplett getestet habe". Eben jenes Testing ist aufwendig und bedingt in der Regel Anpassungen [1]. Diesen Aufwand müsste Intel für die MKL leisten oder Mathlab. Intel kann man nicht dazu verdonnern den Aufwand für AMD zu betreiben und bei Matlab steigt der Aufwand eher noch, da sie eine Softwarelösung von Dritten (hier Intel) testen und gegebenenfalls anpassen müssen.
So nochmal, Intel hat Befehlssatzerweiterungen für die x86 Architektur gemacht z.b. MMX od. AvX od. SSE diese sind Standards die gewisse Berechnungen beschleunigen, AMD hat diese in ihrer Partnerschaft Lizensiert (Intel hat z.b. die AMD64 also die 64Bit Erweiterung Lizensiert) und somit unterstützen Sie exakt die selben Befehlssatzerweiterungen, damit ist diese AVX Erweiterung exakt auf beiden CPUs gleich (außer es würde einen Bug in der CPU geben der nicht entdeckt worden ist).
Das bedeutet die MLK stellt Programmbibliotheken zurverfügung die diese "Erweiterungen" für das jeweilige Programm "nutzbar" machen, hier wurde demnach nichts "optimiert" sondern es wird lediglich die Befehlssatzerweiterung benutzt die die jeweilige CPU Gen unterstützt, ansonsten würde sich Intel nicht an ihre eigenen Standards halten ....
Somit ist das was intel macht nichts anderes als absichtliches „ausbremsen“ der Konkurrenz.
