Intel nach neuen HPC-Benchmarkvergleichen in der Kritik (Update)

AVX512 ist noch neu und wird künftig noch weiter verbreitet werden, sowohl was die Nutzung als auch die Unterstützung durch die CPUs angeht und auch AMD wird sicher mit einer AVX512 Unterstützung nachziehen. Gerade im HPC (High Performance Computing) ist AVX512 aber durchaus schon verbreitet, da geht es eben darum das Maximum rauszuholen und die SW ist auch nicht unbedingt von der Stange. Aber es begreifen offenbar viele hier nicht, dass der Benchmark um den es geht, eben ein HPC Benchmark ist und verwechseln das mit ihren Desktopanwendungen, der Tellerrand ist für manche eben zu hoch.
"wird künftig" ... "wird sicher" ... "durchaus"

Für den kleinen Tellerrand anderer bist du aber ganz schön hypothetisch - wirfst also mit Theorien um dich, um dann dadurch andere herabsetzen zu können.

Erbärmliche Diskussionskultur.

Erstaunlich ist, dass gerade Cloud-Anbieter mehr und mehr auf HPC-Technik setzen - und zu AMD abwandern.

AWS | High Performance Computing (HPC) - Cloud Computing
AMD and AWS
AMD EPYC processors come to Google—and to Google Cloud | Google Cloud Blog

Da diskutiert wohl Holt mit sich allein. Die BigPlayer in dem Geschäft wandern nach und nach zu AMD. Ohne AVX512. Scheint also keine so großen Vorteile zu bieten, wie uns Holt hier schönreden möchte.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
"wird künftig" ... "wird sicher" ... "durchaus"

Für den kleinen Tellerrand anderer bist du aber ganz schön hypothetisch - wirfst also mit Theorien um dich, um dann dadurch andere herabsetzen zu können.
Im klassischen HPC übersetzt man die Programme mit dem mitgelieferten Compiler und nutzt BLAS und LAPACK für die Berechnungen. BLAS und LAPACK lassen sich einfach beim Linken durch optimierte Versionen vom Systemhersteller ersetzen (Intel MKL; AMD Blis), und man bekommt so einen kostenlosen Speedup ohne weiteren Einsatz. Der restliche Code nutzt üblicherweise OpenMP und/oder MPI, und skaliert darüber auch auf allen Kernen. Üblich ist es keine inline Codes für SSE, AVX, etc. zu verwenden, weil diese nicht portabel sind. Allerdings setzen die Compiler selbst den passenden Code ein, wenn man den eigenen Programmcode so schreibt, dass der Compiler seinen Autovektorisierer arbeiten kann ggf. muss man partielles loop unrolling machen.

Die BigPlayer in dem Geschäft wandern nach und nach zu AMD. Ohne AVX512. Scheint also keine so großen Vorteile zu bieten, wie uns Holt hier schönreden möchte.
Die Big Player kaufen Systeme, um eine Vielzahl an Anwendungen drauf laufen zu lassen, d.h. auch integerlastige Anwendungen, und die laufen ohne Frage auf AMD Systemen schneller. Wer hingegen weiß, dass er Number Crunching mit Gleitkommazahlen macht, schaut sie die Sache anders an.
 
Zuletzt bearbeitet:
Und schaut vor allem auf die GPU-Beschleuniger, ob die die gleiche Aufgabe lösen können - nur eben schneller. ;)
GPU-Beschleuniger haben diverse Nachteile, das am häufigsten auftrettende Problem ist die sehr beschränkte RAM-Größe.
 
GPU-Beschleuniger haben diverse Nachteile, das am häufigsten auftrettende Problem ist die sehr beschränkte RAM-Größe.
Das zeigt nur das Paradoxon, in dem Intel festhängt.

Sie machen groß Werbung mit AVX512, aber keiner interessiert sich dafür.

Außer Holt natürlich.

Die anderen wissen um die Nachteile und wissen auch, dass AVX512 nur in Maschinen Sinn macht, die es unbedingt und ausschließlich benötigen. Und davon gibt es eben nicht genug. Deswegen rührt Intel dermaßen die AVX512-Werbetrommel.

Und von der GPU-Seite kommt auch Gegenwind. Und eine RTX8000 mit ihren 48GB hat trotz "RAM-Limit" eine brutale Geschwindigkeit bei wissenschaftlichen Berechnungen.
 
