News Intel Arrow Lake-S: P-Cores bekommen mehr L2-Cache, LGA-1851-Samples gesichtet

[7H0M45]

Es läuft Wahrscheinlich auf das Gegenteil von HT/SMT hinaus: Ein Kern kann nicht mehr mehrere Threads bearbeiten, sondern mehrere Kerne können gleichzeitig am selben Thread arbeiten.

Wie genau geht das? Es gibt ja Berechnungen welche nicht parallelisiert werden können, wie soll so etwas auf zwei Kerne aufgeteilt werden?

 

[BAR86]

Weil mit Royal Core die CPUs wie wir sie heute kennen sowieso über den Haufen geworfen werden. Stichwort Rentable Units, wie MLID es nennt. HT wird es dann sowieso nicht mehr geben.Also munkelt man, dass Intel es auf den letzten Architekturen vor dem eigentlichen Royal Core Start schon deaktiviert.

bei MLID aufpassen. Manchmal treffen seine vielen hinausposaunten Aussagen zu, oft sind sie aber auch frei erfunden (für die Klicks)

Ergänzung (13. August 2023)

Wie genau geht das? Es gibt ja Berechnungen welche nicht parallelisiert werden können, wie soll so etwas auf zwei Kerne aufgeteilt werden?

Genau. Du findest einige Artikel online die inverses multithreading zum Thema hatten.
Im C'T "Prozessorgeflüster" wurde früher auch manchmal von Testchips berichtet
Gerüchte dazu gibts übrigens seit über 10 Jahren https://www.hardwareluxx.de/communi...single-thread-leistung-beschleunigen.1084298/

 

[latiose88]

also eines weis ich ,wenn alles in den L1 oder L2 Cache rein passt,dann muss weniger oder garnicht in de L3 Cache geladen werden.Das spart zeit und erhöht die Geschwindigkeit.
Bei sehr hohen CPU Takt,spielt der Cache dann allerdings wieder ne Rolle.
Wie weit die Abhängigkeit geht,kann ich nicht sagen.
Und wie weit L2 Cache Einfluss hat,ist ne gute Frage.Weil was ist wenn durch die Verdoppelung von L2 Cache der L3 Cache halbiert werden kann.
So kann man nicht sagen ob von 512 KB auf 1024 kb L2 Cache bei AMD so einfluss drauf hat,das dann L3 von 64 auf 32 MB Cache halbiert werden kann.
Auch spielt die Missrate bei L1,L2 und so weiter ne Rolle.Ist diese allerdings schon so gering das diese nahe bei Null liegt,spielt die Rolle bei Cache immer weniger.Der Einfluss wird also immer geringer.Ist ja nicht nur bei AMD so sondern ja auch bei Intel nicht wahr?

 

[Telechinese]

wenn Singlethread Leistung gefragt ist schalten sich einfach 2 Kerne zusammen und bearbeiten den Thread zusammen.

Danke für die Info... warum man das nicht schon längst umgesetzt hat?
Das is ja viel logischer als der Mist mit "Ein Kern kann zwei Threads" - das is (meiner Meinung nach) ja sowieso totaler Bullshit - und die Angriffsvektoren zeigen das auch! HT ist Murks!
Da könnte man dann CPUs mit - sagen wir - 100 winzigen (kleinen) Kernen erzeugen, die sich nach Bedarf "zusammenschließen" lassen um größere Aufgaben zu lösen.
Ist das nicht nötig, können sie einzeln vor sich hinarbeiten mit total wenig Ernergieverbrauch 👍
Defakto eine "skalare" CPU. Das wär's...

 

[Lutscher]

Und wer NOCH länger zurückblickt, kommt schnell bei 0 an, wie z.B. der Covington an.
Dieser war mit seinen 266 Mhz langsamer war als 200 Mhz der Vorgänger-Generation Pentium 1. Nur aufgrund des fehlenden Caches...

Dafür war der Nachfolger Mendocino umso besser, dort lief der Cache auch gleich mit vollem CPU Takt.
Ich hatte so eine CPU auf einem Abit BX6 2.0 auf 450MHz übertaktet, der lief wie die Hölle.

In Sachen Cache war der K6-III auch noch sehr interessant.

 

[bensen]

@bensen
Ich kann dir technisch in keinster Weise zustimmen.

Weil du dich mit den Argumenten gar nicht befasst.

