News Core Ultra 400D/400DX: Intels Geheimwaffen gegen Ryzen X3D

[latiose88]

Sollte das heißen das bei videoumwandeln weder der große l3 noch l4 Cache eine Rolle spielt. Naja und profitiere AMD bei ihren CPUs schon immer mehr als Intel von den besseren cl werten also von cl32 auf cl26 bei ddr5 bei AMD gegenuber Intel ? Und wenn der effektive Takt trotz Precision Boost Overdrive bei AMD +200 niedriger ist ,dann verpufft der Vorteil dabei oder ?
Dann gibt es nicht mehr viele Möglichkeiten mehr um richtig die Leistung zu steigern.

 

[Rollora]

1150 stammt noch aus der Phase gut begründeter Sockelwechsel. Sowohl der vorangehende 1155 als auch der nachfolgende 1151 hatten eine deutlich andere Stromversorgung

mea culpa, ich hab 1151 gemeint, bei dem ja theoretisch viele nachfolgende CPUs bis hinauf auf die 10 Kerner laufen hätte können.

Wenn du Bayern als nicht überheblich wahrnimmst, muss es wirklich subjektiv sein. Kenne keinen Verein der überheblicher ist und das schon mit Saisoneröffnung wo man kurzerhand das Double zur Pflicht erklärt. Auch abseits von Rolex Kalle und AngerManager UH.

meinung ist immer subjektiv.
Beim FCB ist sie historisch. DIe Leute haben prinzipiell ein Problem mit einem Serienmeister.
Aber ich kann durchaus unterscheiden, ob ein ganzer Verein überheblich rüberkommt, oder einzelne Personen. Und da scheint bei dir die Trennung nicht zu erfolgen
Und Ziele auszugeben ist nun schon überheblich... puh da sitzt irgendwo ein Stachel aber tief.
Ist dann auch DOrtmund, Leibzig und andere überheblich, weil sie den Titel als Ziel ausgeben? Nein, natürlich nicht, das gilt nur bei den Bayern.

Intel hat bis 2020 / 2021 schon so einiges gerissen um ihr Image der überheblichen schwerfälligen Konzernmutti zu pflegen; ähnlich bspw. VW in Deutschland.

ja was denn?

Nur war das damals auch weitestgehend so; heute denken die Firmen sich ja das lustigste aus um zu verkaufen. Intel bspw. hat glaube ich über vier Gens hinweg die gleiche CPU verkauft, nur immer unter neuerem Namen. Nerven tut das schon.

das findest du auch bei anderen Herstellern, auch AMD verkauft alte CPUs/GPUs gerne weiter. Refresh oder RElabel...

Nur werden sie damit vermutlich zwei preislich relevante CPUs liefern, die 52 Kern CPU wird niemanden interessieren, denn entweder brauchst du Kerne oder Cache, zu selten beides, als das es im Desktop Sinn geben könnte.

ich finde beides interessant
Ich brauch Kerne UND Cache

 

[MechUnit]

Das klingt spannend. Mal sehen, was da dann tatsäclich von Intel kommt, ob sie HT haben werden, wie die Benchmarks ausfallen und wie stromhungrig die CPU's werden.

 

[PCGH_Torsten]

Grundsätzlich ist das Prinzip Cache nicht so schwer. Man hält Dinge extrem schnell vor die sehr häufig und zeitkritisch genutzt werden.
Weil es nun technisch extrem "teuer" wäre schnelle große (L1)-Caches zu verbauen hat man mehrere "Level" eingerichtet - von extrem schnell aber sehr klein (L1) über sehr schnell und mittelgroß (L2) zu langsamer aber groß (L3) und manchmal auch noch langsam und riesig (L4) - danach kommt dann RAM.

Jedes Programm, egal ob Spiel oder was anderes, läuft beim abarbeiten von Befehlen sehr vereinfacht gesagt gleich: Lade Daten --> verarbeite Daten --> schreibe Daten (load, compute, store). Beim Lade Daten kommt der Cache ins Spiel: Die gewünschten Daten sind bestenfalls im L1 vorhanden und können sofort verarbeitet werden. Wenn die CPU sie im L1 nicht findet geht sind in den L2 suchen. Treffer? Dann kanns weiter gehen, wenn nicht... in den L3 suchen gehen und so weiter.

Wenn nun ein L3 Cache sehr groß ist (völlig egal ob Tile, 3D oder sonstwie) erhöht sich schlichtweg die Chance, dass das gesuchte Datenpaket da schon drin ist und nicht erst aus dem vergleichsweise elend langsamen RAM geholt werden muss. Auf technisch gesagt die Anzahl von Cache misses (Daten nicht im Cache die nötig sind) verkleinert sich.

Dass Spiele da oft besser skalieren als viele andere Programme liegt in der "unvorhersehbaren" Natur von Spielen. Wenn ich ein Video konvertiere sind die Befehle in der CPU immer die gleichen, was passiert gut vorhersehbar und entsprechend immer kontrolliert alles im Cache was gebraucht wird, auch in einem kleineren Cache. Bei Spielen weiß der PC nie, was in der nächsten Sekunde berechnet werden muss da alles "live" je nach Spielerverhalten erzeugt werden muss. Hier ist ein großer Cache Gold wert, da viele "Optionen" reinpassen und viel vorgeladen werden kann - und dadurch seltener die Situation eintritt dass der Spieler oder die Spielengine etwas machen was unvorhergesehen war und deswegen die nötigen Daten nicht im Cache sind.

"Optimieren" ist da so eine Sache - prinzipiell arbeitet jeder bessere Kompiler so, dass das oben beschriebene ausgeführt wird, sprich wenn eine CPU spontan 100 MB Cache mehr an Bord hat wird sie diese auch nutzen. Nur kann man übergeordnet auf Spielebene optimieren indem man zum beispiel festlegt, dass ein bestimmtes Asset eines Levels immer im Cache bleibt sofern der groß genug ist da zu erwarten ist dass es ständig benötigt wird. Wenn beispielsweise die Zustände aller Einzelbewohner in Anno, deren Verhalten bei jedem Spieltick aus diesen Zuständen ermittelt wird, alle in den Cache passen, wird das viel schneller sein als das immer im RAM zu parken. Deswegen skaliert sowas wenn gut programmiert extrem gut mit Cache.