GPU-Beschleuniger haben diverse Nachteile, das am häufigsten auftrettende Problem ist die sehr beschränkte RAM-Größe.
Vor allem haben die GPU Beschleuniger den Nachteil das man die Daten zur GPU übertragen muss und von dort wieder zurück, was Zeit kostet, aber dies hatte ich schon erwähnt und es wundert mich nicht, dass der Typ dies einfach nicht wahrhaben möchte. Ich wetter der hat nie Leben eine Zeile Quellcode für GPUs geschrieben, sonst wäre ihm der nächste Nachteile nämlich auch sofort aufgefallen, denn während man AVX512 durch Compilerflags aktivieren kann, geht dies bei der GPU Programmierung nicht so einfach.

Beides hat seine Vor- und Nachteile und daher jeweils seine Existenzberechtigung, weshalb auch AMD sicher schon bald AVX512 implementieren wird, jede Wette!
 
@fortunes
Nicht um sonst möchte Intel im HPC GPU Bereich mitmischen!
Aber der Holt512 weiß das besser....
 
Das zeigt nur das Paradoxon, in dem Intel festhängt.

Sie machen groß Werbung mit AVX512, aber keiner interessiert sich dafür.
Das ist eindeutig falsch. Im HPC Umfeld ist AVX512 sehr wichtig. Allerdings hat Intel momentan das Problem, dass AMD sowohl bei der AVX2 Implementierung wie auch bei der Zahl der Cores deutlich besser geworden ist. D.h. wenn man die theoretische Leistungssteigerung von EPYC zu EPYC2 betrachtet, hat sich die Leistung vervierfacht. Einmal durch die Verdoppelung der Cores, einmal durch die bessere Implementation von AVX2, d.h. ein AVX2 Befehl pro Takt anstatt einen pro zwei Takte. Das bringt je Faktor zwei. Dadurch ist AMD nun im Bereich von Intel vorgestoßen. Da durch die höhere Corezahl AMD bei Integerrechnungen Vorteile hat, ist es unterm Strich zurzeit so, dass AMD das bessere Angebot macht. Allerdings muss man das ganze komplett durchrechnen. Hier im Forum wird gerne nur der CPU-Preis genommen, der ist aber nahezu unwichtig, weil man immer komplette Knoten benötigt. Braucht man viel RAM, spielt der CPU Preis faktisch keinerlei Rolle mehr.

Und von der GPU-Seite kommt auch Gegenwind. Und eine RTX8000 mit ihren 48GB hat trotz "RAM-Limit" eine brutale Geschwindigkeit bei wissenschaftlichen Berechnungen.
Eine RTX8000 ist extrem langsam bei HPC Rechnungen, man kann nur bestimmte HPC-Rechnungen darauf ausführen, die mit einfacher oder halber Genauigkeit laufen. Für etliche Problem bräuchte man aber QuadruplePrecision (128Bit), die gibt es aber bisher nur in Software für CPUs, wenn man einmal von den alten HP-PAs absieht, die QuadruplePrecision in Hardware rechnen konnten. Für DoublePrecision (das ist der Standard im HPC) muss man die nVidia GV100 nehmen. Wenn man das RAM Problem in Zusammenhang mit den GP100 bzw. GV100 verringern will, muss man zu einer POWER9 Maschine greifen, weil bei der es möglich ist die CPU und die GPU per NVLink zu koppeln und so deutlich mehr Bandbreite zwischen Hostspeicher und GPU-Speicher bekommt.

GV100 (NVLink) DP: 8,7TFlops; SP: 15,7TFlops; HF (ich habe keine Zahlen auf die schnelle gefunden, es müsste aber das doppelt der SP Leistung sein)
RTX8000 DP: 0,5TFlops; SP 16,3TFlops; HP 32,6TFlops

Nachtrag: Die RTX Karten sind im Gegensatz zu früher bei DP nicht verkrüppelt, die Karte haben nur sehr wenige DP Einheiten drauf.

- - - Updated - - -

@fortunes
Nicht um sonst möchte Intel im HPC GPU Bereich mitmischen!
Aber der Holt512 weiß das besser....
Nicht nur Intel denkt so.

- - - Updated - - -

