News Intel Nova Lake aus N2P-Fertigung: 8P+16E-Kerne samt 144 MB L3-Cache werden ~150 mm² groß

Perdakles schrieb:
Da fehlt eine Instanz die von ganz oben drauf guckt und dann feststellt:
"Hey es wäre besser jetzt die E-Cores zu benutzen, obwohl die Anwendung idealerweise auf den P-Cores laufen sollte." Genau deshalb gibt es ein OS basiertes Scheduling.
Wie soll diese Entscheidung konkret anhand welcher Metriken stattfinden?
Piktogramm schrieb:
Was gut funktioniert, bis irgend ein anderer Thread mal Bumms braucht, der aber nicht im Kontext vom Spiel läuft. Dann hängt zum Beispiel der Compiler vom Grafikstack auf irgend einem kleinem Kern bzw. kleinem CPU-Thread und der ganze Bumms stottert weil es zu lang dauert.
Im Fall von Spielen ist eh nur eine Anwendung relevant.
Nighteye schrieb:
Die 600W GPU ist doch genau so geisteskrank wenn wir ehrlich sind :D
Ich hab keine Klima Anlage in der Wohnung, lange Zocksessions in Heißen Sommernächten stell ich mir damit unglaublich ungemütlich vor, wenn ich schon bei den 150W meiner GPU merke wie der Raum sich im Sommer erwärmt nach 60 Minuten :D
Dein Körper produziert bereits über 100 Watt Abwärme im Ruhezustand.
 
Nighteye schrieb:
zurück zu Hyperthreading für alle Kerne etc.
Zumindest der Punkt ist ein viel größeres Thema im Server (Diamond Rapids) als im Client (Nova Lake). Es stellt sich halt die Frage, ob man mit ein paar Prozent mehr Chipfläche einen E-Core baut, oder SMT ermöglicht. Nova Lake hat halt E-Cores als "flächengünstige" Variante, um mehr Leistung zu bekommen. Obendrauf auch noch SMT wäre sicherlich nicht verkehrt (auch wenn es das ganze nochmal komplexer macht), aber zumindest ist da auf diese Art effizient genutzte Fläche vorhanden.

Diamond Rapids hingegen hat gar nichts dergleichen. Und das wird Intel weh tun.
 
  • Gefällt mir
Reaktionen: Convert
foofoobar schrieb:
Dein Körper produziert bereits über 100 Watt Abwärme im Ruhezustand.
Meine Partnerin zockt auch noch im gleichen Raum wie ich. Sind dann 200W Menschen.
Dennoch bleibt unser Raum im Sommer Kühl trotz stunden Zock session.
Meine Partnerin und ich haben Zen 3 & RDNA 2 Technik, CPU,s unter 60W und GPU,s unter 150W (RX6700 & RX6800 Undervolted), wir haben keine großen Probleme im Sommer, obwohl wir keine Klima Anlage haben.
(Und das bei 100% CPU & 100% GPU Last in Star Citizen)
Man stelle sich vor wir hätten einen 14900K oder noch schlimmer, Nova Lake und eine RTX 5090.
900-1000W Minimum für den PC bei Volllast, und nochmal 80W durch den Monitor und nochmal 100W pro Mensch.
Schon mein Staubsauger verbraucht 700W. Man stelle sich vor man hat permanent 3 Staubsauger neben sich an. (Das wären dann diese 2100W)
Ohne Klima Anlage kann man so im Sommer nicht Zocken. Da stirbt man.
 