Compiler oder Entwickler müssen nichts machen, damit Cache genutzt wird. Die Verwaltung desselbigen macht die CPU komplett in Eigenregie und Software-transparent. Selbst wenn man wollte, gibt es meinem Wissen nach keine Möglichkeit, bestimmte Inhalte im Cache vorrätig zu halten. Die einzige direkte Einflussmöglichkeit sind Cache-Flushes, bei der eine Software (i.d.R. aus Sicherheitsgründen) eine Leerung aller Caches befiehlt. Bei Hardware-naher Programmierung, also Optimierung auf einzelne Architekturen und Systeme, kann man seine Software natürlich an die Cache-Logik und -Größe anpassen. Der Extremfall wären sind die Rückkanäle bei Hacks wie Spectre, aber die müssen halt für jede Architekturvariation extra angepasst werden. Bei Spielen, die auf verschiedenen Systemen laufen, lohnt sich sowas dagegen nicht. Ein hypothetisch von 37 auf 34 MiB optimierter Engine Kerne läuft beispielsweise auf einer 36-MiB-CPU viel besser, aber dann kommt der nächste Anwender und installiert das Spiel auf einem 32-MiB-System.

Das wird häufig (leider) überschätzt. Das Ding ist, dass größerer Cache (in höheren Stufen) eine sehr ausgeprägte diminished returns Charakteristik hat. Wäre das nicht so hätten alle CPU-Hersteller schon lange Hunderte MB an Caches verbaut. Leider ist es so, dass die allermeisten Workloads nicht so arg viele ständig benötigte Daten verwenden und eher von sehr schnellen L1/l2 profitieren als von riesigen L3/L4, letzteres ist fast nur bei manchen Spielen der Fall - und entsprechend auf Plattformen wie unserer hier die sich viel damit beschäftigt overrated.

Die Kehrseite des ganzen ist: Cache (SRAM Zellen) benötigt viel Energie und Platz auf dem Die, ist also in jeder Hinsicht "teuer". Zusätzlich geht der Grenznutzen mit der Größe immer weiter gegen Null (ob ein L3/L4 Cache heute 100 oder 400 MiB groß ist macht in den allermeisten Fällen keinen Unterschied mehr). Daher ist das Mantra bei Cache nach wie vor "so viel wie nötig/nützlich, so wenig wie möglich". AMD hat mit ihrem X3D hier auch aus ihrer Marketingposition heraus strategisch eine Nische (Gaming) massiv bedient, für nahezu alles andere ist der große Cache oft völlig nutzlos. Dass Intel jetzt seinerseits einen bLLC bringt ist auch "nur" ein strategisches Konkurrenzprodukt um bei den Spielebenchmarks auch mal wieder einen setzen zu können für die sich vorher nicht wirklich interessiert wurde.

Der Energiebedarf von Cache ist sehr gering. AMDs X3D gehören sogar zu den relativ sparsameren Prozessoren, weil leichte CPU-Taktreduktionen zugunsten der Cache-Einbindung den Mehrverbrauch derselben überkompensieren, obwohl eine gigantische Menge aktiven Siliziums hinzukommt. Zählen tut daher in erster Linie Platz: Über die Hälfte eines normalen AMD-CCDs sind bereits Cache. Wollte man den monolithisch von 32 MiB auf 64 MiB verdoppeln und dafür andere Einheiten runterschmeißen, hätte man also einen 0-Kerner. Der ist garantiert nicht schneller. Für 400 MiB zusätzlichen SRAM müsste man locker fünfmal so viel Silizium einsetzen; das ist schlicht zu teuer. Stattdessen nimmt man eher DRAM-Chips dazu, Intels Xeon [CPU] Max hatten zum Beispiel 16 GiB HBM mit im Sockel, die auch als L4-Cache genutzt werden konnten. (Aber auch als zusätzlicher oder gar alleiniger Arbeitsspeicher.)

 

[Incredible Alk]

Der Energiebedarf von Cache ist sehr gering. AMDs X3D gehören sogar zu den relativ sparsameren Prozessoren, weil leichte CPU-Taktreduktionen zugunsten der Cache-Einbindung den Mehrverbrauch derselben überkompensieren, obwohl eine gigantische Menge aktiven Siliziums hinzukommt.

Ja, wenn der Cache die ganze CPU zu Undervolting zwingt um nicht draufzugehen machts das natürlich effizient - das ist aber ein nachgelagerter Effekt (der von AMD sicher nicht absichtlich gewählt wurde, was folgende Generationen bewiesen haben).
Dass SRAM an sich aber wenig Energie bräuchte wäre mir neu. Ich erinnere mich eher an Diskussionen, wie viel SRAM innerhalb eines limitierten Powerbudgets realistisch sind bevor die Kerne mit dem Takt runter müssen um das Powerlimit nicht zu sprengen.
Oder gibts da vielleicht große Unterschiede zwischen L1/L2 und großen höheren Stufen wie 3D oder Infinity-Cache?

Compiler oder Entwickler müssen nichts machen, damit Cache genutzt wird. Die Verwaltung desselbigen macht die CPU komplett in Eigenregie und Software-transparent. Selbst wenn man wollte, gibt es meinem Wissen nach keine Möglichkeit, bestimmte Inhalte im Cache vorrätig zu halten.

Wenn das so ist und der Entwickler keine Einflussmöglichkeit hat - warum wird dann davon geredet, dass ein Spiel auf 3D-Cache "optimiert" wurde? In dem Falle wäre es so gesehen ja praktisch reiner Zufall, ob Spiel XY gut oder schlecht mit Zusatzcache skaliert?

 

[PCGH_Torsten]

Mir ist kein Beispiel bekannt, wo jemand sich damit gebrüstet hätte "wir optimieren extra, damit es auf 95 Prozent aller CPUs wie Grütze läuft" – Link?^^ Korrekt wäre jedenfalls eher: "Spiel XY harmoniert gut mit extra Cache" oder "profitiert stark davon". In aller Regel handelt es sich dabei aber um Spiele, die einfach nicht durch andere Parameter wie zum Beispiele Compute-Leistung, Inter-Core-Kommunikation oder absolute Speicher-Transferrate limitiert sind, sondern hart an der Zugriffslatenz für ein paar Hauptdaten hängen. Wenn die dann auf einmal aus einem Cache kommen, explodieren die Fps – aber dass die Grenze zu diesem "in place"-Szenario tatsächlich oberhalb von 32 MiB und unterhalb von 64 MiB, also genau im Fenster von AMDs V-Cache-Produkten liegt, wird in aller Regel tatsächlich purer Zufall sein. (Und ob der Cache dabei 3D oder monolithisch ist, spielt gleich gar keine Rolle. Das sie einen externen Chip ohne Nachteile wie internen Cache ansprechen können, ist doch gerade die Meisterleistung von AMD V-Cache-Entwicklung.)