Ich wetter der hat nie Leben eine Zeile Quellcode für GPUs geschrieben, sonst wäre ihm der nächste Nachteile nämlich auch sofort aufgefallen, denn während man AVX512 durch Compilerflags aktivieren kann, geht dies bei der GPU Programmierung nicht so einfach.
Man merkt in diesem im Forum stark an, dass die meisten keinerlei Erfahrung mit HPC Programmierung haben, und wohl mit Programmierung im allgemeinen auch nicht. Dazu wissen sie nicht wie man HPC-Knoten kauft, und überbewerten die CPU-Preise maßlos. Ich kann mich an ein Gespräch mit einem Admin aus einer Arbeitsgruppe eines MPIs erinnern, in dem dieser erklärte weshalb sie Quadsocket Opterons gekauft hatten, obwohl die damaligen Xeon E5 drastisch schneller gerechnet haben. Diese Gruppe machte Gensequenzierung und musste anschließend die Gene mit einer Datenbank abgleichen. Die Opterons konnten ausreichend RAM (1TB!) aufnehmen, so dass die komplette DB im RAM gecached werden konnte. Das lief dann trotz der deutlich langsameren AMD CPU Faktor 50 o.ä. schneller als auf den Xeon E5, weil in die nicht ausreichend RAM reinpaßte und die Festplatten zu langsam waren. Das sind aber so Dinge, die hier keiner verstehen will. Wichtig ist nur AMD gut, Intel schlecht.
 
Zuletzt bearbeitet:
Ein interessanter Artikel, mit diesem Patch müsste man mal neue Benchmarks machen.

Zitat: ( Mal die Übersetzung des Artikels. )

„MATLAB ist eine beliebte mathematische Computerumgebung, die von Ingenieurbüros, Universitäten und anderen Forschungseinrichtungen genutzt wird. Einige seiner Operationen können durchgeführt werden, um Intel MKL (Math Kernel Library) zu nutzen, die schlecht für AMD Ryzen-Prozessoren optimiert ist und bekanntlich langsam ist. Der Reddit-Benutzer Nedflanders1976 entwickelte eine Möglichkeit, die Leistung der Ryzen- und Ryzen-Threadripper-Prozessoren zwischen 20 und 300 Prozent wiederherzustellen, indem er MATLAB zwang, erweiterte Befehlssätze wie AVX2 zu verwenden. Standardmäßig fragt MKL die Hersteller-ID Ihres Prozessors ab, und wenn er etwas anderes als "GenuineIntel..." sieht, fällt sie auf SSE zurück und stellt einen erheblichen Leistungsnachteil für "AuthenticAMD" Ryzen-Prozessoren dar, die eine vollständige IA SSE4, AVX und AVX2-Implementierung haben.

Der Optimierungsprozess, der dazu gedacht ist, von AMD Ryzen-Benutzern manuell angewendet zu werden, zwingt MKL, AVX2 unabhängig vom Ergebnis der CPU-Anbieter-ID-Abfrage zu verwenden. Die Optimierung ist so einfach wie wirkungsvoll. Eine einfache 4-zeilige Windows-Batchdatei mit einer Reihe von Argumenten startet MKL im AVX2-Modus. Sie können die Anpassung auch "permanent" vornehmen, indem Sie eine Systemumgebungsvariable erstellen. Die Umgebungsvariable gilt für alle Instanzen von MATLAB und nicht nur für die, die durch die Batch-Datei erzeugt werden. Nedflanders1976 hat auch ein Benchmark-Skript veröffentlicht, das die Auswirkungen von AVX2 auf die Leistung hervorhebt, aber Sie können auch Ihre eigenen Skripte verwenden und Ergebnisse veröffentlichen.“

Übersetzt mit DeepL Translator

Quelle:
MATLAB MKL Codepath Tweak Boosts AMD Ryzen MKL Performance Significantly | TechPowerUp
 
Daran anschließend:

Und jetzt muss man bei Tests, insbesondere Intel, ganz genau hinschauen, ob Intel-Bibliotheken beim Compilen/Testen genutzt wurden. Denn nicht immer geht es fair zu.

Intel MKL: Workaround erhöht Leistung auf AMD Ryzen signifikant - ComputerBase

