AMD APUs (Phoenix, Phoenix2, Dragon Range, Rembrandt, Cezanne, Renoir, van Gogh, Mendocino, Strix Point)

die ausschließlich den AVX-512-Pfad ohne Rückfall verwendet
Davon redet doch niemand!

Es geht darum, dass Intel sich mit der Effekthascherei bei den Kernzahlen von den Performance-Vorteilen dieser Technik abschneidet. Bei allen CPUs und in allen Kernen.
Ja und? Wen interessiert das? Es gibt in den Bibliotheken doch einen Rückfall auf "normales" AVX. Dann eben ohne die Performance-Vorteile von AVX-512. Es gibt viele CPUs, die kein performantes AVX-512 können. Und diejenigen, die tatsächlich auf die Performance von AVX-512 angewiesen sind, müssen sich eben die richtige CPU kaufen.
 
Wen das interessiert, ist wohl eine rhetorische Frage.... Am Ende kaufen die Anwender die schnellere CPU.
Ich denke aber auch, dass Intel das irgendwann wieder nachrüstet. Dem Scheduler sowas beizubringen, dürfte aber nicht so einfach sein (sonst hätten sie es gleich so umgesetzt).
 
Ja und? Wen interessiert das? Es gibt in den Bibliotheken doch einen Rückfall auf "normales" AVX. Dann eben ohne die Performance-Vorteile von AVX-512
Wenn die Kerne einen unterschiedlichen Funktionsumfang bieten, es aber von der Software nicht unterschiedlich behandelt werden kann dann ist ein theoretischer AVX-512 Support wertlos weil praktisch nicht nutzbar da es mit ziemlicher Sicherheit knallt sobald die Last von den Big- auf die little Cores wandert, da der ausgehandelte Befehlssatz auf einmal nicht mehr verfügbar ist und die Big Cores nur einen Bruchteil der Multicore Rechenleistung liefern. Eine Beschränkung auf diese wäre also ebenfalls praktisch wertlos.

Sowas bringt in der Praxis viel mehr Ärger als Nutzen weshalb so ein Szenario wohl auch gemieden wird.
 
Meinst du? Wenn sie in Bibliotheken verwendet werden, auf die die normale Software zurückgreift, nicht.

Ich dachte eigentlich, nach dem Rausschmiss von AVX-512 würde dessen Verwendung nachlassen, aber dem ist nicht so.
Was führt Dich zu der Annahme?
Selbst bei den deutlich verbreiteteren AVX/AVX2 Befehlssätzen hat es viele Jahre gedauert, bis es tatsächlich mal ein paar Anwendungen (keine Spezialfälle wie z.B. best. Boinc-Applikationen o.ä.) gab, die davon merklich profitierten.
Nochmal: Für Budget-CPUs ist das völlig irrelevant (wenn ich schneller Handbrake-codieren will kaufe ich mir keine billige CPU!)! Da gibt es nunmal erwiesenermaßen Vorteile des Intel-Big-Little-Designs (was nicht heißt, dass AMDs Ansatz hier schlechter sein muss!)...

Bei den teuren Varianten mag das durchaus anders aussehen (und ich denke auch, dass Intel den Support dafür irgendwann wahrscheinlich wieder zurückbringen wird)...
 
Bei den teuren Varianten mag das durchaus anders aussehen (und ich denke auch, dass Intel den Support dafür irgendwann wahrscheinlich wieder zurückbringen wird)...
Ich gehe davon aus das es langfristig für die E-Cores wie beim AVX Support (128 Bit) der 64 Bit FPU bei AMDs Kabini laufen wird. Der Code wird vom Decoder in entsprechende Häppchen zerlegt die die schmale FPU verdauen kann und dann in mehreren Durchläufen abgearbeitet.
Das ist zwar nicht allso performant aber sparsam.
 
Zuletzt bearbeitet:
AVX512 läuft mit dem PS3 Emulator RPCS3. Da ist der Ryzen 7000er absolut "King of the hill". Weißt nicht wie viele PS3-Games darin emuliert werden können.
 