Zum Stromverbrauch: Es kann tatsächlich sein, dass schnellere Caches auch verbrauchsintensiver sind. Auf alle Fälle spielt bei L1 und L2 noch ein weiterer Parameter eine große Rolle, nämlich die Zugriffszeit der Ansteuerung. Je größer ein Cache ist, desto schwerer wird es, ihn zu verwalten, da hilft auch die Geschwindigkeit der einzelnen Speicherzellen nicht weiter. Deswegen sind L1-Caches bewusst sehr klein gehalten, nicht so sehr wegen der Fläche. (Auch wenn die pro MiB tatsächlich wesentlich größer als für L3 ausfällt.) Bei 100 MiB Extra-Cache redet man aber ohnehin, aus genau diesem Grund, über eine extra Stufe. Für einen L4 zählt dann nur noch der Platzbedarf. Schneller als DDR-DRAM ist er allemal, aber ist er in "bezahlbarer" Dimension auch hinreichend größer als der L3, um sich zu lohnen? Die Antwort lautet in aller Regel "nein".

In der Vergangenheit gab es übrigens ein paar Beispiele von CPUs, die sich nur im Cache unterschieden haben. Das bekannteste dürften Galatine P4EE gegenüber Northwood-C P4 gewesen sein: Der gleiche CPU-Kern, der gleiche 0,5-MiB-L2-Cache aber zusätzlich 2 MiB L3. Transistorzahl und Gesamtfläche sind dadurch noch stärker angestiegen, als bei Zen 3 versus Zen 3d, aber die damals noch exakt angegebene, von Verbrauchsmessungen gedeckte TDP nur von 82 auf 92 (3,2 GHz) respektive von 89 auf 102 W (3,4 GHz). 13-14 Prozent sind natürlich nicht nichts, aber für dreimal so viele Transistoren lachhaft wenig und den Performance-Zuwachs durchaus wert. AMD könnte einem "Ryzen 8" statt einem zusätzlichen Compute-CCD also locker 4-5-6 zusätzliche V-Cache-Chips spendieren, ohne den von Ryzen 9 bekannten Verbrauchsrahmen zu sprengen oder die Taktraten wegen Power Limitierungen drosseln zu müssen.

 

[BigBoymann]

Aber ich kann durchaus unterscheiden, ob ein ganzer Verein überheblich rüberkommt, oder einzelne Personen. Und da scheint bei dir die Trennung nicht zu erfolgen

Naja, ein ganzer Verein wird wohl nie eine Rolle einnehmen können, außer er besteht nur aus ganz wenigen Personen. Aber bei den Bayern ist es schon so, dass Sie über weite Strecken, von einem Großteil der Fußballwelt als überheblich wahrgenommen werden und dieses Image durchaus sogar pflegen. Bedeutet natürlich nicht, dass einzelne Personen dies unbedingt sein müssen. Darfst du auch gerne googlen und du wirst überascht sein, dass wahrscheinlich 80% der Nicht Bayern Fans den Verein auf Platz 1 der Überheblichkeit setzen würden.

ja was denn?

Ich weiß nicht so recht was deine Agenda ist, aber Intel hat in nahezu jeder Werbung seine Überheblichkeit gezeigt. Ich kann mich noch gut daran erinnern, als jemand von Intel auf der Bühne einen Opteron in den Müllkorb geworfen hat, oder Pats Passwort "I hate AMD". Davon gab es unglaublich viele Dinge und viele Kampagnen waren sehr hart und überheblich geführt.

das findest du auch bei anderen Herstellern, auch AMD verkauft alte CPUs/GPUs gerne weiter. Refresh oder RElabel...

Nochmal, welche Agenda verfolgst du?

Ich schreibe doch ganz klar "Firmen" und nenne dann ein Beispiel!

Ich brauch Kerne UND Cache

Wofür?

Alle erzählen immer, dass Sie mit dem Rechner, dies und das machen und glauben tue ich davon 1% weil ich so lange dabei bin, dass ich weiß, dass viel zu viel geschwätzt wird. Ich kenne nur ganz wenige Szenarien die beides gleichzeitig brauchen und die sind allesamt mit Desktop PCs nicht richtig bedient. Dafür gibt es Server / Workstation Chips, die dann auch mehr als 16 Kerne bieten.

Ja, wenn der Cache die ganze CPU zu Undervolting zwingt um nicht draufzugehen machts das natürlich effizient - das ist aber ein nachgelagerter Effekt (der von AMD sicher nicht absichtlich gewählt wurde, was folgende Generationen bewiesen haben).

Ja und Nein, grds. ist die Erhöhung der Effizienz ja per se erstmal dadurch gewährleistet, dass die CPU mehr FPS liefert. Sprich ein 9800X3D wird bei gleichem Verbrauch mehr FPS generieren als ein 9800X und dadurch effizienter laufen. Hinzu kommt natürlich, dass man den unsinnigen OC Bereich verlassen musste, da man den 3D Cache sonst nicht gekühlt bekam. Aber eine 30% bessere Effizienz würde ich schon rein dem 3D Cache zuschreiben.

Wenn das so ist und der Entwickler keine Einflussmöglichkeit hat - warum wird dann davon geredet, dass ein Spiel auf 3D-Cache "optimiert" wurde? In dem Falle wäre es so gesehen ja praktisch reiner Zufall, ob Spiel XY gut oder schlecht mit Zusatzcache skaliert?

Ich denke mal, dass man Spiele schon so programmieren kann, dass Sie mehr Cache besser finden. Thorsten sagt ja nicht, dass man als Entwickler keinen Einfluss darauf hat, sondern nur, dass man nicht aktiv eingreifen kann, was im Cache gehalten wird und was nicht. Aber man wird schon "optimieren" können.

 

[Rollora]

Naja, ein ganzer Verein wird wohl nie eine Rolle einnehmen können, außer er besteht nur aus ganz wenigen Personen. Aber bei den Bayern ist es schon so, dass Sie über weite Strecken, von einem Großteil der Fußballwelt als überheblich wahrgenommen werden und dieses Image durchaus sogar pflegen. Bedeutet natürlich nicht, dass einzelne Personen dies unbedingt sein müssen. Darfst du auch gerne googlen und du wirst überascht sein, dass wahrscheinlich 80% der Nicht Bayern Fans den Verein auf Platz 1 der Überheblichkeit setzen würden.

