News Intel Nova Lake: Ein Quartett mit großem Cache als Core Ultra 400K erwartet

Northstar2710 schrieb:
Somit benötigt Intel mehr kerne als AMD für die gleiche anzahl an threads.
Das ist ja alles richtig, nur gab es 2017 das erste mal 8, 2019 dann 16 und ende 26 sollen es dann 52werden, das ist schon krass. wird noch Jahre dauern bis 16 und mehr Kerne wirklich einen vorteil im alltag bringen.
 
@Icke-ffm Absolut.
Bzw wird das im Alltag (also für Bauer Hans, nicht im Spiele Alltag ist gemeint) so vielleicht gar nie Sinn ergeben. Einfach weil die CPUs nun so schnell sind, dass 99% der Software auch schon mit nur einem Teil der Leistung auskommt:
Ich nutze in einem meiner PrivatPCs einen i7 920. Also eine 17 Jahre alte CPU für den Office Betrieb (Windows, Office, Internet Surfen, wissenschaftliche Arbeiten), aber auch teilweise zum Spielen (selbst Doom Eternal läuft mit 120+ FPS, die CPU Last ist dabei aber stets auf 90+% :D).

Heutige CPUs sind schneller, Sparsamer und haben auch mehr als 4 Kerne +HT.

Wie könnte man das in Zukunft lösen?
Es gibt letztlich 2 Ansätze: kurzfristig braucht es verschiedene Architekturen in einer CPU. 2-4 LP Cores die sich um Hintergrund Aufgaben kümmern. Diese müssen ja nicht stärker sein als die von SmartWatches oder zumindest Smartphones. 0,5-2W verbrauchen und 99% der Office Aufgaben, OS Prozesse etc abdecken. Den Rest machen dann stärkere E Cores oder für die ganz harten Aufgaben zusätzlich dann P Cores.
Einzig der OS Scheduler muss hier mitspielen und die Software.

Zweiter Ansatz ist inverse Multi Threading oder massive Software Änderung: wenn Software fähig wird sich (bzw. die daraus entstehenden Software-Threads) beliebig auf Cores aufzuteilen (bzw diese aufzuteilen) geht das mit der Core Skalierung einher.

Oder wenn es CPUs möglich ist, dass mehrere Kerne an einem Thread/Job arbeiten.

Prototypen dazu gibt es schon lange, die Umsetzung scheint bis auf Spezialfälle schwierig
 
Zuletzt bearbeitet:
Northstar2710 schrieb:
Du must bedenken, das intel kein HT mehr hat und somit eder Kern 1thread darstellt. AMD benutzt noch Smt und somit steht jeder Kern für 2threads. Somit benötigt Intel mehr kerne als AMD für die gleiche anzahl an threads.
Auch bei Intel kann ein Kern mehrere Threads abarbeiten, dafür gibt es ja den (Software-)Scheduler. SMT heißt nur, dass mehr logische CPUs auftauchen als physische da sind und der Scheduler diese Threads dann darauf verteilen darf. Mit allen Folgen, z. B. dass diese logischen "CPUs" sich gegenseitig beeinflussen können, was dann in der Vergangenheit schöne Sicherheitsprobleme verursacht hat und man SMT deaktivieren durfte.

Wenn man Silizium-Fläche für diese logischen CPUs einsparen und dafür mehr physische hinbauen kann, bringt das am Ende mehr. Und man bekommt saubere Kontextwechsel dazu.
 
Ob wir jemals erfahren werden, wie hoch der Transistorcount des Gesamtkonstrukts sein wird…

@zeedy
Taktfrequenz zu niedrig?🤔
 
Quidproquo77 schrieb:
Für die richtige Nische nicht.
Die "richtige" Nische dürfte in etwa so groß sein, wie die für 9950X3D2. Der Rest zahlt für etwas, wovon man nichts hat.
 