Zum einen übersiehst du von Beginn der Diskussion an den allerwichtigsten Punkt: So gut wie jeder (integrierte) Cache ist sinnvoller als ein externer/weiterer Zugriff... genau deshalb gibt es sie überhaupt.

Hat nichts mit dem Thema zu tun, habe ich oben schon geschrieben. Es geht nicht um kein Cache oder Cache. Schneller als der Hauptspeicher ist kein ausreichendes Kriterium.
Habe ich jetzt schon mehrfach geschrieben.

Dann gibt es noch den Punkt den du übersehen hast: Daten können von oben nach unten geschoben werden

Die Cache-Hirarchie habe ich selber mehrfach genannt. Deswegen macht es wenig sind niedrigere Cache-Level extrem groß zu machen. Aber auch mehrere Cache-Stufen kommen mit dem Nachteil daher, dass die oberen Stufen und letztendlich der Speicherzugriff eine höhere Latenz haben. Es ist immer ein trade-off.
Warum du hier die inklusivität und Spiel bringst erschließt sich mir nicht. Hat damit nur am Rande zu tun. Und ist auch nicht erst seit Mehrkernorozessoren ein Thema.

Du schreibst fast als ob Spannung ziemlich egal wäre... ganz und gar nicht!

Was soll das? Ich schrieb dazu gar nichts, weil es nichts mit dem Thema zu tun hat. Was sollen diese Unterstellungen?

Warum verkleinert man?Um mehr auf die selbe Fläche zu bekommen und Material zu sparen - in der Regel auch um die Spannung senken zu können.

Und um kürzere Signalwege zu erhalten um größere Caches realisieren zu können.

Ryzen 3D hat diese Falschbehauptung bereits widerlegt.

Lies einfach was ich geschrieben habe!
Im planaren ist das der Fall. Der dritte Dimension ist ein Kniff um Signalwege kurz zu halten. Klappt aber eben Stand heute nur bei vergleichsweise großen und langsamen LLC. Das funktioniert nicht für den L2.

Ich sprach nicht davon etwas langsamer zu machen,

Wird der Cache automatisch wenn du ihn größer machst.

Und bevor du weiter an meinem Thema vorbeireden magst (ich werde nicht abweichen), du kannst auch Cache schneller machen - denke mal an Zyklen.

Ja indem man ihn kleiner macht oder die Bandbreite reduziert oder die Assoziativität verringert.

Wenn du schreibst "hat nichts mit Level 2" zu tun darf ich lachen, denn alles beginnt ganz oben - mit dem ursprünglichen Rechenauftrag.

Was soll das bedeuten?

Auch Intel widerspricht dir jetzt, sie wollen den Cache vergrößern. Warum tun sie das? Leistung. Vielleicht überdenkst du diesen Beitrag nochmal.

Warum wird er nur 3 MB groß und nicht 6 MB? Denk mal drüber nach. Nach deiner Logik würde man mit 6 MB deutlich schneller sein. Ist aber nicht der Fall.
Durch den Shrink kann man den Cache vergrößern bei gleicher Latenz. Aber eben nicht unbegrenzt.

Mein Einwand war lediglich: Warum nicht noch mehr als das gebotene... technisch ist es drin.

Nicht beim L2 Cache. Ein L4 Cache würde helfen. Der müsste aber sehr groß sein, da man mit einer zusätzlichen Stufe auch alle Speicherzugriffe verlangsamt.
Die Gerüchteküxhe spricht ja von einem optionalen L4 Cache für Meteor Lake.

 

[Tzk]

Ich verstehe hier diese seitenlange Diskussion um den Cache auch nicht. Die Latenz (in Zyklen) des Cache steigt mit seiner Größe, das ist als Fakt zu betrachten und gilt für alle Level, also L1 bis L4 und in Teilen auch für den RAM. Deshalb stuft man das ab… L1 ist klein und hat eine Latenz von unter 20 Zyklen, RAM liegt um ein Vielfaches darüber.

X3D nimmt dabei eine Sonderrolle ein, weil amd quasi den normalen L3 mit passender Latenz und Signallaufzeit für X3D entworfen hat. Deshalb gilt das Argument dort nicht. Andersrum wäre der L3 von Zen3 und 4 vermutlich schneller, würde das X3D Interface fehlen.