ironischerweise habe ich da gerade unter dem Sieg der Bayern viele Kommentare entdeckt die sagen "sie verstehen nicht, warum die Bayern immer noch als Überheblich gesehen werden, diese Zeiten sind längst vorbei" - und zwar, wenn man sich die Poster ansieht, durchaus von Nicht-Bayern Fans.
Also nein, deine 80% sind entweder aus der Luft gegriffen, oder ewiggestrige. Die Spielerinterviews sind seit 25+ Jahren einfach viel zu sauber und gescripted, wer da immer noch von "Überheblichkeit" spricht der lebt halt in seiner eigenen Welt.
Da ich immer die Sportschau samt Interviews anschau sehe ich diese ÜBerheblichkeit eben genauso wenn nicht noch mehr in anderen Vereinen...
Und nein, ich bin kein Fan, aber ich find das immer amüsant wie gewisser Anti/Hass wasauchimmer einfach immer weitergelebt wird
Wenn man Leute fragt, ob sie die Bayern überheblich finden dann mag das oft mit "ja" beantwortet werden, weil einfach die Mundpropaganda sagt, Bayern sind überheblich, nicht weil sie es sind. Hinzu kommt der Hindsight/Confirmation Bias.
Ich könnte hier auch annehmen, dass du überheblich bist.
Deutsche sind ja auch generell überheblich, das sagen 80% der Europäer. Dann wird das schon stimmen, oder?

Ich weiß nicht so recht was deine Agenda ist,

Ich sehe Dinge Relativ, nicht absolut?

aber Intel hat in nahezu jeder Werbung seine Überheblichkeit gezeigt

ja? Welche denn? Und warum fällt dir das nur bei Intel auf?

Ich kann mich noch gut daran erinnern, als jemand von Intel auf der Bühne einen Opteron in den Müllkorb geworfen hat, oder Pats Passwort "I hate AMD". Davon gab es unglaublich viele Dinge und viele Kampagnen waren sehr hart und überheblich geführt.

Marketing halt, das gibts bei allen Firmen. Poor Volta sag ich da nur

Nochmal, welche Agenda verfolgst du?

Anti-Schwarz-weiß-denke

Ich schreibe doch ganz klar "Firmen" und nenne dann ein Beispiel!

und ich weise auf andere hin, damit verfolge ich keine Agenda

Wofür?

auf der CPU läuft so ziemlich alles. Von lokaler KI über Spiele, wissenschaftliche Berechnungen, encoding...
Oh und am besten hoch effizient bei Niedriglast.
Allerdings ist "brauch" übertrieben. "Wünsch' mir" wäre besser gewählt.

Alle erzählen immer

das sind gleich 2 übertreibungen/verallgemeinerung in 3 Wörtern
Und deine 80% sind wohl auch so eine Übertreibung

, dass Sie mit dem Rechner, dies und das machen und glauben tue ich davon 1% weil ich so lange dabei bin, dass ich weiß, dass viel zu viel geschwätzt wird. Ich kenne nur ganz wenige Szenarien die beides gleichzeitig brauchen und die sind allesamt mit Desktop PCs nicht richtig bedient. Dafür gibt es Server / Workstation Chips, die dann auch mehr als 16 Kerne bieten.

nun tatsächlich laufen unsere Anwendungen auf zwischen 8 Kernen (lokale ältere PCs) und tausenden.
Was auch immer das mit dem Wunsch zu tun hat mehr Kerne und mehr Caches zu haben.

Aber wenn man es nur auf Spiele bezieht zeigte doch der 5800X3D schön: es gibt genug Gründe für eine CPU mit Cache. Entweder Leistung oder Effizienz. Und mehr Kerne sind immer praktisch, auch für bessere Zukunftssicherheit.

Ich denke mal, dass man Spiele schon so programmieren kann, dass Sie mehr Cache besser finden.

ja nämlich "nicht gut". Also Cache wird vor allem dann ein wichtiger Bestandteil, wenn Code nicht super läuft

 

[D4rKnE55]

Mir ist kein Beispiel bekannt, wo jemand sich damit gebrüstet hätte "wir optimieren extra, damit es auf 95 Prozent aller CPUs wie Grütze läuft" – Link?^^ Korrekt wäre jedenfalls eher: "Spiel XY harmoniert gut mit extra Cache" oder "profitiert stark davon". In aller Regel handelt es sich dabei aber um Spiele, die einfach nicht durch andere Parameter wie zum Beispiele Computer-Leistung, Inter-Core-Kommunikation oder absolute Speicher-Transferrate limitiert sind, sondern hart an der Zugriffslatenz für ein paar Hauptdaten hängen. Wenn die dann auf einmal aus einem Cache kommen, explodieren die Fps

Von "Optimierungen" diesbzgl. hab ich auch noch nicht gehört, ich hätte auch von "profitiert stark davon" gesprochen.

Ohne jetzt groß drauf rumzudenken, möchte ich dich aber mal was fragen: Ich hätte jetzt gesagt, dass Spiele, die vom großen Cache profitieren, dann eher _nicht_ auf schnelle CPU-Berechnungen hin optimiert sind, oder? Wie Rollora zuletzt schon angedeutet hat.
Dass, wenn man das ganze profiled und rauskommt, dass die Zugriffszeiten ein Bottleneck sind, man dagegen vorgehen müsste.

Obwohl ich tatsächlich Entwickler bin, hab ich keine wirkliche Ahnung, da nicht hardware-nah. Aus eigenem Fachwissen kann ich nur sagen, dass (Software-)Caches ein wichtiges Mittel zur Optimierung als auch eine Kaschierung fehlender Optimierung sein können.^^

 

[latiose88]