Bis zu 400% Mehrleistung auf AMD-CPUs - weil die Intel-Bibliothek eine Nicht-Intel-CPU erkannt und deswegen AVX(2) deaktiviert, stattdessen simples SSE zugelassen hat. Top!

Wen erinnert das noch an...
Does Intels compiler cripple AMD performance? - The Tech Report
 
Na ja bei Spielen interessiert das nicht oder sind da auch Beschränkungen versteckt welche CPU genutzt wird?
Das ist ein Problem bei wissenschaftlichen Berechnungen oder werden damit andere Programme und Anwendungen auch ausgebremst?

Solches Problem gab es ja schon früher mal. Hier mal was aus 2009.

https://www.agner.org/optimize/blog/read.php?i=49#49

Intel macht sich in letzter Zeit nicht viel Freunde, sollte so was auch in Gamecodes gefunden werden, müssten alle aber wirklich alle Benchmarks neu erstellt werden. Wie würde es dann mit dem Intel Vorsprung im Gaming aussehen.

Jetzt muss man so ziemlich jeden Benchmark unter Vorbehalt betrachten. Glaube das hier wird kein Sturm im Wasserglas, eher ein ausgewachsener Orkan.
 
Ein interessanter Artikel, mit diesem Patch müsste man mal neue Benchmarks machen.
Die Benchmarks aus der Original Meldung sind so aufgebaut, dass sie sich auf jeder Zielplattform aus Sourcecode übersetzen (mit dem Compiler und den Compilerflags der Wahl des CPU Herstellers!) und mit einer optimierten Version (die sollte auch vom CPU Hersteller kommen!) der BLAS und LAPACK nutzen kann. Die Intel MKL stellt BLAS, LAPACK und einiges mehr in einer für Intel CPUs hochoptimierten Version bereit. Wie der von Dir angeführte Artikel erläutert verwendet das kommerzielle Produkt Matlab fest verlinkte Versionen der MKL Library. Das ist nur dann ein Problem, wenn man auf einem Computer arbeitet. Wenn man auf Cluster geht, bekommt man mit Matlab ohnehin ein großes Problem, weil man für jeden Knoten eine Matlab Lizenz benötigen würde. Das kann man mit dem Matlab Compiler oder der Umstellung auf GNU Octave umgehen. Da GNU Octave FOSS ist, kann man es auch hochoptimiert für AMD CPUs übersetzen und binden.

- - - Updated - - -

Und jetzt muss man bei Tests, insbesondere Intel, ganz genau hinschauen, ob Intel-Bibliotheken beim Compilen/Testen genutzt wurden.
Das ist ein altbekanntes Problem. Die Liste an Problemen mit Intel Composer XE auf AMD Hardware ist lang. Das der VTune Amplifier nicht läuft, das kann man noch verstehen, weil Intel und AMD unterschiedliche Hardware in den CPUs integriert hat, um die Performance zu messen.
 
Daraus wollte ich noch mal zitieren, da die wenigsten hier bis so weit unten gelesen haben dürften:
Für den Einsatz in Supercomputern sind die Scalable Vector Extentions (SVE) gedacht, die zu zweit in jedem Rechenkern sitzen und ähnlich wie Intels AVX-512 512-Bit-Werte verarbeiten.

Man merkt in diesem im Forum stark an, dass die meisten keinerlei Erfahrung mit HPC Programmierung haben, und wohl mit Programmierung im allgemeinen auch nicht.
Ja und leider sind diese Leute sich trotzdem nicht zu schade dumme Kommentare wie es wäre nur die Dummheit oder Faulheit der Entwickler, wenn nicht alle Programme perfekt für ganz viele Kerne skalieren würden.
Wichtig ist nur AMD gut, Intel schlecht.
Das ist leider bei den meisten hier der Tenor, Sachlichkeit ist bei denen nicht gefragt und dann wundern sie sich am Ende, wieso so bei mir auf der Ignoreliste stehen, aber ich habe einfach keine Lust Zeit zu verschwenden um Leuten etwas beibringen zu wollen, die gar nicht lernwillig sind.

Ein interessanter Artikel, mit diesem Patch müsste man mal neue Benchmarks machen.
Das Thema ist uralt und von AMD gibt es die AMD Math Library (LibM). Die MKL wird von Intel auch klar als für Intel System beworben:
Für AMD gibt es die AMD Lib oder Alternativen wie OpenBLAS.

