Notiz Ryzen 7 5800X3D: CPUs schon im Verkauf und erste Geekbench Scores

[guggi4]

Ein Beispiel für Optimierung auf jeweilige Cachegrößen wäre Prime95, wie relevant das ist, sei jedem selbst überlassen

 

[DevPandi]

Wieso sollten die Daten nicht auch beim Lesen in den L3 geladen werden

@Locuza hat bereits den Grund dafür genannt und @Zer0Strat auch.

Der Prefetcher lädt die Daten vor, die der Kern als nächstes benötigt und lädt die Daten in den L2 und L1d, der L3 ist ein Victim-Cache und wird von den Kernen primär beim Schreiben mit Daten versehen.

Was Locuza erwähnt ist, das man den L3 per Software explizit beschreiben kann, das wiederum obliegt dann den Softwareentwicklern oder dem Compiler und läuft über die CPU-Befehle ab und ist damit keine Logik des Prefetcher.

Der Prefetcher schaut auch nur eine bestimmte Zeit in die Zukunft und die Daten, die er lädt, werden vergleichsweise schnell benötigt, es ist daher nicht unbedingt sinnvoll, dass die Daten in den L3 geladen werden, das kosten sogar sinnlos Energie.

Anders sähe es aus, wenn der L3 Inclusive wäre, dann würde der L3 auch die Daten des L2 enthalten und man würde ihn beim Laden von Daten aus dem RAM mit beladen.

Dann würden geladene Daten aus den L2 irgendwann fallen, wären im L3 aber ggf. noch, wenn sie nicht überschrieben werden. Nachteil wäre dann aber, das er mit dem L2 synchron gehalten werden muss, was wieder Energie kostet und die Cache Verwaltung komplex macht.

 

[Ned Flanders]

Anders sähe es aus, wenn der L3 Inclusive wäre, dann würde der L3 auch die Daten des L2 enthalten und man würde ihn beim Laden von Daten aus dem RAM mit beladen.

Dann würden geladene Daten aus den L2 irgendwann fallen, wären im L3 aber ggf. noch, wenn sie nicht überschrieben werden. Nachteil wäre dann aber, das er mit dem L2 synchron gehalten werden muss, was wieder Energie kostet und die Cache Verwaltung komplex macht.

Der L3 wird zwar nicht beladen, aber auch nicht zwangsläufig invalidiert, denn der L3 ist non-inclusive, nicht exclusive, und 'may or may not contain data present in L1/L2'.

Da ist offenbar noch eine Logik dahinter die das entscheidet. Komplex ist das in jedem Fall

 

[Miuwa]

@Locuza hat bereits den Grund dafür genannt und @Zer0Strat auch.

Der Prefetcher lädt die Daten vor, die der Kern als nächstes benötigt und lädt die Daten in den L2 und L1d, der L3 ist ein Victim-Cache und wird von den Kernen primär beim Schreiben mit Daten versehen.

Was Locuza erwähnt ist, das man den L3 per Software explizit beschreiben kann, das wiederum obliegt dann den Softwareentwicklern oder dem Compiler und läuft über die CPU-Befehle ab und ist damit keine Logik des Prefetcher.

Der Prefetcher schaut auch nur eine bestimmte Zeit in die Zukunft und die Daten, die er lädt, werden vergleichsweise schnell benötigt, es ist daher nicht unbedingt sinnvoll, dass die Daten in den L3 geladen werden, das kosten sogar sinnlos Energie.

Anders sähe es aus, wenn der L3 Inclusive wäre, dann würde der L3 auch die Daten des L2 enthalten und man würde ihn beim Laden von Daten aus dem RAM mit beladen.

Dann würden geladene Daten aus den L2 irgendwann fallen, wären im L3 aber ggf. noch, wenn sie nicht überschrieben werden. Nachteil wäre dann aber, das er mit dem L2 synchron gehalten werden muss, was wieder Energie kostet und die Cache Verwaltung komplex macht.

Sorry für das fullquote, aber ich weiß nicht, was ich mir da rauspicken kann. Jedenfalls: Du missverstehst worauf ich mit meiner Frage hinaus willte: Auch beim laden von Daten müssem bestehende Daten aus dem L2 cache geschmissen werden. Wieso sollten diese Daten nicht genauso im L3 landen?

 

[DevPandi]

Der L3 wird zwar nicht beladen, aber auch nicht zwangsläufig invalidiert, denn der L3 ist non-inclusive, nicht exclusive, und 'may or may not contain data present in L1/L2'.