@D4rKnE55 cool dann verstehst du ja auch was davon was ich dich frage.
Ich bin auf das eine Programm xmedia recode als 32 bit gebunden. Es macht unter Windows 11 nur Probleme . Man kann einstellen was man will ,es vergisst die selbst aktiven Sitzung eingestellte Sachen. Unter Windows 10 habe ich das Problem noch nie gehabt. Zuverlässig arbeitet es eben also nicht unter Windows 11. Mehrere Menschen die für mich was getestet hatten ,hatten nur Probleme damit gehabt. Selbst die 64 bit Version machte erst Recht nur Probleme auch wenn diese schneller etwas schneller ist.
Wenn ich dann umwandle kommen am Ende 18 Software Threads raus. Selbst wenn ich 2 davon gleichzeitig starte laste ich damit ein 9950x3d nur zu 84 % aus.
Tya schaue so nicht so aus als ob es viel wäre. Das heißt auf gut deutsch 13 Kerne ackern voll und 3 Kerne der Zeit schlafen vor sich hin.
Ich bilde mir ein das ich vom extra l3 Cache profitieren. Bei Intel jedoch mag ich zwar beim 265k alle Kerne voll auslasten aber die e Kerne limitieren alles. Scheinbar geht der CPU der l3 Cache aus ,sonst würde die CPU nicht zurück fallen .
Ich habe somit eine gewisse hohe Last aber profitiere doch von Latenz .Das passt halt irgendwie nicht zusammen aber scheint wirklich der Fall zu sein.
Ich gehöre also zu den wenigen wo das der Fall ist.
Spannend wird es also wenn diese Nachfolger auf dem Markt sind. Dann kann ich mich wirklich voll und ganz darauf konzentrieren. Wird mir jedenfalls eine Freude bereiten.
Spannend wird es für mich sein wie sich die viel bessere Latenz und IPC samt höhere Taktraterate auf das 32 bit mit begrenzter Software Threads so auswirkt.

Google KI sagte mir bei so wenig Software Threads könnte ich 100 Kerne haben ,das Ergebnis würde das selbe sein und es bliebe bei den 18 Threads pro Video. Was am Ende weil zwei gleichzeitig 36 wären und damit würden die Kerne nicht ordentlich ausgelastet sein. Ich bin ein spezial fall. Besser wird die Software nicht werden. Höhere Einstellung würden die Geschwindigkeits senken aber die Auslastung verbessern. Das ist das dielemma an das ganze. Die Videos kann ich eben nicht einfach so die Auflösung des Quellen Videos erhöhen.
Was am Ende bleibt ist die Tatsache das ich ab einer bestimmten Anzahl an kernen die Mehrleistung ins nichts verpufft. Damit kann ich auf das Problem eben nicht einfach so immer noch mehr Kerne auf das Programm schmeißen weil schneller wird das nicht mehr werden.
Was heißt das für mich ,hätte der Entwickler sich mehr Mühe machen können oder ist jede Anstrengung des ganzen nicht mehr wert ?

 

[PCGH_Torsten]

Von "Optimierungen" diesbzgl. hab ich auch noch nicht gehört, ich hätte auch von "profitiert stark davon" gesprochen.

Ohne jetzt groß drauf rumzudenken, möchte ich dich aber mal was fragen: Ich hätte jetzt gesagt, dass Spiele, die vom großen Cache profitieren, dann eher _nicht_ auf schnelle CPU-Berechnungen hin optimiert sind, oder? Wie Rollora zuletzt schon angedeutet hat.
Dass, wenn man das ganze profiled und rauskommt, dass die Zugriffszeiten ein Bottleneck sind, man dagegen vorgehen müsste.

Obwohl ich tatsächlich Entwickler bin, hab ich keine wirkliche Ahnung, da nicht hardware-nah. Aus eigenem Fachwissen kann ich nur sagen, dass (Software-)Caches ein wichtiges Mittel zur Optimierung als auch eine Kaschierung fehlender Optimierung sein können.^^

Hängt jetzt davon ab, was du mit "auf schnelle CPU-Berechnungen optimiert" meinst. Dafür optimiert, schnell (=leicht) berechenbar zu sein? So optimiert, dass es davon abhängig ist, schnell berechnet zu werden?
Herausragende Cache-Profiteure haben typischerweise wenig/wenig aufwendiges zu berechnen. Die eigentliche Arbeit in den Rechenkernen kann schnell erledigt werden respektive könnte das, wenn die Daten schnell genug bereitstehen würden. Besagte Daten wiederum sind nicht so klein, dass sie in herkömmliche Caches passen würden, aber auch nicht so groß, dass der große Cache ebenfalls überfordert wäre.

Z.B. Videobearbeitung ist, vor allem bei schwacher Komprimierung, extrem speicherlastig, profitiert aber genau deswegen überhaupt nicht von Caches, weil die zu bearbeitenden Inhalte so oder so nicht passen. Synthetische Benchtools im anderen Extrem sind wiederum so klein, dass sie komplett in Standard-Caches passen, da ergeben sich auch keine Unterschiede. Zwischen beiden rangieren Anwendungen, bei den die häufig verwendeten Bestandteile zwar ein paar Megabyte extra brauchen könnten, aber die Datenverarbeitung in der CPU ohnehin solange braucht und so gut vorhersagbar ist, dass der Prefetcher alles rechtzeitig aus dem RAM bereitstellen kann. Nur wer alle drei naheliegenderen Fallstricke meistert, kann im Cache-Größen-Limit landen. Bei Spielen scheint das besonders oft der Fall zu sein. Macht ja auch Sinn: Engine, Kern-Assets wie das Interface und die wichtigsten Elemente rund um den Spieler kommen auf einige Megabyte, aber nicht auf viele Dutzend, und werden bei jedem Durchlauf des Gameloops aktiviert. Von den mehrere 100 Megabyte großen Texturen und weiten Teilen der Leveldaten wird dagegen immer nur ein Ausschnitt benötigt oder ohnehin nur an die GPU durchgereicht, dass kann man alles im RAM parken. Und die Komplexität scheint auch eher mäßig zu sein, wenn man mal die Package Power als Gratmesser der Auslastung heranzieht – oder sich überlegt, wie nah viele Spielmechaniken hinter aktueller Grafik eigentlich an der von Titeln dran sind, die schon auf einem Pentium III flüssig liefen.

 

[D4rKnE55]

Hängt jetzt davon ab, was du mit "auf schnelle CPU-Berechnungen optimiert" meinst. Dafür optimiert, schnell (=leicht) berechenbar zu sein? So optimiert, dass es davon abhängig ist, schnell berechnet zu werden?
Herausragende Cache-Profiteure haben typischerweise wenig/wenig aufwendiges zu berechnen. Die eigentliche Arbeit in den Rechenkernen kann schnell erledigt werden respektive könnte das, wenn die Daten schnell genug bereitstehen würden.

Ich meinte ersteres. Bzw. nicht mal wirklich "leicht" berechenbar, da das dann in die Richtung gehen würde, einen effizienteren oder versimplifizierenden Algo zu nutzen (natürlich die erste Prio!), sondern einfach das, was berechnet werden muss, möglichst schnell/in wenig Zeit zu berechnen, also die Bottlenecks zu identifizieren und versuchen zu "lösen".
Hatte da an sowas wie Datensets so aufzubereiten, dass sie in geläufige Caches passen oder eine Art Prefetching der Daten zu betreiben (wobei da wohl vllt. nur das Aktivieren der Rows im RAM möglich wäre? Denn um vom Cache zu profitieren, müssen die Daten ja vermutlich zmd. schon im RAM vorliegen..) gedacht - jedenfalls sofern möglich.

Aber du hast noch einen anderen Faktor erwähnt, der mir zuerst gar nicht so bewusst war: Die große Leistungssteigerung durch Cache ist natürlich auch nur möglich, wenn die Berechnungen an sich nicht zu komplex sind und prozentual nicht viel mehr Zeit in Anspruch nehmen, als die Zugriffs/Bereitstellungszeiten für die Daten.

Z.B. Videobearbeitung ist, vor allem bei schwacher Komprimierung, extrem speicherlastig, profitiert aber genau deswegen überhaupt nicht von Caches, weil die zu bearbeitenden Inhalte so oder so nicht passen.

Ah, die Info ist auch hilfreich für mich! Bzw. Was meinst du mit "Videobearbeitung" überhaupt? Das Bearbeiten von Videos in Sony Vegas und Konsorten, oder das Encoding von Videos mit x264, x265 etc.?
Bzgl. letzterem wollte ich mich eh noch informieren, ob da X3D CPUs hilfreich sind, oder auch eher schlechter performen, wie bei vielen anderen Produktivitäts-Szenarien..
War bei meinen bisherigen Quellen kaum abgebildet das Thema.

Bei Spielen scheint das besonders oft der Fall zu sein. Macht ja auch Sinn: Engine, Kern-Assets wie das Interface und die wichtigsten Elemente rund um den Spieler kommen auf einige Megabyte, aber nicht auf viele Dutzend, und werden bei jedem Durchlauf des Gameloops aktiviert. Von den mehrere 100 Megabyte großen Texturen und weiten Teilen der Leveldaten wird dagegen immer nur ein Ausschnitt benötigt oder ohnehin nur an die GPU durchgereicht, dass kann man alles im RAM parken.

Interessant, mir war nicht bekannt, dass auch gewisse Assets in der 'Pipeline' der CPU landen.. Weißt du wofür manche Assets in der CPU gebraucht werden?
Ich hätte jetzt gedacht, dass nur gewisse Logiken und resultierende Parameter wie Boolean Werte, ob ein gewisses HUD Element sichtbar ist, oder Integer Werte, welche Variante eines Assets benötigt wird die CPU durchkreuzen und die Assets an sich nur zur GPU durchgereicht werden.
Ist jetzt eher Off-Topic, aber jetzt wo du's erwähnt hast.^^

Ok, jetzt wo ich etwas drüber nachgedacht hab, meinst du vllt. um z.B. Farbwerte eines Assets zu extrahieren, um daraufhin dann gewisse Interpolationen zu kalkulieren und an die GPU zu reichen? Lass meine vorherige Frage trotzdem mal so stehen.^^

 

[latiose88]

@PCGH_Torsten ich hab genau das Problem was du geschrieben hast.
Ich verwende einen 265k. Ich gebe Vollgas. Zwei gleich starke Anwendung gleichzeitig und zwar auf p und e Kerne . Das dann die e Kerne schlapp machen sagte mir auch einer. Die e Kerne sind keine Power Kerne. Und darum fallen die auch bei der Leistung zurück. Aber genau das fordere ich sie .ich tue ihnen alles abverlangen was geht. Aber nun Stelle ich fest ,ich kriege diese nicht mehr schneller hin. Ich stecke in der Sackgasse. Die CPU bei den e Kernen völlig überfordert aber ich verlange nach mehr. Die Wattanzeige die steigt nach oben ,bei stärkeren CPUs sogar so weit das sie sogar drosseln. Würde ich da nun mit Luft hantiert würde es gameover heißen. Sogar der 285k landete bei einem auf 90 Grad. Also kurz vor der Drossel Grenze. Mehr scheint wirklich nicht zu gehen. Würde ich auf Takt noch bestehen ,dann würde wohl auch die wasseekühlung schlapp machen. Alles nur um die e Kerne mehr zu Puschen . Aber genau damit würde ich der CPU wirklich erschlagen. Ich habe wohl gedacht die e Kerne könnten echte Last auch vertragen. Naja hinter her wohl doch schlauer geworden. Wird das etwa beim Nachfolger auch wieder so Enten e Kerne geben ?

 

[D4rKnE55]

@D4rKnE55 cool dann verstehst du ja auch was davon was ich dich frage.
Ich bin auf das eine Programm xmedia recode als 32 bit gebunden. Es macht unter Windows 11 nur Probleme . Man kann einstellen was man will ,es vergisst die selbst aktiven Sitzung eingestellte Sachen. Unter Windows 10 habe ich das Problem noch nie gehabt. Zuverlässig arbeitet es eben also nicht unter Windows 11.

Hehe, XMedia Recode war auch mal mein Tool der Wahl. Ist aber schon sehr lange her, möglicherweise hab ich es zuletzt unter Win 7 genutzt.. Ich setze schon lange auf Handbrake, und teils auch mal direkt ffmpeg über die Kommandozeile.
Außerdem bin ich immer noch unter Win 10 unterwegs, also kann ich mit Win 11 auch nicht weiterhelfen.. :|

Wenn ich dann umwandle kommen am Ende 18 Software Threads raus. Selbst wenn ich 2 davon gleichzeitig starte laste ich damit ein 9950x3d nur zu 84 % aus.
Tya schaue so nicht so aus als ob es viel wäre. Das heißt auf gut deutsch 13 Kerne ackern voll und 3 Kerne der Zeit schlafen vor sich hin.

Hach ja.. Encodest du über x264 oder x265 (oder andere H.265 Encoder)?
Solltest du, wie ich, weiter mit x264 encoden, ist das nicht verwunderlich und du hättest dich vor dem CPU Kauf vllt. mehr informieren sollen.
x264 skaliert nicht gut mit mehr als 16 Threads. Einerseits hast du mehrere Typen von Frames und die sind teils untereinander abhängig, sodass man nicht endlos skalieren kann, andererseits hab ich zmd. gelesen, dass bei mehr als 16 Threads die Qualität auch abnehmen kann. Das ist auch einer der Gründe weshalb ich mich damals nicht für eine höhere CPU Klasse als den 3700X entschieden hab.
Ich lass x264 (aktuell) die 'interne' Anzahl an Threads selbst bestimmen und lande bei meinen meisten Encodes bei 22-24 Threads (1,5x). Bei Encodes in niedrigerer Auflösung (<= 720p) und/oder mit simpleren Settings (medium Preset) lande ich auch mal bei nur 18 Threads.
Wenn du die 18 Threads auch bei FHD bekommst, grätscht entweder XMedia Recode dazwischen oder du nutzt ein niedriges Preset - höhere Presets skalieren mit der Leistung besser, probier mal "slower".
Du kannst zwar manuell den Threadcount über "--threads=X" festlegen (weiß nicht ob in XMedia Recode), aber würde ich persönlich nicht machen, höher zu gehen..