Generell tut jeder Zyklus weh, in dem die CPU nichts tut. Daher kommt sowohl das out-of-Order Design, als auch HT als auch die spekulative Ausführung. Alles soll die Auslastung der Rechenwerke maximieren und so die IPC erhöhen. Intels Atom Produktlinie müsste eins der letzten in-oder Designs gewesen sein, wobei Intel bei den E-Kernen davon abgekehrt ist. Die sind ja irgendwie als Nachfolger von Atom gedacht.

 

[andi_sco]

Precott hatte damals eine Pipeline von fast 50 Stufen - also 50 Cycle.

31 Stufen.
50 sollten erst mit der übernächsten Generation eingeführt werden!
Die Daten stimmen nicht zu hundert Prozent, weil die Generation gekippt wurde:

Aber so ungefähr sah der Plan aus

 

[latiose88]

Ja darum sehe ich den Ansatz von AMD auch den richtigen Weg. Es gibt Anwendung die von größeren Cache kein Nutzen davon ziehen und stattdessen durch den höheren Zyklus dann an Leistung verlieren. AMD hat mit l2 cache 1 MB wirklich nen super schnellen Cache.
Bei Intel merke ich davon ja eben nix. Nur dank der sehr hohen Taktrate konnte sich die vielen Kerne behaupten.
Ich dachte immer die miss rate käme aufgrund zu wenig cache ram weil ja nur ne gewewisse Menge darin Platz hat. Das was in den Cache kommt und was nicht scheint wohl jede CPU der jeweiligen Herstellers anders zu handhaben.
Habe zwar von überlaufenen Cache noch nie was gelesen gehabt soll es jedoch auch gewiss bei welchen Programmen geben.
Ich frage mich nur wer von viel Cache profitiert als das es die Nachteile von höheren takt Zyklus ausgleichen kann.

Meine Anwendungen scheinen dem wie die meisten zu reagieren. Entweder garnicht oder es gibt bei mehr Cache weniger Leistung.
Bei mir hat sich durch den doppelten l3 Cache weniger Leistung gezeigt. Über den l2 cache kann ich nix sagen. Könnte ich die Menge beeinflussen um es zu sehen würde ich das ernsthaft machen.
Auf jedenfall nutze ich 2 gleiche Programme die sich ja den l1-l3 Cache teilen. Ab einer gewissen Größe wirkt sich das schon aus indem man den l3 csche halbiert bleibt beiden jeweils mit noch die Hälfte übrig.

Aus 32 wo pro Software 16 MB l3 sind es nach 16 MB dann jeweils 8 MB pro Software. Das ist dann so zu wenig das es dann Leistungs kosten tut.
Bei Intel habe ich diesbezüglich noch keinen solchen test durchgeführt, würde ich aber echt zugerne mal machen.

 

[foofoobar]

Weil mit Royal Core die CPUs wie wir sie heute kennen sowieso über den Haufen geworfen werden. Stichwort Rentable Units, wie MLID es nennt. HT wird es dann sowieso nicht mehr geben.Also munkelt man, dass Intel es auf den letzten Architekturen vor dem eigentlichen Royal Core Start schon deaktiviert.

Allerdings wird das erstmal in der Praxis zu bewähren haben.

 

[DevPandi]

Wie genau geht das? Es gibt ja Berechnungen welche nicht parallelisiert werden können, wie soll so etwas auf zwei Kerne aufgeteilt werden?

Im kleinen wird zur Zeit bereits genau das auf Kern-Ebene gemacht, in dem man sich die Nebenläufigkeit der Anweisungen ausnutzt und entsprechend auf mehrere Rechenwerke im Kern verteilt.

Grob - nur zur Veranschaulichung - besteht ein Golden Cove/Raptor Cove Kern aus 12 "Kernen" (Ports). Die CPU kann dann im Re-Order-Buffer (Out-of-Order-Architektur) die Befehle so sortieren, dass die auf die 12 Kerne verteilt werden.

Der Gedanke, dass zwei Kerne an einem Thread arbeiten, würde sich genau dieser Prämisse bedienen, dass es eben Befehle gibt, die voneinander losgelöst ausgeführt werden können. Das ist aber nicht so trivial, wie man denkt. In einem Kern mit mehren Rechenwerken funktioniert das relativ gut, weil hier das Register-File das gleiche ist und die Daten nicht synchron gehalten werden müssen. Bei 2 Kernen mit dem selben Thread sieht das anders aus.