AVX512 ist sinnlos in Desktop-CPUs. Ich sehe das wie Linus Torvalds und Intel anscheinend mittlerweile ebenso
"Aber Massenmarkt? Sie machen keine Wettervorhersage auf der CPU, die Sie gekauft haben." Viele der Aufgaben, die jetzt auf CPUs vektorisiert werden, seien ohnehin besser auf der GPU aufgehoben, wie die Verarbeitung von Bild und Videodaten.
Oder noch deutlicher:
„Ich hoffe, AVX512 stirbt einen qualvollen Tod, und dass Intel die echten Probleme behebt, anstatt zu versuchen, besondere Befehle zu erfinden, um anschließend in Benchmarks besser auszusehen.“ Mit diesen Worten beginnt Linus Torvald seine E-Mail.
E-Mail:
And AVX512 has real downsides. I'd much rather see that transistor budget used on other things that are much more relevant. Even if it's still FP math (in the GPU, rather than AVX512). Or just give me more cores (with good single-thread performance, but without the garbage like AVX512) like AMD did.
 
Hier gibt es einen ausführlichen Beitrag zu AVX512

Insbesondere bei low-end APU mit Zen4 ist es schon sinnvoll AVX512 einzusetzen, um den Verbrauch der CPU zu senken und dafür mehr elektrische Energie in die GPU zu bringen. Bspw. die "Steam-Deck" oder auch allerlei mobile Geräte.

Im Betrag gibt es einen Vergleich mit Icelake wo AVX512 ggü. AVX2/FMA um 23% zulegt. Also von 187fps auf 241fps. Das ist schon ordentlich.

Insgesamt bleibt AVX512 eine Nische und Tovalds hat natürlich recht, wenn er sagt mehr Cores für die CPU.

Immerhin hat AMD nun 16C/32T inkl. AVX512 für das mobile Segment eingeführt, löblich.
 
E-Mail:
And AVX512 has real downsides. I'd much rather see that transistor budget used on other things that are much more relevant. Even if it's still FP math (in the GPU, rather than AVX512). Or just give me more cores (with good single-thread performance, but without the garbage like AVX512) like AMD did.

Das ist aber ne Lesekompetenzübung, oder? ;)

Denn er bezieht sich ja auf "More Cores, like AMD did".
 
Hier gibt es einen ausführlichen Beitrag zu AVX512

Insbesondere bei low-end APU mit Zen4 ist es schon sinnvoll AVX512 einzusetzen, um den Verbrauch der CPU zu senken und dafür mehr elektrische Energie in die GPU zu bringen. Bspw. die "Steam-Deck" oder auch allerlei mobile Geräte.
Absoluter Unfug. Vektorisierung im Lowend auf der CPU zu betreiben ist wohl das noch sinnloseste Szenario.
Aus deinem Link:
The Icelake tier AVX-512 target hits a ludicrous 235 FPS average, 23% faster than the AVX2/FMA target.
+23% Performance gegenüber AVX2 und das ganze in einem so speziellen Usecase wie dem PS3 Emulator.
Even when the target framerate is already achievable without AVX-512, enabling AVX-512 optimizations could improve battery life, or provide more TDP to the gpu which could enable gameplay at higher resolutions.
Wenn die CPU bei mehr Vektorlast die TDP mehr belastet, kann die GPU nicht mehr TDP zur Verfügung haben. Und alle bisherigen Benchmarks zeigen einen deutlichen Mehrverbrauch bei Intel CPUs die AVX512 nutzen und deshalb auch niedrigere Taktraten.

Zen4 hat es als einzige CPU bisher geschafft diesen Tradoff zu neutralisieren:
Ebenso war der Stromverbrauch der CPU ähnlich, wenn die AVX-512-fähige Software ausgeführt wurde. Bei fast allen Tests waren die Ergebnisse von AVX2 und AVX-512 nahezu identisch. Zu den Ausnahmen gehörten die Intel oneDNN-und OpenVINO-Software, bei der die AVX-512-Nutzung zu einer Steigerung von 10 bis 20 Watt für den Ryzen 9 7950X führte, aber der Rest der Zeit tendenziell fast die gleichen Ergebnisse lieferte.

Während dieser anspruchsvollen Arbeitslasten und sogar mit dem Cooler Master wird der ML280 ziemlich warm, zumindest wie vom Linux k10temp-Treiber gemeldet. AMD hat detailliert erklärt, dass der Betrieb bei einer TJMax von 95 Grad Celsius für die Teile mit höherer Kernzahl nicht überraschend und „beabsichtigt und konstruktionsbedingt“ ist, da dies eine maximale sichere Betriebstemperatur ist und effektiv gehandhabt wird. Jedenfalls hatte der Einsatz von AVX-512 zu keiner merklichen Erhöhung der CPU-Temperatur geführt. AMD gibt typische Lasttemperaturen für die Ryzen 7000-Serie mit 70 bis 90 Grad Celsius an.