zeedy schrieb:
Ich verstehe Intel's Kernzahlwahn nicht.
Das ist der Lauf der Dinge. AMD hat schließlich rein logisch betrachtet auch mit mindestens 2x 12 Kerne geplant.
Und wenn AMD aktuell über Mindfactory 2.410 9950X3D verkauft hat, ist es sicherlich nicht vermessen von mindestens 7.000 in ganz Deutschland zu spekulieren. Weltweit sicherlich 60.000. Das lohnt sich für AMD . Ein 9950X3D2 kostet keinerlei Entwicklung. Und wenn man damit weltweit 30.000 verkaufen kann, warum also nicht. Bei Intel wird der Markt viel größer sein, weil weiterhin der übergroße Chef bei Marktanteile. Da werden sicherlich über die Laufzeit 350.000 52 Kerner im Desktop weggehen.

Was gibt es da nicht zu verstehen. Wir Menschen laufen doch voll aus dem Ruder.

Es gibt hier im Form Menschen, die eine 35W Leerlauf GPU haben, einen 60W HDR Monitor, sich über 10-15W mehr Leistungsaufnahme im Leerlauf bei AMD beschweren und beim Zocken insgesamt 600W verbraten.
Ein 7500X3D wird trotzdem verkauft, obwohl teurer als ein 7600X3D.
AMD wird gefeiert und Intel in den Untergang gebetet und umgedreht. Dabei sind wir nur Bittsteller und dürfen froh sein, nicht noch eine Ohrfeige beim Kauf hinnehmen zu müssen.

Da hätten selbst 100 Kerne mehr Rationalität im Vergleich wie wir Menschen so sind.
 
viel hilft viel

1766503351781.png
 
Alesis schrieb:
Dabei sind wir nur Bittsteller und dürfen froh sein, nicht noch eine Ohrfeige beim Kauf hinnehmen zu müssen.
🤣
Sieht man ja bei Nvidia. Die fragen sich bestimmt auch, ab wann die Schmerzgrenze bei den meisten x90 Käufern erreicht ist. Sicherlich nicht bei 3000€. "Ist ja genau genommen ein relativ günstiges Hobby" 🤡
 
mae schrieb:
Was ich (vor laengerer Zeit) ueber diverse Prozessoren gelesen habe, ist, dass sie immer groesser entworfen wurden, und dann wurden sie fuer die Produktion abgespeckt ("silicon diet" habe ich mal gelesen).
Vorgekommen ist es, es gibt ein sehr prominentes Beispiel. Es würde mich aber wundern, wenn es nach Abschluss des Chip Designs die Regel war. Nach Ende des Physical Designs ist es selten sinnvoll.

Der Pentium bekam eine "silicon diet". Der Pentium Bug ist eine direkte Folge dieser "silicon diet". Und wie die Diäten bei der Gewichtsreduktion nichts bringen, brachte diese "silicon diet" keine Flächenreduktion, da sie zu spät kam und der Chip nicht komplett neu layoutet wurde.

Üblicherweise starten die CPU Architekten mit einem Budget an Transistoren und wenn sie dadrüber kommen, fangen eben die Diskussionen an.

mae schrieb:
Dass man den Lion Cove abspecken kann, und dabei noch nennenswert IPC dazugewinnen kann, halte ich allerdings fuer unwahrscheinlich.
Abspecken bedeutet IPC wegnehmen.

Abzuspecken und dabei überproportional Fläche zu sparen halte ich bei komplexen Designs für sehr schwer. So wie ich es verstehe läuft abspecken eher darauf hinaus überproportional IPC für die Flächeeinsparung aufzugeben.

Es läuft auf ein Redesign raus oder eben auf ein neues Ground Up Design.

mae schrieb:
Andererseits, einen fuer geringeren Takt entworfenen Core auf hoeheren Takt zu bringen, stelle ich mir auch schwierig vor.
Wir reden von Chipdesign mit Milliarden Transistorfunktionen je Die. Da ist nichts einfach.