Bitte noch mal lesen was ich geschrieben habe. Ich habe nicht geschrieben, dass der L3-Cache Exclusive oder inclusive ist, sondern dass er ein Victim-Cache ist und in der Regel nicht beim Laden von Daten aus dem Arbeitsspeicher beschrieben wird - wie der L2 und L1 - sondern dass er primär beschrieben wird, wenn die Kerne mit den Daten eigentlich weitgehend fertig sind und diese wirklich in den Arbeitsspeicher zurück geschrieben und freigeben werden - daher auch das Victim. Die Stelle, die du von mir zitierst soll nur den Unterschied aufzeigen, wenn es sich beim L3 von AMD um einen inclusive handeln würde, ist es aber nicht.

Dein Zitat bestätigt auch noch etwas weiteres: Sobald die Daten aus dem L3-Cache in den L2 oder L1 des Kernes wandern, können diese Daten aus dem L3 heraus genommen werden, damit die Datenhoheit eben bei einem Kern liegt.

Und da kommt der nächste wichtige Punkt: Sollte neben dem eigentlichen Kern ein weiter darauf zu geriffen werden, müssen die Daten "kopiert" werden. Etwas, was Entwickler*innen, die nT-Anwendungen programmieren, die von Datenaustausch leben, sehr gut kennen und ich aktuell auch in RUST immer wieder erlebe. (Ich fang an die Sprache zu lieben!).

Das schöne an Victim-Caches ist, dass die Verwaltung relativ einfach ist, weil man klare Regeln hat und die Logik dahinter möglichst einfach hält.

Deswegen profitieren - in dem Fall - auch Spiele doch relativ Stark von dem größeren L3-Cache, weil hier Daten zwischen den Kernen ausgetauscht werden und damit entsprechende Daten im L3 landen und von dort auch gelesen werden.

Anwendungen die primär aus dem RAM lesen werden und bei denen kein so reger Austausch - Cinebench - zwischen den Kernen statt findet, profitieren eben nicht wirklich.

Auch beim laden von Daten müssem bestehende Daten aus dem L2 cache geschmissen werden. Wieso sollten diese Daten nicht genauso im L3 landen?

Ich habe nie geschrieben - soviel zum Thema missverstehen - dass Daten nicht auch beim Laden ggf. aus dem L2 in den L3 geschrieben werden, sondern nur, dass in der Regel die Daten im L3 landen, wenn die Daten bewusst per store in den Arbeitsspeicher geschrieben werden, weil dann auch sicher ist, dass die Daten fertig sind.

In deinem Fall - L3 ist eben nicht inclusive - müsste die die Cache-Verwaltung im Kern dann sehr bewusst entscheiden, dass die Daten die nun heraus fallen, weil sie am ältesten sind und lange nicht benutzt wurden, noch in den L3 verschoben werden sollen. Das ist durchaus möglich, macht aber die Verwaltung wieder komplexer. Frage ist, wie komplex AMD ihre Cacheverwaltung dann gestaltet und welchen Nutzen es hat.

 

[Esenel]

Eine glasklare Angelegenheit was das Preis-Gaming-Leistungsverhältnis anbelangt.
Anhang anzeigen 1200681

Die Bullshit Skala wurde gesprengt.
Was du da mit Power Point gezeichnet hast lässt sich kaum in Worte fassen :-D
Erste Designrichtlinie.
"Never use 3D bar charts"

Zum Thema:
Diese Platform kosten sind so unglaublich aus der Luft gegriffen und bilden nur eine mögliche Kundengruppe ab.

Kunde hat AM4 + DDR4 + Netzteil + Rest.

Laut deiner Power Point wird diesem Kunden verweigert das Netzteil zu behalten und er wird gezwungen DDR5 zu nehmen ohne ersichtlichen Grund. Stehst du hinter diesem und zwingst ihn dazu?

Man könnte aber auch einfach NT+DDR4 behalten. Sachen gibts. Dann ist man bei um die 600-700€ für ein Upgrade. Setzt aber auf eine Platform die noch eine weitere CPU Gen aufnehmen kann.

Neuanschaffungen lässt du gleich mal außen vor. Gibts nicht.

Wie schon erwähnt. Totaler Unfug diese Grafiken. Sowohl aus visueller und informativer Betrachtung.

 

[nitech]

Kann man eingentlich irgenwie aus Erfahrungen der Vergangenheit abschätzen welche Spiele bzw. Engines vom Chache profitieren? Da scheinbar meinem B350 MB ein dritter Frühling (1600x->3700x->5800x/3d) bevorsteht stellt sich nur mehr für mich die Frage ob sich das Warten/der Aufpreis auf 3d lohnt. Leider wird mein Spiel: WoW selten getestet und profitierte eben auch von CPU Power.
mfg

 

[therealcola]