Im Durchschnitt der getesteten AVX-512-Workloads führte die Verwendung der AVX-512-Anweisungen zu einer um etwa 59 % höheren Leistung im Vergleich bei künstlicher Begrenzung des Ryzen 9 7950X auf AVX2/kein AVX512.
AVX512 ist keine Perspektive um in Zukunft TDP bei der CPU einzusparen. Die selben Workloads sind auf einer GPU um einiges schneller für weniger Strom. Diese ganzen Mehrleistungen für die nächste Generation CPU sind immer noch weit weg von schnell, verglichen mit Vektor-Workloads auf GPU.
Siehe: https://www.anandtech.com/show/14466/intel-xeon-cascade-lake-vs-nvidia-turing/14
Using AVX-512 boosts performance in this benchmark by 46%. But again, this software runs so much faster on a GPU, which is of course understandable. At best, the Xeon has 28 cores running at 2.3 GHz. Each cycle 32 single precision floating operations can be done. All in all, the Xeon can do 2 TFLOPs (2.3 G*28*32). So a dual Xeon setup can do 4 TFLOPs at the most. The Titan RTX, on the other hand, can do 16 TFLOPs, or 4 times as much. The end result is that NAMD runs 3 times faster on the Titan than on the dual Intel Xeon.
Also die CPUs mit AVX512 sind schneller als mit AVX2 und dabei immer noch 3x langsamer als auf einer GPU unterwegs mit einem Dual-CPU Setup, was 6x mal langsamer als eine Titan RTX, verglichen 1:1 mit einer CPU, ist.
Mit dem Hinweis: Performance is markedly improved when running on Pascal (P100) or newer CUDA-capable GPUs.
Also was soll der Kram lösen, was nicht schon längst besser gelöst ist?

Edit: Ich denke das runter rechnen von 28 Kernen des Xeons auf eine Lowend 4-Kern CPU (1/6) und das runter rechnen der Titan RTX auf 1/36 Leistung spricht dafür, dass Low-Level GPUs jeden 4-Kern hinter sich lassen.

@pipin
Worin sollte die Übung bestehen? Ich habe lediglich das letzte fett markiert wegen "like AMD did". Lieber mehr Kerne anstatt die Fläche für weitere AVX Erweiterungen verschwenden, ist genau was ich meine. Intel hat da noch einiges aufzuholen was Kernzahl angeht.
 
Zuletzt bearbeitet:
Die nach eigener Aussage in einer "grumpy" Stimmung geschriebene E-Mail von Linus Torvalds ist jetzt drei Jahre alt. Logischerweise basiert sie auf der damaligen Hardware.

Und alle bisherigen Benchmarks zeigen einen deutlichen Mehrverbrauch bei Intel CPUs die AVX512 nutzen und deshalb auch niedrigere Taktraten.
Wenn eine neue Technik mit bedeutsamen Nachteilen daher kommt, entwickelt sie natürlich einen schlechten Ruf. Das liegt aber nicht am Befehlssatz selbst, sondern an Intels schlechter Implementierung. Interessanterweise schafft es AMD nicht nur, mit dem gleichen Stromverbrauch auszukommen wie ohne AVX-512. Sie legen dabei auch (relativ) um 50 % stärker zu als Intel, obwohl jene sich einen "größeren Schluck aus der Pulle" nehmen mussten. Dazu kam, dass Intel mal wieder ihre kleinteilige "Exklusivität" durchdrücken wollte, je nachdem, wie viel man bezahlt ("du kriegst es, du kriegst es nicht"). Sowas nervt.

Stand heute geht es darum, kostenlose Vorteile (zumindest bei AMD) "mitzunehmen". Auch wenn die GPU-Nutzung vorankommt, sind wir ja wohl noch nicht so weit, dass das "einfach so" bei allen drei Grafikchip-Anbietern funktionieren würde. Ob man die CPU-Chipfläche lieber anders hätte nutzen sollen, können die Chipentwickler vermutlich besser beantworten.

PS: Auf Leute, die traditionell unangenehm und anstrengend rüber kommen, was in diesem Fall an der Kombination aus "speziellem" Tonfall und eigener Unwissenheit liegt, gehe ich nicht weiter ein.
 