Die Chipdesigner müssen sich am Anfang des Designs festlegen welche IPC und welche Frequenz sie anstreben. Entsprechend müssen die die Libs auswählen und das Design aufsetzen.

In einem Interview bei Toms Hardware hat sich Mike Clark wie folgt geäußert:
TH: When you are looking at the standard core and shrinking it down while closely matching the performance capabilities so you don’t have thread dependency problems, how do you achieve that? Denser libraries, closer spacing?

MC: It's more of the latter — the library’s the same. \[..] There are sort of logical blocks, and there are even subblocks, but to hit the high frequency in certain critical speed pads, we have to break the design down into small pieces, which we then do custom work on. But at the end of the day, it's a rectangle; things are further apart than they need to be, there's whitespace, and that's all to drive that high frequency. But then we say, ‘Okay, well, lower the max frequency.’ Then, we can combine blocks together; we don't need to do as much custom work, and it can pull the design in. It's now just naturally smaller because we utilize the space more. When it was bigger there's extra logic for repeaters and stuff like that, there’s buffering, and that all gets removed.

It's amazing how much you can shrink the core at whatever target you picked to then find a bunch of area and power to get the squeeze out of it. It was really just because of what we had to do to get that high frequency. Now, you could say, ‘Well, why aren't you better at picking those small bundles? ' But we've been doing that for years, and we can't perfect the smaller blocks. It's just kind of in the nature of the design.

So wie ich Mike Clark verstehe, ist das Physical Design für Kerne mit niedriger Frequenz einfacher. Es kommt eben darauf an die richtige Frequenz zu wählen, wie Mike Clark ebenfalls in diesem Interview sagt, wo er quasi Hybrid CPUs für den desktop ankündigt.

AMD hat bei der Vorstellung den Weg gewählt Zen 4 dense inklusive L2 mit Zen 4 classic inklusive L2 zu verglichen, und kam auf 35 % Einsparung.
1766577415260.png


Wenn ich mir den annotierten Die Shot von Phoenix 2 anschauen, dann komme ich zum Schluss, dass der Kern ohne L2 erheblich besser skaliert als die genannten 35 %

1766578009246.png




mae schrieb:
Ok, theoretisch macht man mehr Pipelinestufen, damit jede Stufe weniger zu tun hat, aber praktisch kann das sehr viel mehr kosten (wenn eine neue Stufengrenze an eine Stelle faellt, wo es sehr viele Signale gibt; fuer alle Signale muessen an einer Stufengrenze Flipflops gemacht werden), und jede Stufe verursacht einen Overhead, sodass man die Anzahl der Stufen um einen hoeheren Faktor vergroessern muesste als das Verhaeltnis der Taktfrequenzen.



Da ist Intel aber schon. Intel's E-Cores sind groesser (und haben mehr IPC) als ARMs big-Cores, und Intel's P-Cores entsprechen ARMs bigger-Cores.



Zunaechst einmal gibt es AVX10.2/256 (maximal 256-bit-Register und -Operationen) und AVX10.2/512, also eigentlich muesste man bei den aktuellen E-Cores nicht viel dazufuegen, um AVX10.2/256 zu unterstuetzen.
512 bit ist obligatorisch für AVX10.2.

1766576631787.png


Das war eine Änderung bei der 4. Revision von AVX10.2.


mae schrieb:
Weiters ist keine fette FPU noetig, um AVX10.2/512 zu unterstuetzen, das geht auch mit 128-bit-FPUs. Was man braucht, sind genug (also >128) physische 128-bit-Register, um die 32 ZMM-Register zu implementieren, und noch ein paar mehr fuer register renaming. Oder man macht stattdessen 512-bit-Register wie Zen4, und die schmaleren FPUs brauchen dann mehrere Zyklen pro Operation. Eigentlich wundert es mich, dass das nicht schon bei Gracemont (Alder Lake E-Core) gemacht wurde, und ich vermute da ein Managementschlamassel bei Intel. Wofuer AFAIK breitere Einheiten sinnvoll sind, sind die Shuffle-Befehle, aber zur Not geht das auch mit schmaleren.
Natürlich gibt es Optionen das mit mehr oder weniger Fläche umzusetzen. Aber es ist immer noch mehr Fläche als bisher. der Flächenverbrauch war der Grund warum Intel AVX-512 weggelassen hat, oder etwa nicht?