50 sollten erst mit der übernächsten Generation eingeführt werden!

Ja, da kommt man mit der Zeit durcheinander. Ich hatte die 50 im Kopf, aber auch die 31 waren damals richtig lang.

Da sind die um die 15 Stufen heute immer noch richtig Kurz.

 

[foofoobar]

31 Stufen.
50 sollten erst mit der übernächsten Generation eingeführt werden!
Die Daten stimmen nicht zu hundert Prozent, weil die Generation gekippt wurde:

Und dann war da noch die legendäre CPU mit 10GHz Takt von Intel :-)

 

[Piktogramm]

Wie genau geht das? Es gibt ja Berechnungen welche nicht parallelisiert werden können, wie soll so etwas auf zwei Kerne aufgeteilt werden?

Danke für die Info... warum man das nicht schon längst umgesetzt hat?
Das is ja viel logischer als der Mist mit "Ein Kern kann zwei Threads" - das is (meiner Meinung nach) ja sowieso totaler Bullshit - und die Angriffsvektoren zeigen das auch! HT ist Murks!
Da könnte man dann CPUs mit - sagen wir - 100 winzigen (kleinen) Kernen erzeugen, die sich nach Bedarf "zusammenschließen" lassen um größere Aufgaben zu lösen.
Ist das nicht nötig, können sie einzeln vor sich hinarbeiten mit total wenig Ernergieverbrauch 👍
Defakto eine "skalare" CPU. Das wär's...

Prozessoren sind vor langer Zeit superskalar geworden, es gibt je CPU also mehr als eine, gleichzeitig aktive Pipeline. Mit mehr Pipelines wird es aber schwerer diese Pipelines auch zu füllen. Der nahe liegende Gedanke war, ein und die selbe CPU "einfach" an zwei Threads gleichzeitig arbeiten zu lassen und so die Auslastung der Pipelines zu erhöhen. Der Aufwand ist vergleichsweise klein.

Um mehrere CPUs zusammenzuschalten braucht es deutlich mehr Aufwand. Zu aller erst braucht jede separate CPU ihr eigenes Frontend, muss bei der Speicherverwaltung ab L2 bis Arbeitsspeicher separat berücksichtigt werden und hängt einzeln oder in Clustern auch als Last am zentralem Bus des Chips. Wenn jetzt noch verlangt wird, dass diese CPUs dynamisch umschalten sollen zwischen dedizierterem Prozessor und einem Cluster aus Prozessoren wird es richtig kompliziert. Die betroffenen kleinen Prozis müssten ihren Zustand komplett in einen Speicherbereich sichern, sich umkonfigurieren und die Speicherverwaltung derart verbiegen, dass jede kleine CPU den Speicherbereich nutzen kann, der vom emulierten großen Kern zu nutzen ist.
Der Aufwand, die Komplexität und damit verbundenen Konsequenzen für die Sicherheit eskaliert und HyperThreading im Vergleich schaut aus wie ein Kinderspiel o.O
Und die Performance wäre auch mies. Die Auslastung von Pipelines ist extrem dynamisch. In einer kompakten Schleife können mitunter 6..8Pipelines voll gefüllt werden. Kaum hat man ein paar bedingte Sprünge sinkt die Auslastung ganz fix auf <1 (also nur eine Pipelines benötigt, diese läuft aber leer weil auf Speicherzugriffe gewartet wird). Die Kontextwechsel deiner Idee wären also extrem häufig und würden jeweils viel Zeit benötigen. Das ist irre..

L1 ist klein und hat eine Latenz von unter 20 Zyklen

Zen3 L1D: 4Zyklen, L2: 12Zyklen, L3 49Zyklen

20Zyklen für L1 wäre wirklich scheiße. Erfolgreicher Zugriff auf L1 würde bedeuten, dass derweil alle Pipelines moderner CPUs leer laufen. (Unter Ignoranz von Prefetchmechanisen)

 

[xexex]

Gerüchte dazu gibts übrigens seit über 10 Jahren

Es gab ja nicht nur "Gerüchte", Intel hat seinerzeit die Firma die dahinter Stand gekauft.

https://www.blopeur.com/2021/10/30/Intel-VISC-Processor-Architecture-Patent.html

 

[Tzk]

Zen3 L1D: 4Zyklen, L2: 12Zyklen, L3 49Zyklen