Zuletzt bearbeitet:
Das Argument lasse ich nicht zählen, dass Chipentwickler es besser wissen.
Der größte Nutzen für Intel die ganzen Vektor-Instruktionen in die CPU zu integrieren liegt darin die x86-64 ISA aufzublähen und auf diese Weise die Einschränkungen und Hürden für Konkurrenz um 25 Jahre zu verlängern, bis die Patente frei werden. Das regelmäßige zufügen von Iterativen Vektorbefehlen, die in weit verbreitetem C++ geschrieben werden hindert den Zufluss von Entwicklern in exotischere GPGPU-Sprachen. CUDA und RocM werden als Exoten gesehen, die man sich sparen kann, je mehr Basis-Vektorbefehle auf der CPU laufen. Das opfern von CPU Kernen für Diefläche und Powerbudget ist für die Kunden der schlechtere Deal, sichert Intel aber mehr Marktanteile auf mittlere Sicht. Bis AMD eben da steil vorbei gezogen ist mit den Core-Counts. Das ist keine Entwickler-Entscheidung, sondern eine strategische zur x86 Lizenz-Sicherung/Aufwertung.

AMD hat eine eleganten Weg gefunden mit seiner DoublePump Technik das Checkfeature AVX512 zu bieten und dann auch noch Intels eigene Implementation schlecht da stehen zu lassen. Ich glaube das war der Kick über die Klippe für AVX512 und Intel wird diese Transistoren dringender für anderes benötigen um nicht vollends ins Hintertreffen zu geraten. Für mehr Kerne muss Intel seine Infinity Fabric finden und dafür Transistoren und Powerbudget auf dem Die einsetzen.
 
@Complicated

Im mobilen Bereich wird AVX512 schon noch gebraucht werden, weil viele leichte Geräte keine diskrete GPU haben, sondern als APU bzw. iGPU erscheinen.

Das gleiche gilt für bspw. Steam-Deck und andere Handhelds. Da das Powerbudged beschränkt ist, ist das Plus an Leistung schon ganz gut. Wieviel dabei rauskommt, bleibt abzuwarten.

AVX512 bringt auf Zen4 auf jeden Fall nach vorne und nicht alle Anwendungen sind auf GPUs schneller.
 
Tja, wenn hier NIEMAND solche Spezialanwendungen wie Videos gucken, Bilder speichern oder Verschlüsselung benutzt, dann halt nicht....
[... Denkt doch mal einer an die Kinder, äh, die Steuersoftware ....]

Was die Desktop-APUs betrifft, enthalten die Gigabyte-Leaks vom letzten Jahr eine Tabelle, wonach auch im Sockel AM5 Rembrandt- UND Phoenix-APUs Platz nehmen werden. Entweder mit der Aufteilung in billiger / hochwertiger, oder (hoffentlich nicht) Rembrandt dieses Jahr und Phoenix nächstes Jahr. Es sollte doch möglich sein, APUs, die wie sonst auch auf der CES vorgestellt wurden, bis zum Sommer in den Desktop zu bringen?
 
Zuletzt bearbeitet:
Tja, wenn hier NIEMAND solche Spezialanwendungen wie Videos gucken, Bilder speichern oder Verschlüsselung benutzt, dann halt nicht....
[... Denkt doch mal einer an die Kinder, äh, die Steuersoftware ....]
Die benutzen alle AVX 512?!
Und sind dadurch so viel schneller und sparsamer?

Für den absolut größten Teil der CPU-Käufer (gerade auch der günstigeren) spielt das keine Rolle:
Die spielen auch aktuelle Videos in 4K ruckelfrei ab, ohne dabei am Anschlag zu laufen, verschlüsseln schnell genug für gängige Internetleitungen (ebgesehen davon gibt es für Verschlüsselung sogar nochmal eigene hochoptimierte Schaltungen), und Bilder speichern sie für die meisten auch schnell genug - und Fotografen kaufen sich wahrscheinlich eh wieder schnellere CPUs...

Es geht nicht darum, dass das "niemand" nutzt - die Zielgruppe ist entscheidend!
 
Es gibt auch schneller oder sparsamer, letzteres wenn nur eine begrenzte Rechenleistung von den CPU Kernen gefordert wird.
Das ändert aber nichts daran das es von der Software unterstützt werden muss und man sich bei der Desktop Software normalerweise einen feuchten Dreck drum schert solange es die halbwegs aktuellen Modelle des Marktführers nicht unterstützen.
 