Die Intel MKL ist halt auf Intel Systemen viel schneller als z.B. OpenBLAS, während AMD Zen2 mit OpenBLAS eben schneller als mit der MKL ist:

Am Ende ist die Anleitung wie man OpenBLAS einbindet und das alles ist vom August, also rund 3 Monate alt.
 
Das Thema ist uralt und von AMD gibt es die AMD Math Library (LibM). Die MKL wird von Intel auch klar als für Intel System beworben: Für AMD gibt es die AMD Lib oder Alternativen wie OpenBLAS.

Die Intel MKL ist halt auf Intel Systemen viel schneller als z.B. OpenBLAS, während AMD Zen2 mit OpenBLAS eben schneller als mit der MKL ist:

Am Ende ist die Anleitung wie man OpenBLAS einbindet und das alles ist vom August, also rund 3 Monate alt.
Entweder willst du nicht verstehen oder stellst dich absichtlich blöd.

Intel hat nicht mehr gemacht, als eine Routine einzubauen, die auf Intel-CPUs prüft und bei Nicht-Vorhandensein die kompletten AVX-Befehlssätze deaktiviert.

Das hat nichts mit "auf Intel optimiert", sondern mit "ich benachteilige Konkurrenz bewusst" zu tun.

Wenn man jetzt hergehen und sagen würde "hey, die MKL arbeitet auf AMD schnell, aber OpenBLAS ist ca. 5% schneller" - ok. Aber das was hier abgeht, ist mal wieder Intels Trauerspiel, die Konkurrenz an allen Ecken und Ende zu behindern, wo es nur geht.

Intel hat seit 2005 nichts gelernt.
 
Entweder willst du nicht verstehen oder stellst dich absichtlich blöd.

Intel hat nicht mehr gemacht, als eine Routine einzubauen, die auf Intel-CPUs prüft und bei Nicht-Vorhandensein die kompletten AVX-Befehlssätze deaktiviert.

Das hat nichts mit "auf Intel optimiert", sondern mit "ich benachteilige Konkurrenz bewusst" zu tun.

Wenn man jetzt hergehen und sagen würde "hey, die MKL arbeitet auf AMD schnell, aber OpenBLAS ist ca. 5% schneller" - ok. Aber das was hier abgeht, ist mal wieder Intels Trauerspiel, die Konkurrenz an allen Ecken und Ende zu behindern, wo es nur geht.

Intel hat seit 2005 nichts gelernt.

Bullshit. Ich optimiere doch nix an meiner eigenen Library für die Konkurrenz, ohne zu wissen ob meine Library dann noch zuverlässige Ergebnisse liefert und nicht evtl. sogar crasht, was viel schlimmer ist als eine miese Performance.
Wenn sich AMD benachteiligt fühlt, können sie ja den Rechtsweg bestreiten, das "Problem", das hier wieder einige aufbauschen, scheint wohl schon länger bekannt zu sein, zumindest für die Leute die es wissen müssen, also keine Tastaturhelden im CB/HWLuxx.
 
Bullshit. Ich optimiere doch nix an meiner eigenen Library für die Konkurrenz, ohne zu wissen ob meine Library dann noch zuverlässige Ergebnisse liefert und nicht evtl. sogar crasht, was viel schlimmer ist als eine miese Performance.
Genau, ich baue eine Flag ein, die fremde CPUs von Befehlserweiterungen ausschließt, statt eine Warnmeldung zu bringen, dass keine Intel-CPU genutzt wird und es deswegen zu Problemen oder Leistungseinbußen kommen kann.

Eine Intel-"Optimierung" wäre es, wenn die Bibliothek nur noch mit AVX512 funktioniert. Dann hätte das Flag einen Sinn gemacht.

Oh wait, dann wären ja über 70% aller Intel-CPUs auf einen Schlag unbrauchbar gewesen.

"Optimierung" for my ***. Was soll denn da crashen.
 
Intel hat nicht mehr gemacht, als eine Routine einzubauen, die auf Intel-CPUs prüft und bei Nicht-Vorhandensein die kompletten AVX-Befehlssätze deaktiviert.