Außerdem werden immer Flächen ohne L2 (E-Core) mit Flächen inklusive L2 (P-Core) verglichen. Ein anderer Faktor war dass sich 4 Kerne den L2 teilen.
mae schrieb:
AMD macht's ja bei Zen5 auch so: Da haben sie Varianten mit 512-bit-FPUs, und Varianten mit 256-bit-FPUs.
Und trotzdem hat AMD bis Zen 4 gewartet bis AMD AVX-512 unterstützt hat. Der Zuwachs an Transistoren in der FPU war beachtlich, obwohl AVX-512 in Zen 4 mit einem 256 data Path umgesetzt worden ist.

mae schrieb:
Es gibt daneben noch andere Anwendungen, die von viel Parallelismus profitieren, aber die meisten Leute brauchen das nur selten bis nie. In diesem Thread wird genau eine andere Anwendung genannt, das ist Shader-Compilierung.
Wenn man sich die Phoronix Benchmarks anschaut, dann profitieren alle Renderbenchmarks von vielen Kernen. Aber bei Phoronix gibt es halt noch jede Menge anderer Benchmarks.
mae schrieb:
Ja, Intel's Hybrid-Ansatz ist grundsaetzlich schon sinnvoll: Ein paar schnelle Cores fuer Anwendungen mit wenigen kritischen Threads, und viele Cores fuer Anwendungen, die sich gut parallelisieren lassen.
Was die Technik anbelangt sind wir anderer Meinung.

Hier ist ein Allround Core bzw Mid Core auf verschiedene Frequenzen auszulegen vielversprechender. Diesen Weg geht man bei den Arm SoC diesen Weg geht AMD

Aus Sicht des Marketings war eine gute Lösung die auf die CineBench Benchmarks zugeschnitten war. Die CineBench Benchmarks stehen bei Windows praktisch alleine für die Multi-Core Anwendungsperformance. Somit hat Intel die Chiplet-Architektur von AMD sehr gut gekontert.

Was ich mich die ganze Zeit frage, passen ein Zen 6 classic CCD und ein Zen 6 Dense CCD in das Package von AM5?

mae schrieb:
Dass nicht alle Kerne gleichzeitig ihre Spitzenfrequenzen gleichzeitig erreichen koennen, ist kein Problem, dann faehrt man sie eben mit niedrigerem Takt.
Und nutz die Fläche, die man für das erreichen der hohen Frequenzen investiert hat nicht. Ganz schlechte Idee.

mae schrieb:
Klar kannst Du jetzt jeden Kern extra fuer die Taktfrequenz entwickeln, die noch geht, wenn er dazugeschalten wird, aber da waere der Enwicklungsaufwand gewaltig
Das ist genau das was AMD, MediaTek und Qualcomm machen. Die Änderungen beziehen sich auf das Physical Design. Der Entwicklungsaufwand ist erheblich geringer als eine zweite Architektur mit E-Cores zu entwickeln.

mae schrieb:
, da sind die zwei Stufen (P-Cores und E-Cores) schon eine gute Annaeherung.
Mit den klassischen E-Cores ist es ein veraltetes Vorgehen.