Um Dinge wie "Video abspielen" kümmert sich keine Software selbst, das macht eine Bibliothek. Wenn diese auch AVX-512 nutzt, nutzt die Software das (spätestens nach dem nächsten version bump der Bibliothek) automatisch mit.
 
Zuletzt bearbeitet:

Da sind mal konkrete Werte zu sehen. Was daran klar wird ist, dass die Effizienz bei L1 und L2 Zugriffen steigen kann in Mobile für Intel - mit Zugriffen auf den L3 ist dieser dann aber auch nicht mehr gegeben. Hier ist AMD schon besser aufgestellt mit anderen Technologien:
In core private caches, we’re splitting hairs. Kaby Lake needs about 9.8% more power per bit in L1, and about 2.2% less in L2. But this is still a win for AVX-512, because Rocket Lake is able to get more than twice as much bandwidth out of L1 and L2 at roughly the same energy efficiency. In L3, AVX-512 doesn’t matter anymore. AVX is enough to max out L3 bandwidth, so Rocket Lake isn’t getting any “race to sleep” benefits. Also, Rocket Lake has a longer ring bus and more L3 capacity, which would increase power consumption and hurt its energy efficiency.
But in L3, Intel’s new mesh setup is a letdown. Bandwidth is nothing to write home about, and we’re seeing 80 pJ used per bit of data shortly after spilling out of L2. L3 performance also isn’t a redeeming factor. We see just 138.72 GB/s with 8 MB of data across all four threads. For comparison, four Zen 3 cores in the 5950X can get 438 GB/s out of L3 with the same amount of data in play, while using less than half as much energy per bit.
 
Zuletzt bearbeitet:
@pipin
Worin sollte die Übung bestehen? Ich habe lediglich das letzte fett markiert wegen "like AMD did". Lieber mehr Kerne anstatt die Fläche für weitere AVX Erweiterungen verschwenden, ist genau was ich meine. Intel hat da noch einiges aufzuholen was Kernzahl angeht.
Ja, aber das vor der Klammer - die man mal auf die Schnelle vielleicht überliest - halt auch. Und seine Aussage ist halt schon was älter.

Ich bin beim Thema aber auch etwas gespalten.

Die Frage ist halt, was die Tradeoffs sind.
AMDs Ansatz ist halt charmanter, da er nicht soviel Energie frisst.

Die Frage ist halt, hätte man mit der Chipfläche besser was anderes machen sollen oder ist das Ganze für "normale" Desktopprozessoren so vernachlässigbar,
dass man lieber nen eigenen Compute-Die dafür kreiert hätte.

Das ist meines Erachtens auch das Spannende bei AMD in der nächsten Zeit. Wird man weiter auf wenige Dies setzen, die man über fast das Ganze Produktportfolio einsetzen kann oder geht man doch irgendwann einen leicht anderen Weg.

PS: Auf Leute, die traditionell unangenehm und anstrengend rüber kommen, was in diesem Fall an der Kombination aus "speziellem" Tonfall und eigener Unwissenheit liegt, gehe ich nicht weiter ein.

Gemach. Hier wird immer noch sehr ruhig diskutiert in Gegensatz zu Teilen des WWW da draußen und ich bin ja froh, dass ihr alle hier so aktiv seid.
 
Ich glaube er meinte Linus ;)
 
Asus bringt das Asus ROG Ally.

Wohl mit sieben Zoll 16:9-Display (500 nits + 120 Hz) haben. AMD Custom APU 4nm Zen-4-CPU mit RDNA 3.
Soll doppelt so schnell sein, wie das Steam Deck.


Test mit einem Engineering-Sample:

 
Zuletzt bearbeitet:
ASRock Industrial hat jetzt Barebones mit Rembrandt Refresh (4,6 oder 8 Kerne) und 2x USB 4.0 im Angebot:

Die Geräte lassen sich im BIOS mit einer Target-TDP von 28 oder 42 W konfigurieren, wobei mit dem aktuellen BIOS-Fehler kaum jemand auf 42 W umschalten wird: der Lüfter würde dann ständig laufen.

Dazu gibt es Reviews von Tweaktown und Anandtech:
 
Zuletzt bearbeitet:
Zurück
Oben Unten