20Zyklen für L1 wäre wirklich scheiße. Erfolgreicher Zugriff auf L1 würde bedeuten, dass derweil alle Pipelines moderner CPUs leer laufen. (Unter Ignoranz von Prefetchmechanisen)

Danke für die Ergänzung! Und ja, 20 wäre Mist. Vier ist aber auch unter 20 War mir mit der Zahl nicht ganz sicher, deshalb so ein hoher Wert... Die x86 Pipelines müssten (aus den Kopf) aktuell ebenfalls unter 20 Stufen haben. So 16 oder 18?

 

[mcmurphy100]

Mir schon länger ein Rätsel warum nicht stetig der Cache erweitert wird. Dann könnte man die Taktrate noch leicht herunterschrauben, den Verbrauch (Spannung) dadurch reduzieren und wieder mehr Cache dranpacken.

Spätestens seit Release des Broadwell war klar das dieser Weg Zukunft hat.

Der Cache belegt pro Kern eine gewisse Die-Fläche, multipliziert mit der Anzahl der Kerne.
Jeder Quadratmillimeter kostet bares Geld und hat auch Auswirkungen auf den Yield.

Wenn alle paar Jahre mal eine Verkleinerung der Fertigungstechnologie möglich ist, muss man gut abwägen, wieviel Kerne vs. wieviel Cache pro Kern man einsetzen will und was dies performancemäßig bringt.

 

[Duran]

Ich brauche aktuell keine zusätzlichen Kerne, 20 bis 24 sind schon sehr ausreichend dimensioniert.
Nutze teilweise Programme die kaum über 3-4 hinaus gehen und Komprimieren ist nicht mehr so häufig wie früher.

Bei 64 Cores sind 256 Megabyte Cache nicht mehr besonders viel, das werden wir alles sehen zukünftig.
Extreme Taktrate war damals nicht zu schaffen und irgendwann ist auch dieses Design am Ende. Daher braucht man weitere Wege...
Der Stromverbrauch ist zuletzt auch ein viel größeres Thema geworden. Man merkt ja schon bei den aktuellen Modellen wie sich das auf die Raumluft auswirken kann, da wird niemand noch das doppelte oder dreifache daheim haben wollen.

 

[DevPandi]

Die x86 Pipelines müssten (aus den Kopf) aktuell ebenfalls unter 20 Stufen haben. So 16 oder 18?

Für Sunny Cove habe ich 14 gefunden. Wird sich also um die 15 bewegen.

Danke für die Ergänzung! Und ja, 20 wäre Mist. Vier ist aber auch unter 20 War mir mit der Zahl nicht ganz sicher, deshalb so ein hoher Wert...

Eine relativ einfache Regel für den L1-Cache: Maximal die hälfte der Pipeline-Tiefe. Also bei 15 sollte der L1-Cache maximal 7 Takte benötigen für die Antwort. Dann ist die Gefahr, dass die Pipeline leerläuft relativ gering. Besser ist maximal 1/4.

 

[Tzk]

Der Stromverbrauch ist zuletzt auch ein viel größeres Thema geworden. Man merkt ja schon bei den aktuellen Modellen wie sich das auf die Raumluft auswirken kann, da wird niemand noch das doppelte oder dreifache daheim haben wollen.

Der sinnvolle Stromverbrauch ist eigentlich recht konstant, seit gut 20 Jahren... Mit sinnvoll meine ich den Sweetspot mit guter bzw. bester Effizienz (Rechenleistung zu Stromverbrauch). Wenn man mal schaut was ein aktueller AMD oder Intel mit unter 80W zu leisten im Stande ist, ist diese Leistung beachtlich. Darüber skaliert das Silizium denkbar schlecht und man erhält nur wenig Mehrleistung für viel mehr Verbrauch/Abwärme.

An der Stelle muss man sich also fragen warum AMD und Intel für ein paar Prozente extra so viel Strom verballern. Klar, 10% Leistung bedeutet einen Sprung von einer Generation...

 

[Telechinese]

An der Stelle muss man sich also fragen warum AMD und Intel für ein paar Prozente extra so viel Strom verballern.

Das frag ich mich auch schon länger...
Seh ich an meinem i9-9900
Ab 95W aufwärts steigt die leistung nurnoch im einstelligen Prozentbereich, aber der Stromverbrauch... alter Schwede 🤪🤪