BAR86 schrieb:
Inwiefern?
Wenn bei AMD 80mm² (bei 12 Kernen)+ Cache hat und Intel 110mm² (bei 4+8+16 Kernen + Cache auf 150 kommt, nimmt man sich da nicht besonders viel. Interessant wirds bei den "kleineren" Kernen, die Intel selbst fertigt. Macht AMD hier auch extra DIEs unter 12 Kernen?

Machen sie jetzt schon: Strix Point (12), Krackan (8); und dann haben sie noch Phoenix 2 mit 6 Kernen und Mendocino mit 4, vielleicht habe ich auch einige uebersehen.

Ich gehe einmal davon aus, dass AMD ab Zen6 mit dem besseren chiplet-Verfahren von Strix Halo arbeiten wird, und wir dann mehrere CCDs (vielleicht 12 und 8 Zen6, und 24 oder 32 Zen6c oder so) und mehrere IODs (mit starker oder schwacher Grafik) haben werden, und damit all ihre hoeherpreisigen CPUs und APUs bauen werden; alternativ wird die starke Grafik als eigener die eingebunden (oder eben nicht). Ausserdem werden sie fuer den Billigmarkt noch einen monolithischen Nachfolger fuer Phoenix2 haben. Alles Spekulation ohne Geruechtegrundlage.

Zurueck zum Thema: Ich gehe davon aus, dass das CPU-die von Nova Lake mit dem grossen Cache ein Halo-Produkt mit relativ geringer Stueckzahl sein wird. Da das aber trotzdem einen eigenes Maskensatz braucht (mit Kosten in 8-Stelliger Hoehe), muessen die Maskenkosten von diesen wenigen Stueck hereingespielt werden, wenn sie nicht ueber das Marketing-Budget von anderen Produkten querfinanziert werden sollen. Da ergeben sich schon aus den Maskenkosten ordentliche Preisaufschlaege. Und da es in der Variante mit zwei solchen dies auch Leistungsmaessig zumindest bei bestimmten Benchmarks einen grossen Vorsprung haben wird, wird Intel auch entsprechend verlangen. Der Rest von uns greift dann zum Intel-Produkt mit einem CPU-die mit 36MB L3, oder eben zu einem AMD-Produkt.
 
foofoobar schrieb:
Wie soll diese Entscheidung konkret anhand welcher Metriken stattfinden?
Metriken, die einer zentral steuernden Komponente (OS-Scheduler) nun einmal vorliegen:
  • Auslastung einzelner Kerne
  • Angemeldeter Rechenbedarf aller Anwendungen
  • Priorisierung der Anwendungen/Threads
  • CPU-Architektur
  • Anzahl logischer und physikalischer CPU-Kerne
  • Art der Kerne (P-Core, E-Core, LPE-Core)
  • Eingestelltes Energieprofil
  • Verbleibende Akkukapazität (bei Laptops)
  • ...

Dein Vorschlag mit den Anwendungen die sich selbst schedulen, bedarf einer Implementierung dieser überaus komplexen Aufgabe in JEDER EINZELNEN ANWENDUNG. Das ist komplett unrealistisch, absolut fehleranfällig und kompletter Overkill. Da müsste dann ja jeder SW-Entwickler sich mit dem ganzen Kram bestens auskennen und auch noch "fehlerfrei" implementieren.
Warum nicht auch gleich die Speicherverwaltung an die Anwendungen abgeben? Ist bestimmt auch viel effizienter... nicht :D.
Das wäre ein einziges Blutbad und du könntest froh sein, wenn der Rechner mal fünf Minuten ohne Abstürze läuft. Nichts für Ungut aber das ist kompletter Stuss.
foofoobar schrieb:
Dein Körper produziert bereits über 100 Watt Abwärme im Ruhezustand.
Das ist korrekt, daran kann man jedoch nichts ändern. Die Entscheidung für/gegen effiziente HW können wir aber sehr wohl beeinflussen. Und damit kann man dann auch indirekt die Erhitzung des Raums beeinflussen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Nighteye und stefan92x
Perdakles schrieb:
Dein Vorschlag mit den Anwendungen die sich selbst schedulen
...ist nur in sofern möglich, als dass Anwendungen selbst ansagen könnten, welcher ihrer Threads der wichtigste ist und welcher weniger hoch priorisiert ist. Das sind Infos, die das OS sinnvoll berücksichtigen kann. Mehr aber auch nicht.
 
  • Gefällt mir
Reaktionen: Perdakles
stefan92x schrieb:
Zumindest der Punkt ist ein viel größeres Thema im Server (Diamond Rapids) als im Client (Nova Lake). Es stellt sich halt die Frage, ob man mit ein paar Prozent mehr Chipfläche einen E-Core baut, oder SMT ermöglicht. Nova Lake hat halt E-Cores als "flächengünstige" Variante, um mehr Leistung zu bekommen. Obendrauf auch noch SMT wäre sicherlich nicht verkehrt (auch wenn es das ganze nochmal komplexer macht), aber zumindest ist da auf diese Art effizient genutzte Fläche vorhanden.
Da sieht man sehr schön wie sich Intel mit seinen ganzen Varianten verzettelt, und Kohle zum Fenster raus wirft wegen fehlender Modularität.
 
@Volker Volker kannst du eigentlich mal erklären warum DDR6 für NVL-S jetzt nicht kommt? Es hieß doch in den Gerüchten es würde so kommen und falls nicht wäre das ein erstes Flop-Signal. Und was ist mit PCIe6?

Davon hört man auch nichts, anscheinend kommt es nicht und es kommt nur DDR5+PCIe5, wie Arrow-Lake.
 
Nighteye schrieb:
Aber er will von allem abkehren was mit Nova Lake zu tun hat.
Quasi alles über Board werfen. Wieder Zurück zu Klassischen Intel CPU,s ohne überforderten Ringbus der 3 Verschiedene Kerne Managen muss, und zurück zu Hyperthreading für alle Kerne etc.
Du kannst das sicherlich mit Quellen belegen.
Ergänzung ()

foofoobar schrieb:
Da sieht man sehr schön wie sich Intel mit seinen ganzen Varianten verzettelt, und Kohle zum Fenster raus wirft wegen fehlender Modularität.
Fehlende Modularität hat man seit Meteor Lake gerade nicht.
 
Artanis90 schrieb:
@Volker Volker kannst du eigentlich mal erklären warum DDR6 für NVL-S jetzt nicht kommt? Es hieß doch in den Gerüchten es würde so kommen und falls nicht wäre das ein erstes Flop-Signal. Und was ist mit PCIe6?

Davon hört man auch nichts, anscheinend kommt es nicht und es kommt nur DDR5+PCIe5, wie Arrow-Lake.

Es baut keiner DDR6, ganz einfach^^ Da ist jetzt nicht Intel dran Schuld, aber kann man natürlich mal behaupten und direkt nen Flop ausrufen.
Und PCIe 6? Wozu? Das ist immer noch ein Mainstream-Produkt!!

Beides sind Technologien die zuerst in den Server kommen - und da markiert AMD Venice im zweiten Halbjahr dieses Jahres dann wohl das erste Produkt, zumindest PCIe 6, aber auch kein DDR6 btw^^. Was aber nicht heißt, dass Ryzen 10000 das dann auch mitbringt - weil auch hier wieder: Wozu^^
 
  • Gefällt mir
Reaktionen: Deinorius, Perdakles und Artanis90
Artanis90 schrieb:
@Volker Volker kannst du eigentlich mal erklären warum DDR6 für NVL-S jetzt nicht kommt? Es hieß doch in den Gerüchten es würde so kommen und falls nicht wäre das ein erstes Flop-Signal. Und was ist mit PCIe6?
Welches Gerücht soll das gewesen sein? DDR6 ist noch weit weg und stand für Nova Lake eigentlich nie zur Debatte. Wird auch der Nachfolger nicht haben. Das hat nichts mit Intel zu tun, es gibt den Speicher einfach noch nicht.
Und PCIe 6.0 kommt dieses Jahr erst in das server Segment. Der Aufwand wird immer größer. Das wird noch 2-4 Jahre dauern. Der Nutzen im Consumerbereich steht halt in keiner Relation zum Aufwand.
Man kann mit PCIe 6.0 nur noch 7,5 cm Leitungslänge ohne Retimer realisieren.
 
  • Gefällt mir
Reaktionen: Volker
bensen schrieb:
Fehlende Modularität hat man seit Meteor Lake gerade nicht.
Zig verschiedene Cores mit unterschiedlichen Feature Sets mit eigenen Masken und unterschiedlichen Prozessen sind das komplette Gegenteil von Modularität.

Vergleich das einfach mal mit AMD.
Perdakles schrieb:
Metriken, die einer zentral steuernden Komponente (OS-Scheduler) nun einmal vorliegen:
  • Auslastung einzelner Kerne
  • Angemeldeter Rechenbedarf aller Anwendungen
  • Priorisierung der Anwendungen/Threads
  • CPU-Architektur
  • Anzahl logischer und physikalischer CPU-Kerne
  • Art der Kerne (P-Core, E-Core, LPE-Core)
  • Eingestelltes Energieprofil
  • Verbleibende Akkukapazität (bei Laptops)
  • ...
Schreibe ich nachher was zu.
Perdakles schrieb:
Dein Vorschlag mit den Anwendungen die sich selbst schedulen, bedarf einer Implementierung dieser überaus komplexen Aufgabe in JEDER EINZELNEN ANWENDUNG. Das ist komplett unrealistisch, absolut fehleranfällig und kompletter Overkill. Da müsste dann ja jeder SW-Entwickler sich mit dem ganzen Kram bestens auskennen und auch noch "fehlerfrei" implementieren.
Schau dir mal CSP bzw. "green Threads" an. Das ist bereits etabliert.
Ansonsten habe ich primär über pinning gesprochen. (https://man7.org/linux/man-pages/man2/sched_setaffinity.2.html)
Perdakles schrieb:
Warum nicht auch gleich die Speicherverwaltung an die Anwendungen abgeben? Ist bestimmt auch viel effizienter... nicht :D.
Das wäre ein einziges Blutbad und du könntest froh sein, wenn der Rechner mal fünf Minuten ohne Abstürze läuft. Nichts für Ungut aber das ist kompletter Stuss.
Welche einigermaßen ernsthafte Anwendung kommt den ohne eigene Speicherverwaltung aus?
Warum wohl gibt es verschiedenen Implementierungen von malloc oder von Garbage Collectors?
 
Zuletzt bearbeitet:
Nur weil man unterschiedliche Kerne verbaut, braucht man nicht unterschiedliche Masken. Irgendwie vermischt du hier was.

Und bei AMD ist es nicht so wenig. Drei APU, wobei Strix Halo auch noch eigene CCD hat. Im Serverbereich auch zwei CCD. Das ist nicht so viel weniger als bei Intel.
Wenn man dass dann noch auf die Stückzahlen hochrechnet.
 
foofoobar schrieb:
malloc oder von Garbage Collectors
Malloc und co. stellen aber nur Anfragen an das OS, welches dann einen entsprechenden Speicherbereich zuweist. Was ich mit Speicherverwaltung meinte ist, dass die Anwendungen sich dann anfangen selber freie Speicherbereiche zu suchen im RAM. Die Analogie zur Scheduling-Thematik war halt, dass das OS das viel besser zentral machen kann als wenn jede Anwendung das selber machen müsste.
Aber du hast Recht, das war missverständlich ausgedrückt.
 
bensen schrieb:
Und bei AMD ist es nicht so wenig. Drei APU, wobei Strix Halo auch noch eigene CCD hat. Im Serverbereich auch zwei CCD. Das ist nicht so viel weniger als bei Intel.
Doch, schon... nehmen wir mal nur Server, da verkauft Intel aktuell Granite Rapids und Sierra Forest. Die nutzen den gleichen IOD, Sierra Forest auch nur einen Core-Die, aber Granite Rapids tatsächlich drei verschiedene. Macht in diesem Markt vier vs zwei Core-Chiplets.

Bei Consumer-CPUs verkauft Intel aktuell Panther Lake und Arrow Lake als aktuelle Generationen. Da haben wir jeweils zwei verschiedene Core Chiplets (wenn ich mich gerade richtig erinnere), unterm Strich also genau so viele wie bei AMD mit dem Standard und Strix Halo CCD sowie den beiden monolithischen APU-Dies. Bei Intel führen die verschiedenen CPU-Dies aber zumindest auch noch zu unterschiedlichen Base-Dies (gut, die kommen aus 22nm, die sind eher unkritisch), während AMD innerhalb einer Produktkategorie nur einen IOD und flexibles Packaging (in dem SInne: ob man ein oder zwei CCDs bestückt, ist egal) nutzen kann. Der Zoo an produzierten Dies ist bei Intel definitiv größer (und dabei ignoriere ich sowas wie die GPU-Dies, dadurch hat Intel natürlich nochmal mehr, während AMD das in den IOD reinpackt, aber die Dies für Intel sind dann halt auch kleiner).
 
Ein Gedanke: Könnte es sein, dass das Chiplayout nicht anders gestaltet werden konnte, und man quasi ein bisschen Fläche zu füllen hatte und sich dachte "warum nicht? Warum sollten wir nicht ein paar E-Cores da hin setzen? Vielleicht finden wir sogar noch einen nutzbaren Nutzen dafür!".
Kann sowas beim Chipdesign passieren?
 
mae schrieb:
Machen sie jetzt schon: Strix Point (12), Krackan (8); und dann haben sie noch Phoenix 2 mit 6 Kernen und Mendocino mit 4, vielleicht habe ich auch einige uebersehen.
Entschuldige, ich meine quasi ihren Standard Chiplet für Desktop und Server, der ist seit Jahren 8 Kerne und man nimmt einfach so viel man will davon
 
Cr4y schrieb:
Ein Gedanke: Könnte es sein, dass das Chiplayout nicht anders gestaltet werden konnte, und man quasi ein bisschen Fläche zu füllen hatte und sich dachte "warum nicht? Warum sollten wir nicht ein paar E-Cores da hin setzen? Vielleicht finden wir sogar noch einen nutzbaren Nutzen dafür!".
Kann sowas beim Chipdesign passieren?
Unwahrscheinlich, dass so große Bereich frei bleiben. Im kleinen ist das durchaus normal und unvermeidlich (und genau dadurch sind auf Die-Shots dann klar abgegrenzte Bereiche erkennbar), aber da passt halt kein ganzer Core mehr hin.
 
  • Gefällt mir
Reaktionen: Cr4y
stefan92x schrieb:
Bei Intel führen die verschiedenen CPU-Dies aber zumindest auch noch zu unterschiedlichen Base-Dies (gut, die kommen aus 22nm, die sind eher unkritisch), während AMD innerhalb einer Produktkategorie nur einen IOD und flexibles Packaging (in dem SInne: ob man ein oder zwei CCDs bestückt, ist egal) nutzen kann.
Der Base Die ist nicht viel mehr als ein Interposer. Das hier mit aufzuführen ist nicht wirklich sinnvoll. Intel hat dadurch viele kleine Dies wie zum Beispiel die GPU (aktuelle Fertigung) in minimaler Größe. Dadurch vermeidet man große monolitische APUs, große Dies in moderner Fertigung.
Ich sehe auch nicht wo AMD den IO-Die wieder verwendet. Wird nur im Desktop verwendet wie auch der SoC Tile bei Intel.

Intel hat ein paar mehr Dies, aber das ist nicht mehr wirklich viel. Und wenn man dann noch die unterschiedlichen Stückzahlen betrachtet sieht es nochmal anders aus.

Intel hatte früher schon 4 Mainstream Dies zu 4 Kern Zeiten um da irgendwo noch 15 mm² zu sparen.
Hätten sie auch nicht haben müssen.
 
Zuletzt bearbeitet:
stefan92x schrieb:
Klar will man sowas nicht unbedingt auf den P-Cores haben, aber warum LPE statt E-Cores dafür nutzen?
Die Aktuellen Skymont E-Cores sind schon recht potent. Je nach Anwendung schwanken die bei Durchsatz (IPC) an Instruktionen je Takt zwischen Zen2 bis Zen4. Die Dinger sind für viele I/O-Aufgaben gnadenlos unterfordert. Es ist also prinzipiell kaum ein Nachteil die Aufgaben auf noch langsamere Kerne zu verteilen.
Dafür gibt es Nachteile E-Cores mit solchen Aufgaben zu belasten. Die Kerne wären belegt und sollte es etwas zu berechnen geben, müsste ein teurer Kontextwechsel erfolgen. Zusätzlich wollen euch I/O-Prozesse mit viel Warterei immer mal wieder arbeiten, knappern also am thermischem Budget und sind Konkurrenz auf L2- u. L3-Cache.

Nighteye schrieb:
Wieder Zurück zu Klassischen Intel CPU,s ohne überforderten Ringbus der 3 Verschiedene Kerne Managen muss, und zurück zu Hyperthreading für alle Kerne etc.
Wenn die kommenden Architekturen das nicht bereits mindestens als Option vorsehen, dann kann diese Vorstellung vergessen werden. Zudem Zeitpunkt, wo der Herr CEO wurde, hätte die Eingabe von SMT ins Lastenheft für zukünftige Architekturen kaum eine Chance gehabt. Bei Darkmont und den dreigeteilten Decodern stelle ich mir SMT auch schwer vor und die Kürzungen die Intel zuletzt bei der Softwareentwicklung betrieben hat passt nicht zum Aufwand der getrieben werden muss um SMT über P&E-Cores gescheit zu verwalten.
Cr4y schrieb:
Ein Gedanke: Könnte es sein, dass das Chiplayout nicht anders gestaltet werden konnte, und man quasi ein bisschen Fläche zu füllen hatte und sich dachte "warum nicht? Warum sollten wir nicht ein paar E-Cores da hin setzen? Vielleicht finden wir sogar noch einen nutzbaren Nutzen dafür!".
Kann sowas beim Chipdesign passieren?
Es kann durchaus vorkommen, dass bei der Synthese Flächen mit wenig bis keiner Belegung herauskommen. Die Flächen sind aber normalerweise damit begründet, dass die Flexibilität der IP-Blöcke und vom Routing der Signalleitungen/Energie ausgeschöpft sind. Das da rein zufällig mal noch ein CPU-Cluster samt Cache, Anbindung an den BUS möglich sein soll ist unrealistisch.
Ganz abgesehen davon, dass die Verwaltunglogik von modernen Prozessoren auch komplex ist. Da an einem Punkt wo man die Synthese die ersten male probiert, einfach mal einen neuen CPU-Cluster mit eigener Energieverwaltung, Taktdomäne, Cache, Speicheranbindung einzuführen ist eigentlich ausgeschlossen. Das ist für viele Teams dann eine Änderung im Lastenheft zu einem Zeitpunkt, wo man sich auf finale Validierung und Probefertigung vorbereitet..
 
  • Gefällt mir
Reaktionen: Cr4y und stefan92x
Zurück
Oben