Das ist komplett falsch. Standardmäßig wird AVX und AVX2 von der Library nicht genutzt. Diese werden bei einer passenden CPU als zusätzliche Leistungsoptimierungen aktiviert. Nur prüft Intel halt nicht, was die CPU an Features unterstützt, sondern macht Intel dies anhand der CPUID fest. Bei deren Hardware wissen die eben, was unterstützt wird und was nicht. Bei anderen Herstellern kann dies nicht garantiert werden und diese werden von Intel auch gar nicht supportet. Die Library ist nur für die eignen CPUs gedacht.

Zudem ist der Workaround schon länger bekannt und nichts neues. Aber jetzt hat man wieder was, um ein Fass aufzumachen..
 
Zuletzt bearbeitet:
sch4kal
Wenn du als Tastaturheld anderen deine Eigenart vorwirfst, ist dies maximal beschämend.
Inwiefern wäre die Prüfung eines AVX Befehlsatzes eine Optimierung für die Konkurrezn? Diese Prüfung findet nämlich nicht statt.
Es gibt nur eine Prüfung, keine Intel CPU, also SSE Befehlsatz.

Wieso soll eine Library keine zuverlässigen Ergebnisse bringen oder abstürzen, wenn diese eine AVX Prüfung vorher macht?
Wieso soll dann diese Library keine zuverlässigen Ergebnisse bringen, oder abstürzen, wenn AVX Befehlsätze vorhanden sind?
Durch das Abkommen, welches AMD und Intel abgeschlossen haben, ist AVX bei beiden Hersteller eben AVX. Intel bietet nur eine noch höhere Beschleunigung, deren Nutzen aktuell unbedeutend ist. Trotzdem bleibt AVX eben AVX. Ob nun AVX, oder AVX2, oder AVX512. Wieso soll laut deiner Expertise des Tastaturheldes nun eine Library abstürzen, oder keine zuverlässigen Ergebnisse bringen?
 
Es gibt nur eine Prüfung, keine Intel CPU, also SSE Befehlsatz.

Die CPUID liefert neben der Vendor ID noch weitere Informationen (u.a. Familie und Model) über eine CPU. Intel kann daran die CPU genau einordnen und weiß dann welche Features von der jeweiligen CPU unterstützt werden, zum Beispiel wird dann nur AVX-512 genutzt, wenn die CPU das auch unterstützt.

CPUID – Thomas-Krenn-Wiki


Intel bietet nur eine noch höhere Beschleunigung, deren Nutzen aktuell unbedeutend ist. Trotzdem bleibt AVX eben AVX. Ob nun AVX, oder AVX2, oder AVX512. Wieso soll laut deiner Expertise des Tastaturheldes nun eine Library abstürzen, oder keine zuverlässigen Ergebnisse bringen?

Dir ist aber schon bewusst, dass bei den Schritten AVX -> AVX2 -> AVX512 nicht nur die Register aufgebohrt wurden, sondern auch neue Instruktionen hinzugefügt wurden?
 
Dir ist aber schon bewusst, dass bei den Schritten AVX -> AVX2 -> AVX512 nicht nur die Register aufgebohrt wurden, sondern auch neue Instruktionen hinzugefügt wurden?

Wird's ihm nicht, sowas lässt man natürlich immer gerne unter den Tisch fallen, neben der Erwähnung der Bedeutungslosigkeit des gesamten AVX512 IA-Satzes.
Die Zitatfunktion der Forensoftware kennt er ja schließlich ebenso wenig ;)
 
Die CPUID liefert neben der Vendor ID noch weitere Informationen (u.a. Familie und Model) über eine CPU. Intel kann daran die CPU genau einordnen und weiß dann welche Features von der jeweiligen CPU unterstützt werden, zum Beispiel wird dann nur AVX-512 genutzt, wenn die CPU das auch unterstützt.
Und wenn die CPU nur AVX unterstützt, wird eben AVX genutzt, anstatt AVX512. Warum soll es dann zu unzuverlässigen Ergebnissen kommen, oder zu Abstürzen?
Denn AVX ist sowohl bei Intel, als auch bei AMD gleich. AVX2 ist sowohl bei Intel, als auch bei AMD gleich. Nicht jede Intel CPU bietet alle AVX Befehlsätze.
Dir ist aber schon bewusst, dass bei den Schritten AVX -> AVX2 -> AVX512 nicht nur die Register aufgebohrt wurden, sondern auch neue Instruktionen hinzugefügt wurden?
Dies gilt sowohl für Intel CPUs, als auch für AMD CPUs. Nochmal, nicht jede Intel CPU bietet AVX, AVX2, AVX512. Dies gilt auch für AMD CPUs. Denn Intel AVX ist auch AMD AVX und umgekehrt.
Warum soll es dann zu Unzuverlässigkeiten und oder Abstürzen kommen?