Mit x265 hab ich deutlich weniger Erfahrung und Wissen. Vllt. Da mal selbst recherchieren bzgl. Der Skalierung.

Ich bilde mir ein das ich vom extra l3 Cache profitieren. Bei Intel jedoch mag ich zwar beim 265k alle Kerne voll auslasten aber die e Kerne limitieren alles. Scheinbar geht der CPU der l3 Cache aus ,sonst würde die CPU nicht zurück fallen .

Ich glaub eher, dass die E-Cores limitieren, wenn abhängige Frames der P-Cores auf das Ergebnis der langsameren E-cores warten müssen. Auch da hab ich allerdings Null Erfahrung, was diese Architektur in dem Fall angeht.

Google KI sagte mir bei so wenig Software Threads könnte ich 100 Kerne haben ,das Ergebnis würde das selbe sein und es bliebe bei den 18 Threads pro Video.

Joa, siehe oben.^^

Höhere Einstellung würden die Geschwindigkeits senken aber die Auslastung verbessern. Das ist das dielemma an das ganze.

Ah, ok, hast das auch schon raus.^^ Naja, machst aber mehr Nutzen aus deiner CPU und bekommst eine bessere Qualität (je nachdem wo du aktuell mit den Einstellungen stehst..).

Was heißt das für mich ,hätte der Entwickler sich mehr Mühe machen können oder ist jede Anstrengung des ganzen nicht mehr wert ?

Siehe oben. Man kann nicht alles endlos skalieren und Threading ist prinzipiell nicht einfach. Um zu urteilen, ob man x264 o.ä. besser skalieren könnte, bin ich bei Weitem nicht in der Lage. Da sitzen allerdings sehr kluge Köpfe dran, die sowas optimieren, ich tendiere also zu "nein, das liegt nicht an zu wenig Mühe seitens der Entwickler".
Große Firmen nutzen zwar durchaus andere Encoder, als das was uns zur Verfügung steht, aber natürlich hab ich da keine Ahnung, inwiefern die besser skalieren.

 

[latiose88]

Hach ja.. Encodest du über x264 oder x265 (oder andere H.265 Encoder)?
Solltest du, wie ich, weiter mit x264 encoden, ist das nicht verwunderlich und du hättest dich vor dem CPU Kauf vllt. mehr informieren sollen.
x264 skaliert nicht gut mit mehr als 16 Threads. Einerseits hast du mehrere Typen von Frames und die sind teils untereinander abhängig, sodass man nicht endlos skalieren kann, andererseits hab ich zmd. gelesen, dass bei mehr als 16 Threads die Qualität auch abnehmen kann. Das ist auch einer der Gründe weshalb ich mich damals nicht für eine höhere CPU Klasse als den 3700X entschieden hab.
Ich lass x264 (aktuell) die 'interne' Anzahl an Threads selbst bestimmen und lande bei meinen meisten Encodes bei 22-24 Threads (1,5x). Bei Encodes in niedrigerer Auflösung (<= 720p) und/oder mit simpleren Settings (medium Preset) lande ich auch mal bei nur 18 Threads.

Jap genau ich verwende wie du auch x264. Ich verwende custom medium also eher niedige settings. Und ich habe 720x576i und 1280x720p 50 vollbilder. Diese Software wo du nanntest genau das ist diese. Ich verwende allerdings die Version von 2018 32 bit. Neurere laufen nicht mehr so gut. Ich habe es versucht aber so richtig glücklich bin ich nicht. Es merkt sich meine Einstellung nicht mehr. Ich muss immer wieder neu sowas wie deinterlacing einstellen egal welches Video. Das nervt echt. Will selbst entscheiden was ich mache. Aber gut ich bleibe einfach bei der einen Version .damit habe ich kein Problem .aber von einer guten Auslastung kann ich halt nicht mehr sprechen. Ich verwende schon zwei Mal das selbe Programm. Es scheint immer noch nicht so gut auszulasten. Naja dann wird es halt ein 12 Kerner . Das gute ist ja der kommende 12 Kerner ist endlich ein chiplet . Damit kann ich endlich die ganzen Probleme hinter mir bringen. Skalierungs Probleme dürfte ich damit nicht mehr haben. Mich stört es nicht ,kommt es mir ja zugute. Wenn ich eines der besten Ergebnisse raus kriege ,dann juckt es mich nicht wenn ich nicht mehr Kerne habe als das was ich bisher gewohnt war. Wenn ich mit 12 Kernen so schnell wie mit 16 kernen bin dann habe ich alles richtig gemacht. Ziel erreicht.

Wenn du die 18 Threads auch bei FHD bekommst, grätscht entweder XMedia Recode dazwischen oder du nutzt ein niedriges Preset - höhere Presets skalieren mit der Leistung besser, probier mal "slower".
Du kannst zwar manuell den Threadcount über "--threads=X" festlegen (weiß nicht ob in XMedia Recode), aber würde ich persönlich nicht machen, höher zu gehen..

Na das selbst festlegen mündete immer in langsamer um. Damit erreiche ich genau das Gegenteil davon . Die Software macht das schon korrekt. Damit habe ich die schnellste Zeit meistens ereicht. Die Software ist doch nicht so dumm wie ich dachte. Die ist klug. Ich habe mich dran gewöhnt. Achja ich kann ja Mal schauen welchen Wert ich da so habe. Ich habe ein 4k auf full HD runter gerechnet. Könnte ich gerne mal nach schauen. Denke mal da steht schon ein höhere wert drinnen. Wobei die Auslastung durch herunter rechnen war naja mehr oder weniger eine Last. Ich würde mal sagen die war ganz schön niedrig Anfangs gewesen. Aber später war die immer höher. Ist schon seltsam das ganze.

Mit x265 hab ich deutlich weniger Erfahrung und Wissen. Vllt. Da mal selbst recherchieren bzgl. Der Skalierung.

Das ist egal ,mit h265 habe ich nix zu tuen. Ist mir auch egal.

Ich glaub eher, dass die E-Cores limitieren, wenn abhängige Frames der P-Cores auf das Ergebnis der langsameren E-cores warten müssen. Auch da hab ich allerdings Null Erfahrung, was diese Architektur in dem Fall angeht.

Ja sicher limtieren die e Kerne. Video 1 ist fertig dank den p Kernen. Videos zwei ackert noch weil e Kernen noch dran arbeiten. Später wenn die p Kerne alles erledigt haben und die e Kerne noch ackern ,dann passiert am drauf folgende Videos eine geachwindigkeits boost. Auf einmal geht alles viel schneller. Die e Kerne packen es einfach nicht.

Joa, siehe oben.^^

Ah, ok, hast das auch schon raus.^^ Naja, machst aber mehr Nutzen aus deiner CPU und bekommst eine bessere Qualität (je nachdem wo du aktuell mit den Einstellungen stehst..).

Glaube mal viel hole ich da einfach nicht mehr raus. Es wird auch nur noch minimal kleiner aber der Aufwand ist zu hoch. Ich lasse es lieber wie es ist.

Siehe oben. Man kann nicht alles endlos skalieren und Threading ist prinzipiell nicht einfach. Um zu urteilen, ob man x264 o.ä. besser skalieren könnte, bin ich bei Weitem nicht in der Lage. Da sitzen allerdings sehr kluge Köpfe dran, die sowas optimieren, ich tendiere also zu "nein, das liegt nicht an zu wenig Mühe seitens der Entwickler".
Große Firmen nutzen zwar durchaus andere Encoder, als das was uns zur Verfügung steht, aber natürlich hab ich da keine Ahnung, inwiefern die besser skalieren.

Naja man kann nicht alles wissen. Hätte ja sein können das du da was weißt. Aber wenn du da nicht so drinnen bist ,dann kann man nix machen. Aber die Einschätzung von dir war dennoch richtig. Du kennst dich halt doch etwas aus. ^^

 

[D4rKnE55]

Jap genau ich verwende wie du auch x264.

Top, und dann war mein Riecher auch richtig.

Na das selbst festlegen mündete immer in langsamer um. Damit erreiche ich genau das Gegenteil davon . Die Software macht das schon korrekt. Damit habe ich die schnellste Zeit meistens ereicht. Die Software ist doch nicht so dumm wie ich dachte. Die ist klug.

Achja ich kann ja Mal schauen welchen Wert ich da so habe. Ich habe ein 4k auf full HD runter gerechnet. Könnte ich gerne mal nach schauen.

[...]

Glaube mal viel hole ich da einfach nicht mehr raus. Es wird auch nur noch minimal kleiner aber der Aufwand ist zu hoch. Ich lasse es lieber wie es ist.

PN..

Naja man kann nicht alles wissen. Hätte ja sein können das du da was weißt. Aber wenn du da nicht so drinnen bist ,dann kann man nix machen. Aber die Einschätzung von dir war dennoch richtig. Du kennst dich halt doch etwas aus. ^^

Weiß auch gar nicht was du erwartet hast, was ich wissen sollte? Ist eh Zufall, dass ich mich mit Video-Encoding gut auskenne, denn für deine Fragen brauchst du nicht wirklich 'nen Entwickler.. Nur vllt. spezifisch 'nen x264 Entwickler, aber ich hab dir ja auch schon gesagt, weshalb diese Berechnungen nur limitiert skalierbar sind..

Hab mich generell auch versucht zurückzuhalten, denn das ist schon ziemlich Off-Topic hier.^^
Ich schick dir 'ne PN.

 

[PCGH_Torsten]

@D4rKnE55:

Prefetching macht die CPU selber, Software hat umgekehrt keine direkte Kontrolle über den Cache. (Heißt umgekehrt: Im Cache kann alles mögliche landen, von dem der interne Algorithmus des Herstellers meint, es wäre wert, aufbewahrt zu werden. HUD war nur ein geratenes, aber illustratives Beispiel von mir.) Man kann also nur optimieren, wenn man spezifische Details der Caching-Logik eines konkreten Prozessors kennt. Aber wie schon im parallelen Thread zu Software-Optimierungen geschrieben: Das ist zu fummelig, um jenseits von Konsolen leistungsrelevant zu sein. Man schaue sich den Aufwand an, den Low-Level-Exploits wie Spectre treiben, um kontrollierte Cache-States zu provozieren.

In der Praxis würde maximal eine Anpassung des Codeumfangs erwarten und diese auch weniger zielgerichtet und mehr als Folge. Die gleiche Arbeit mit einem simpleren Programm zu machen, ist prinzipiell immer eine gute Idee und je näher man sich an der Kapazitätsgrenze des Caches bewegt, desto stärker sollten sich kleine Verbesserungen auszahlen. Heißt: Wer die Leistung seines Programms zu steigern versucht, in dem er es entschlackt, wird ganz automatisch von "ein Stück über der Cache-Kapazitätsgrenze" bis "darunter" optimieren, weil er in dem Bereich große Leistungszuwächse sieht, sich bei weiter Arbeit in gleicher Weise dann aber nur noch wenig tut.

Mit "Videoberarbeitung" meinte ich Schnitt und ähnliches, aber keine konkreten Programme, sondern nur allgemein/theoretisch betrachtet. Wer mehrere 100 MiB große Fragmente bearbeitet, arbeitet mit Daten, die nicht mehr cachebar sind. Der Programmcode umgekehrt sollte, den Größen typischer Ausführungsdateien zu Folge, sowieso passen.

De- oder Encoding kann ich schlechter einschätzen. Auf den ersten Blick wirkt es gar nicht cachelastig – die Tools sind winzig und die Nutzdaten werden nur einmal verarbeitet. Es gibt keine zweite Runde, für die man sie vorhalten könnte. Aber mikroskopisch betrachtet arbeiten meinem Wissen nach alle nicht komplett veralteten Codecs Frame temporal, nutzen die Daten eines einzelnen Bildes also jeweils für die Bearbeitung der folgenden. 24 MiB für einen komplett dekomprimierten UHD-Frame liegen durchaus in V-Cache-Größenordnung. Auf der anderen Seite sind diese Zugriffsmuster natürlich extrem vorhersehbar, Heimspiel für Prefetcher also, und je moderner der Codec, desto komplexer wird die Querverrechnung und desto eher limitieren die Compute-Pipelines. Was in der Summe rauskommt, kann ich nicht abschätzen und habe es auch nie vergleichend gebenched.