Die E-Cores von Apple sind von der Performance nur ganz knapp unter den mittleren Cores bei den anderen. Und haben einen erheblich niedrigeren Energieverbrauch als die E-Cores, die noch bei den alten Phone-SOC von MediaTek und Qualcomm verwendet wurden.
mae schrieb:
Schauen wir einmal, was mein auf Eco-Mode (~61W power limit) laufender Ryzen 8700G (Zen4) macht, wenn ich ihn auf n Kernen 2000x2000-Matrizen multiplizieren lasse:

Code:
n MHz
1 4970
2 4904
3 4865
4 4766
5 4574-4865
6 4366-4791
7 4166-4455
8 4012-4177

n ist die Anzahl der Kerne, die Matrixmultiplikation machen. SMT ist auf diesem Prozessor abgeschaltet.
Ich denke deine Zahlen zeigen sehr schön warum AMD bei Strix Point auf Hybrid gegangen ist. 61 w sind im Desktop nicht viel aber für Mobilprozessoren ist das zu viel.

mae schrieb:
Interessanterweise fiel bei 2-4 Kernen die Taktfrequenz, obwohl weder das Powerlimit noch das Thermal Limit erreicht wurden. Das Power Limit wird bei n=4 knapp verfehlt und ab n=5 haengt der Prozessor im Power Limit (~61W). Das thermal limit wird auf diesem Prozessor nie erreicht, dazu ist das Power Limit zu niedrig und die Kuehlung zu gut.
Es gibt halt noch das Strom Limit. Vielleicht ist es das?

Das Strom Limit war der Grund ist warum AMD beim 9950X die PPT von 230 W auf 200 W zurücknehmen musste. Durch die bessere Spannungskurve von Zen 5 auf N4P läuft der 9950X ins Strom Limit von 160 A.

mae schrieb:
Bei n=3 ist auch im Eco-Mode die Taktfrequenz weit ueber dem, was Zen4c zu leisten imstande ist, also ist Phoenix2 mit Zen4+Zen4c im Desktop schwaecher, als es Phoenix mit nur Zen4 ist (vorausgesetzt, man hat Last fuer mehr als 2 Kerne, die von hohem Takt auf den Kernen profitiert). Sogar bei n=8 ist die Taktfrequenz noch deutlich ueber der mit Zen4c erreichbaren Taktfrequenz. Ich erwarte, dass Krackan und Strix Point auch vom Taktlimit staerker als vom Power Limit begrenzt werden, wenn sie einmal in den Desktop kommen.
Ich rede nicht von Phoenix 2 mit 6 kernen. Dass man 6 Kerne im Desktop locker ausfahren kann, ist klar.

Auf der anderen Seite hat Phoenix 2 beim test von Phoronix ordentlich abgeschnitten.
https://www.phoronix.com/review/amd-zen4-zen4c-scaling/5
1766590195363.png


Wir reden offensichtlich auch nicht vom 9950X:
1766588310466.png

https://www.techpowerup.com/review/amd-ryzen-9-9950x/26.html

Aber die Frage ist eben, wie gut skaliert das ganze bei Zen 6 mit 24 Kernen oder mit den angeblich 32 Kernen bei Zen 7? Vor allem wenn die Frequenzen weiter ansteigen.

Und genügt das um mit Intel bei CineBench mithalten zu können?
Ergänzung ()

stefan92x schrieb:
Du denkst an den Desktop. AMD priorisiert Server, und da scheint zu gelten: Advanced Packaging erlaubt keine zweite/dritte Reihe CCDs mehr, alle müssen direkt an den IOD grenzen bei Zen 6.
Genau.
Und deshalb hat AMD auch 2 IODs weil die erforderliche Shoreline mit einem IOD das Reticle Limit sprengen würde.
stefan92x schrieb:
Damit AMD die Zahl der Kerne pro CPU nicht senken muss, muss die Zahl der Kerne pro CCD steigen (von 8/16 auf 12/32).
Bei Zen 5c war es auf beiden Seiten auch nur eine Reihe, aber die CCDs mussten nicht an die Shore Line des IOD.
 
Zuletzt bearbeitet:
Zurück
Oben