Die Bullshit Skala wurde gesprengt.
....

Ich glaub das soll nen Meme sein ^^
Fehlt nurnoch ne weiße Flüssigkeit auf dem Kopf von Ruby dann ist das Meme perfekt !

 

[Ned Flanders]

@DevPandi

Ja, ich wollte dich ja auch nicht korrigieren sondern nur ergänzen.

 

[Zer0Strat]

Die Bullshit Skala wurde gesprengt.

Joar, das ist halt absoluter Worst-Case. Was es meme-artig macht, ist, dass gegen den Best-Case verglichen wird. ^^

Aber mal dumm gefragt, was soll 100 vs. 110 bedeuten?

 

[t3chn0]

@Zer0Strat

Ich befürchte es soll die relative Leistung darstellen.

Also ich hab keine 1500EUR für Board und CPU bezahlt ^^.

 

[Zer0Strat]

Ich befürchte es soll die relative Leistung darstellen.

Moooment, wir haben P/Euro=110 bei 500 Euro Investionskosten und P/Euro=100 bei 1500 Euro Kosten für Alder Lake, dann heißt das also, dass P_Zen/500 = 110 und P_ADL/1500 = 100 => P_Zen = 500*110 und P_ADL = 100*1500 => P_ADL/P_Zen = 100*1500/(500*110) ~=2.73. Respekt, ADL ist fast dreimal so schnell.

Ja, die Bullshit Skala wurde tatsächlich gesprengt.

 

[Esenel]

Aber mal dumm gefragt, was soll 100 vs. 110 bedeuten?

100 BE vs 110 BE (Bullshit Einheiten) auf der Bullshit Skala.

 

[DevPandi]

Ja, ich wollte dich ja auch nicht korrigieren sondern nur ergänzen.

Okay dokay, dann hab ich da etwas überreagiert. Entschuldige.

Im Endeffekt muss man bei dem Thema auch beachten, dass Firmen ungerne ihre Cache-Verwaltungen, Branchprediction und Co wirklich umfassend vorstellen und offen legen, weil man damit auch andere Firmen in die Hände spielt.

Das, was ich bisher an Informationen aus Whitepapern habe, spricht dafür, dass AMD beim L3 darum bemüht ist die Logik möglichst einfach zu halten. Das deckt sich auch mit den Aussagen von AMD selbst zu den Szenarien die vom größeren L3 nun profitierne und was eben nicht profitiert.

 

[Ned Flanders]

Kann man eingentlich irgenwie aus Erfahrungen der Vergangenheit abschätzen welche Spiele bzw. Engines vom Chache profitieren?

Als grobe Richtlinie kannst du davon ausgehen, dass Spiele profitieren werden, die bislang auf Zen3 stark von RAM OC (Latenzen) profitiert haben. Wie das bei WoW aussieht, kann ich Dir nicht sagen.

@DevPandi Keine Ursache

 

[nitech]

Als grobe Richtlinie kannst du davon ausgehen, dass Spiele profitieren werden, die bislang auf Zen3 stark von RAM OC (Latenzen) profitiert haben. Wie das bei WoW aussieht, kann ich Dir nicht sagen.

Danke, hab was gefunden dass WoW sehr wohl von RAM OC profitiert. Dann mal schaun ob wirklich wie angekündigt Morgen das Biosupdate kommt. Schwanke noch zwischen den 2 :-)
mfg

 

[Gortha]

Und das hier ist das Ziel:

Interessiert keine Sau, beim 5800X3D geht es um Spiele. Nicht Geekbench oder Workstation-Lasten.
Wie man in AMDs Benches sehen konnte, zieht der 5800X3D wahrscheinlich leicht am 12900K vorbei.

 

[incurable]

Interessiert keine Sau

Wenn das die bisher vorhandenen Ergebnisse sind, sind das die Größen, die man vergleichen kann.

Wenn der Besitzer (oder jemand, der kurz mal nach Belgien kann/will) Ergebnisse aus Spielen veröffentlicht kann man dann auch diese vergleichen.

 

[random12345]

Eigentlich scho krass das der grösste Teil der CPU Fläche gar nicht für das Rechnen da ist, sondern für das Ausbügeln der Probleme die mit digitalem Rechnen kommen.

 

[cookie_dent]

Ich bin einmal mehr überrascht wie hoch die Erwartungen an die CPU sind.
Offensichtlich reicht etwas mehr Gamingleistung für viele User um so einen hohen Preis zu rechtfertigen.
Das man aktuell 50% mehr Kerne für 10% weniger Geld aus gleichem Hause bekommt ist für viele kein Kaufargument mehr, vor nicht allzu langer Zeit war es das einmal.