Da du zwar meinen Kommentar zitiert hast, diese Fragen von mir nicht beantwortet hast, gehe ich davon aus, dass du nicht diese behaupteten Szenarien von sch4kal einem Fakt näher bringen kannst. Im Gegenteil, weder kannst du diese bestätigen, noch verneinen. Also auch nur so wie sch4kal schrieb, ein Tastaturheld, wie wir alle, einschließlich sch4kal.

Nachtrag:
sch4kal
Warum ist es dir nicht möglich die Fragen zu beantworten?
 
Zuletzt bearbeitet:
Warum soll es dann zu Unzuverlässigkeiten und oder Abstürzen kommen?

Wer garantiert, dass andere Hersteller sich an die Vorgaben halten und auch wirklich jede Instruktion zur Verfügung stellen?

Auch stimmt deine Behauptung nicht, dass AVX bei AMD und Intel gleich wären, denn gerade bei AVX2 gab es Unterschiede in der Hardware. Intel verbaut seit Haswell 256bit Register und AMD erst seit Zen2. Bei Zen hat AMD nur 128bit Register verbaut und dementsprechend werden für 256bit breite Befehle zwei von diesen 128bit Registern benötigt.
 
Das ist komplett falsch. Standardmäßig wird AVX und AVX2 von der Library nicht genutzt.
Du erzählst einen Schmarrn.

Natürlich können wir uns darüber streiten, ob es jetzt standardmäßig "an" oder "aus" ist. Das ändert aber nichts an der Tatsache, dass Intel AVX bei non-Intel-CPUIDs abschaltet oder abgeschaltet lässt.

Dabei ist AVX(1) seit SandyBridge & Bulldozer dabei. AVX2 seit Haswell und Excavator, also schon vor AMDs Zen!
 
Natürlich können wir uns darüber streiten, ob es jetzt standardmäßig "an" oder "aus" ist. Das ändert aber nichts an der Tatsache, dass Intel AVX bei non-Intel-CPUIDs abschaltet oder abgeschaltet lässt.

Darüber gibt es nichts zu streiten, da es ganz einfach ist. Es gibt neben dem möglichst kompatiblen Basisweg - wobei dies nicht einmal unbedingt SSE2 sein muss, das wurde einfach nur behauptet - noch weitere optimierte Wege. Diese Optimierungen und die daraus resultierenden Speedups werden durch die Verwendung von entsprechenden Instruktionen erzielt. Da es sich um einen Library von Intel für Intel CPUs handelt, mit keinerlei Gewährung von offiziellem Support für Hardware von anderen Herstellern, ist es relativ selbstverständlich, dass diese auch keine Optimierungen erfahren und dementsprechend über den Basisweg geschickt werden.
 
Ich kann bei deinen Ausreden nur mit dem Kopf schütteln.

AMD und Intel haben ein Abkommen über Patentaustausch.

Die AVX-, SSE- und weiteren Befehlssätze sind bei beiden Herstellern in Hardware identisch. Es gibt da nur ein "an" oder "aus", also "Haben" oder "nicht Haben". Die einzigen Vorteile können in der Architektur selbst begründet liegen, wie schnell die implementierten Befehlssätze abgearbeitet werden.

Das ist das gleiche Spiel wie DirectX bei Grafikkarten. Entweder die GPU unterstützt die DX11-Befehlssätze oder nicht.

Intel kann bei den Befehlssätzen nichts "optimieren". Und Intel hat lediglich die Befehlssätze abgeschaltet. Wenn die Optimierungen auf Intels Architektur dazu geführt hätten, dass die MKL gar nicht erst auf AMD lauffähig ist - ok.

Aber man hat einfach nur AVX deaktiviert. Das ist keine Optimierung, sondern ein simples "Abschalten".
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh