Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: News des 25. Februar 2026
Leonidas
2026-02-26, 09:18:05
Link zur News:
https://www.3dcenter.org/news/news-des-25-februar-2026
Die Differenz zwischen P-, E- und LPE-Kernen wird bei Intel zukünftig über unterschiedliche Power-Kurven gebildet
Also wie bei AMD.
MiamiNice
2026-02-26, 10:10:58
Die neuerlichen Aussagen zu Intels Unified Cores klingen auf dem Papier erst einmal nach Aufräumaktion im Hybrid Tempel. Tatsächlich sollte man sich aber eher fragen, ob hier nicht das Gegenteil dessen passiert, was Intel eigentlich braucht.
Denn Unified bedeutet eben nicht, dass P-, E- und LPE-Kerne verschwinden. Die Klassen bleiben. Was verschwindet, sind die unterschiedlichen Mikroarchitekturen. Künftig soll alles auf dem selben Müll basieren nur noch mit unterschiedlichen Konfiguration.
Mit anderen Worten:
Ein Kern Design, das man dreimal unterschiedlich schnell laufen lässt und das nennt man dann „Unified“.
Und jetzt kommt der entscheidende Punkt: Diese gemeinsame Architektur soll aus der bisherigen E Cores stammen. Nicht aus den P Cores.
Da darf man schon einmal die Augenbraue heben.
Die Ps waren bislang Intels Speerspitze: maximale IPC, breite Ausführungseinheiten, große Ressourcen, kompromisslos auf SC getrimmt. Die Es hingegen waren Effizienzdesigns. Gut skalierbar, flächensparend, aber eben nie als absolute Performance Referenz gedacht und in den meisten Rechner fehl am Platz.
Wenn man nun die Es zur Grundlage für alles macht, läuft das im Kern auf Folgendes hinaus:
Man nivelliert die Architektur nach unten und versucht, das über Takt und Power wieder auszugleichen.
Das kann funktionieren, wird es aber nicht.
Hoher Takt ersetzt keine strukturelle Breite. Mehr Spannung ersetzt keine tiefere OoO Logik. Und wenn die Architektur intern enger gestrickt ist als ein klassischer richtiger Kern, dann bleibt sie das auch, egal wie hoch man sie prügelt.
Natürlich spart ein "Unified Design" massiv Entwicklungsaufwand. Zwei komplett unterschiedliche Kernlinien parallel zu entwickeln, kostet Ressourcen, Validierungszeit und Geld. Aber das ist ein Vorteil für Intel, nicht automatisch für den Gamer.
Gerade im Desktop Bereich zählt am Ende die maximale SC Power. Nicht die Eleganz oder der Preispunkt. Wenn Unified Cores bedeuten, dass Intel faktisch nur noch "Effizienzkerne mit verschiedenen Power-Limits“ anbietet, dann ist das ein strategischer Richtungswechsel. Weg vom kompromisslosen Performance Anspruch, hin zu einer stärker ökonomisch getriebenen Architektur. *Würg*
Aroas
2026-02-26, 10:13:36
8GB Grafikspeicher waren doch auch vor der Speicherkrise bereits "outdated" und jeder, der neueste Grafikkracher nicht nur in FullHD und bereits teils reduzierten Details zocken wollte, hat sich längst eine Karte mit mehr Speicher gekauft.
Alle Anderen, die der Meinung waren/sind, dass ihnen 8GB ausreichen und die somit mit den Einschränkungen leben können, werden das weiterhin tun.
Insofern sehe ich keinerlei Grund für die Spieleentwickler, jetzt wieder damit anzufangen, die 8GB Fraktion zu bedienen.
Das Einzige was sie nun ersteinmal nicht machen sollten ist, den Speicherhunger ihrer Spiele noch weiter nach oben zu schrauben, weil da erstmal keine/kaum neue Karten mit noch mehr Speicher zu erwarten sind.
Immortal
2026-02-26, 10:17:26
Bezüglich Speicherkrise zeigen sich übrigens anscheinend schon erste Auswirkungen selbst im Automotive-Bereich... Laut einem Kunden hat bereits einer deren Zulieferer von Speicher, der auch Server und Consumer RAM herstellt, seine Produktion weg von Automotive umgeschichtet zu den mutmaßlich lukrativeren Produkten für AI. Das wird umgekehrt als Chance für Firmen gesehen, die nur diesen spezialisierten Automotive-Speicher herstellen, im Automotive-Bereich ihren Marktanteil zu vergößern.
Platos
2026-02-26, 10:56:48
Wenn man die Unterscheidung durch nur die Spannungskurve bzw. Takt macht, ist klar, warum: Yieldrate. Die Kerne, die viel schaffen, aus denen wird dann ein P-core und die schlechteren werden als E-core klassifiziert und die ganz schlechten als LPE-Kerne.
So kann man wirtschaftlicher produzieren. Ich nehme da lieber AMD und nicht so unterschiedliche Kerne.
Badesalz
2026-02-26, 10:59:04
Also wie bei AMD.Dein Wissen ist, daß die Standardcores und die C-Cores bei AMD identisch mit verschiedenen Powerkurven sind? wow
@all
Ich verstehe das mit der core-flood weiterhin nicht. In Xeons wird man wohl weiter keine Hybride sehen. ODER? Sowas wie 48P+48E ergibt aber sonst absolut keinen Sinn oder? Was ist das für ein Markt? Will man hier eine Nische in der Nische besetzen, falls AMDs 48 Threads nicht reichen? Und dann? kill the threadripper oder wie? Der kann dann mit 256 oder 224 Threads kommen. Und dann?
Leonidas
2026-02-26, 11:54:49
Wenn man die Unterscheidung durch nur die Spannungskurve bzw. Takt macht, ist klar, warum: Yieldrate. Die Kerne, die viel schaffen, aus denen wird dann ein P-core und die schlechteren werden als E-core klassifiziert und die ganz schlechten als LPE-Kerne.
Die Kerne werden aber nicht einzeln hergestellt. Die kommen als einzelnes Die daher mit fest abgesteckten 8P+16E. Da läßt sich nicht mehr nachträglich irgendwas bestimmen, wer P und wer E ist - das legt der Floorplan vorher alles bereits fest.
In drei Jahren brauchen wir also 100 CPU Kerne. ^^
MiamiNice
2026-02-26, 12:09:20
Für mich ist eine 16 Core CPU am Desktop schon maximaler "core-flood" ;D
Platos
2026-02-26, 12:20:09
Die Kerne werden aber nicht einzeln hergestellt. Die kommen als einzelnes Die daher mit fest abgesteckten 8P+16E. Da läßt sich nicht mehr nachträglich irgendwas bestimmen, wer P und wer E ist - das legt der Floorplan vorher alles bereits fest.
Dann können es aber nicht die exakt gleichen Kerne sein, dann muss da architektonisch schon ein Unterschied herrschen, sonst könnte man sie ja gleich hoch takten lassen und weniger davon verbauen. Dann muss es ja schon eine abgespeckte version sein.
Platos
2026-02-26, 12:31:06
Dein Wissen ist, daß die Standardcores und die C-Cores bei AMD identisch mit verschiedenen Powerkurven sind? wow
@all
Ich verstehe das mit der core-flood weiterhin nicht. In Xeons wird man wohl weiter keine Hybride sehen. ODER? Sowas wie 48P+48E ergibt aber sonst absolut keinen Sinn oder? Was ist das für ein Markt? Will man hier eine Nische in der Nische besetzen, falls AMDs 48 Threads nicht reichen? Und dann? kill the threadripper oder wie? Der kann dann mit 256 oder 224 Threads kommen. Und dann?
Was verstehst du denn daran nicht? Immer noch nicht klar, dass es Leute gibt, die gerne viele Kerne haben wollen und nicht eine teure Threadripper Plattform kaufen wollen?
Oder was verstehst du an vielen Kernen nicht?
Exxtreme
2026-02-26, 12:48:39
Und jetzt kommt der entscheidende Punkt: Diese gemeinsame Architektur soll aus der bisherigen E Cores stammen. Nicht aus den P Cores.
Da darf man schon einmal die Augenbraue heben.
Die Ps waren bislang Intels Speerspitze: maximale IPC, breite Ausführungseinheiten, große Ressourcen, kompromisslos auf SC getrimmt. Die Es hingegen waren Effizienzdesigns. Gut skalierbar, flächensparend, aber eben nie als absolute Performance Referenz gedacht und in den meisten Rechner fehl am Platz.
Jein. Es ist so, die E-Kerne bei Raptor-Lake sind absoluter Kernschrott und nur dazu da um bei Cinebench-Zeugs gut dazustehen. Sie fressen wenig Fläche und das war's. Sie sind lahm und fressen viel Energie. Bei Arrow-Lake sieht die Sache anders aus. Die E-Kerne hier sind nur einen Ticken langsamer als die P-Kerne, fressen aber beträchtlich weniger Fläche und Energie. Die Dinger sind nagelneu. Was macht Intel also? Sie nehmen das neue E-Kerne-Design von Arrow-Lake und vergrößern es zu P-Kernen. Mehr ist das nicht.
Badesalz
2026-02-26, 13:01:33
Was verstehst du denn daran nicht? Immer noch nicht klar, dass es Leute gibt, Warum kannst du schreiben können, aber nicht lesen? Wie geht das? Ich fragte, was das für ein Markt sein soll und wie und welcher Konkurrenz man mit 48P und 48E begegnen soll. Wenn deine Antworten genuaso wie die letzten sind, dann ja, dann werde ich das beim nächsten Mal wieder fragen. Bis irgendjemand darauf Antworten hat die wenigstens oberhalb von kindisch sind.
Die X3D machen 87% aller Verkäufe einer Generation. Von dem was übrig bleibt, folgen erst die (x)600X. Sagt dir das was? Das ist, wenn das Angebot breit ist und die Leute damit rein nach Bedarf kaufen können. Wenn sie unbedingt Intel haben müssen weil wegen Gründe, dann kaufen sie primär was grad das Budget hergibt. Und nicht, weil sie gerne 12E Kerne brauchen.
edit:
Ich schreib nirgendwo - hier wie überall woanders - NICHT, daß mehr als 16 Threads kein Mensch braucht. Falls du auch das bisher nicht richtig lesen konntest.
Semmel
2026-02-26, 13:14:43
Wenn das alles identische "unified" Cores sind, dann bedeutet das ja, dass jeder Core dazu fähig wäre, ein P-Core zu sein. Aber bestimmte Cores werden dann zu E-Cores künstlich kastriert.
Wo ist da der Sinn?
Badesalz
2026-02-26, 13:25:23
@semmel
Vielleicht haben sie vor, solange power budget nicht kippt, mit irgendeinem "PL5" timer, bei Bedarf paar Kerne von der Betriebsart E auf die Betriebsart P zu schalten? hmm...
Verschiedene Modelle werden dann auch verschiedene PL5 haben. Schätzungsweise vorgetestet in etwa jeweils die Dauer eines Cinebench Laufes :usweet:
Leonidas
2026-02-26, 13:51:13
Dann können es aber nicht die exakt gleichen Kerne sein, dann muss da architektonisch schon ein Unterschied herrschen, sonst könnte man sie ja gleich hoch takten lassen und weniger davon verbauen. Dann muss es ja schon eine abgespeckte version sein.
Vermutlich ähnlich wie bei AMD: Enger gepackt, läßt sich schlechter takten. Die Architektur soll wie gesagt absolut gleich sein. Man könnte also höchstens an den Größen der Caches spielen.
Die Architektur soll wie gesagt absolut gleich sein. Man könnte also höchstens an den Größen der Caches spielen.
Wenn sie enger gepackt sind ist die Architektur nicht die gleiche.
Wenn das alles identische "unified" Cores sind, dann bedeutet das ja, dass jeder Core dazu fähig wäre, ein P-Core zu sein. Aber bestimmte Cores werden dann zu E-Cores künstlich kastriert.
Wo ist da der Sinn?
Sie haben das gleiche Instructionset und grundlegend die gleiche Architektur. D.h. aber nicht, dass das Silizium gleich ist (resultiert in unterschiedlichen Taktraten und Flaechenverbrauch). Es bedeutet nicht einmal, dass die Caches gleich gross sein muessen. Auch kann man die Cores an unterschiedlichen Stellen implementieren, d.a. die vier LPE Cores koennte zum Beispiel direkt auf dem I/O Die sitzen waerend 24P+24E ein Compute Chiplet bilden und aus zwei Compute Chiplets + I/O chiplet + whatever dann halt eine 48P+48E+4LPE CPU wird.
[QUOTE=Badesalz;13887760]Dein Wissen ist, daß die Standardcores und die C-Cores bei AMD identisch mit verschiedenen Powerkurven sind? wow
https://newsletter.semianalysis.com/p/zen-4c-amds-response-to-hyperscale
Lehdro
2026-02-26, 15:31:51
Wenn sie enger gepackt sind ist die Architektur nicht die gleiche.
Natürlich ist sie das, zeigt doch schon AMD. Bitte nicht die Kernarchitektur mit den Dieshots verwechseln.
Ein Zen Kern ist ein Zen Kern, ob der dann im Server, Mobile oder Desktop landet, führt nur zu seiner Ausgestaltung:
- Fertigung
- Packdichte
- Cache (siehe Dense Kerne & mobile Varianten)
- Kernanzahl pro Die -> interne Anbindung (siehe Dense Kerne)
- externe Anbindung (IF etc)
- angepeilte V/F Curve (Auslegung Power Gating / Clock Gating & ähnliches)
und sicher noch ein paar andere Sachen. Aber wie der Prozessor grundsätzlich angesprochen wird ist im Grunde gleich, er kann auch dasselbe (selbes Featureset) und hat sogar dieselbe IPC im AMD Fall.
Leonidas
2026-02-26, 15:59:15
Wenn sie enger gepackt sind ist die Architektur nicht die gleiche.
Die technologische Architektur (Schaltplan) ist zweifellos gleich, das hat nix mit der Packdichte zu tun. Die sagt nur aus, wie nahe die Schaltelemente aneinander liegen, ergibt keinerlei Architektur-Unterschied.
Nebenbei bereits vorhandener Beweis: AMD Zen 5 zu Zen 5c
Platos
2026-02-26, 20:08:55
Warum kannst du schreiben können, aber nicht lesen? Wie geht das? Ich fragte, was das für ein Markt sein soll und wie und welcher Konkurrenz man mit 48P und 48E begegnen soll. Wenn deine Antworten genuaso wie die letzten sind, dann ja, dann werde ich das beim nächsten Mal wieder fragen. Bis irgendjemand darauf Antworten hat die wenigstens oberhalb von kindisch sind.
Die X3D machen 87% aller Verkäufe einer Generation. Von dem was übrig bleibt, folgen erst die (x)600X. Sagt dir das was? Das ist, wenn das Angebot breit ist und die Leute damit rein nach Bedarf kaufen können. Wenn sie unbedingt Intel haben müssen weil wegen Gründe, dann kaufen sie primär was grad das Budget hergibt. Und nicht, weil sie gerne 12E Kerne brauchen.
edit:
Ich schreib nirgendwo - hier wie überall woanders - NICHT, daß mehr als 16 Threads kein Mensch braucht. Falls du auch das bisher nicht richtig lesen konntest.
Das mit den 48 + 48 Kernen ist ja nicht mal ein "leak" (Im Sinne von Insiderwissen), sondern nur eine Eigenhypothese. Das wird kaum passieren. Die Fläche wäre doch riesig mit einem dann verfügbaren Fertigungsprozess.
Aber ich bezog mich da auf Nova Lake Kernanzahl (16+32) bze. Zen7 (32 Kerner). Das mit den 48+48 habe ich tatsächlich überlesen bei dir. Ich glaube nicht, dass Intel auf 100 Kerne bei Consumer geht (ich täusche mich aber sehr gerne hierbei). Es sei denn, die können mit 48 Kernen nicht gegen AMDs Zen7 mit 32 Kernen antreten, weil die eben alle "gross" sind und auch SMT haben. Aber dann geht man doch nicht gleich auf 96 Kerne. Nochmals zur Erinnerung: Diese Info war Eigenhypothese vom Twitterer (oder welche Plattform auch immer) und die halte ich für total unwahrscheinlich
Aber selbst wenn: Wer mit 32 Threads was anfangen kann oder auch mit eben 64 (Zen7) oder 48 (Novalake/Zen6), der wird automatisch auch von 100 Threads profitieren. Oder ist dir eine Software bekannt, die zwar 48/64 Threads unterstützt, aber keine 100?
Und beispiele: Encoding, AI-Zeug (Wenn auch primar GPU-Lastig, brauchts da auch oft fette CPUs), Videofiltering (Filme z.B), Videoschnitt und Multitasking (Gleichzeitig mehreres von dem genannten machen und/oder nebenher noch anderes machen).
Das wäre der Markt. Niemand sagt, der sei riesig, aber das ist auch der Markt vom AMD 16-Kerner oder für den kommenden 24-Kerner von AMD nicht (im Grunde der Gleiche). Durch den Einzug in eine normale Consumerplattform kann man allerdings den Markt grösser machen. Vor AMDs 16-Kerner war dieser Markt erheblich kleiner, weil man sowas eben nur zu Mondpreisen in HEDT von Intel oder Threadripper bekam.
Sind deine Unklarheiten damit gelöst?
Ps: AMD hat natürlich so grosse ccds, weil man primär auf Server geht (der 16-Kerner wäre sicher nicht so schnell gekommen, hätte man das nicht auch für Server genutzt). Intel will da vlt. einen ähnlichen Weg einschlagen und alle tiles vereinheitlichen und so hochskalieren. Da kann man dann auch eher solche "riesen-CPUs" beim Consumer anbieten, weils eben mit Fertigungsfortschritten eben schlicht auch einfach möglich ist. Man hat die Tiles/ccds ja dann sowieso schon... Die Frage ist nur, wie viele davon kommen in eine Consumer-CPU und das sind bisher eben 2, sowohl bei AMD als auch (ab Novalake) bei Intel. Und wenn das CCD/Tile (hauptsächlich vermutlich wegen Server) grösser wird (Im sinne von mehr Kernen), dann wird das (anscheinend) automatisch auch nach "unten" durchgereicht zum Desktop.
Vlt. sollte man also anstatt in Kernen eher in Tiles/CCDs denken, um zu verstehen, warum die Kernanzahl am Desktop steigt. Wir kriegen 2 davon. Server mehr. Steigt die Kernanzahl pro Tile/CCD, steigt sie automatisch am Desktop mit.
Die technologische Architektur (Schaltplan) ist zweifellos gleich, das hat nix mit der Packdichte zu tun. Die sagt nur aus, wie nahe die Schaltelemente aneinander liegen, ergibt keinerlei Architektur-Unterschied.
Nebenbei bereits vorhandener Beweis: AMD Zen 5 zu Zen 5c
Schaltplan trifft es nicht ganz, aus der Beschreibung kann man auch eine Relais Schaltung, oder eine Röhrenschaltung, sogar einen reinen mechanischen Apparat kann man daraus generieren.
Wenn sie enger gepackt sind ist die Architektur nicht die gleiche.
Man kann die gleiche Architektur verwenden, aber eine andere Bibliothek im Fertigungsprozess. Für P-Kerne verwendet man die Bibliothek, die für hohe Taktraten optimiert ist, aber mehr Platz verbraucht. Für E-Kerne verwendet man die Bibliothek, die Platzoptimiert ist, dafür aber weniger Takt schafft. Die Architektur ist die selbe, die IPC ist die selbe, aber die Tranistoren schaffen weniger Takt bei den E-Kernen und verbrauchen weniger Platz.
Badesalz
2026-02-27, 07:39:35
Das wäre der Markt. Niemand sagt, der sei riesig, aber das ist auch der Markt vom AMD 16-Kerner oder für den kommenden 24-Kerner von AMD nicht (im Grunde der Gleiche).Wie oben schon beschrieben ;)
Die technologische Architektur (Schaltplan) ist zweifellos gleich, das hat nix mit der Packdichte zu tun.
Ein identischer Schaltplan würde zu identischen physischen Maßen führen, dass diese nicht identisch sind, zeigt bereits dass der Schaltplan unterschiedlich sein muss.
Die logische Architektur mag identisch sein, also die selben logischen Bausteine verwenden. Die physische ist es definitiv nicht.
Nebenbei bereits vorhandener Beweis: AMD Zen 5 zu Zen 5c
Zen5 ist nicht Zen5c, das sind 2 unterschiedliche Architekturen, sie sind zueinander kompatibel aber nicht identisch.
Leonidas
2026-02-27, 10:06:20
Ein identischer Schaltplan würde zu identischen physischen Maßen führen, dass diese nicht identisch sind, zeigt bereits dass der Schaltplan unterschiedlich sein muss.
Die logische Architektur mag identisch sein, also die selben logischen Bausteine verwenden. Die physische ist es definitiv nicht.
Missverständlich von mir geschrieben. Der Schaltplan (Elektrik) ist gleich. Der Floorplan (Belichtungsmaske) ist natürlich unterschiedlich.
Zen5 ist nicht Zen5c, das sind 2 unterschiedliche Architekturen, sie sind zueinander kompatibel aber nicht identisch.
Nein, es sind dieselben Architekturen. Der Code sieht keinen Unterschied.
Nein, es sind dieselben Architekturen. Der Code sieht keinen Unterschied.
Der Code sieht auch zwischen Zen 3 und Zen 4 keinen Unterschied
Leonidas
2026-02-27, 13:03:52
Der Code sieht auch zwischen Zen 3 und Zen 4 keinen Unterschied
Sicher? Was sagen die Programmierer hierzu?
MiamiNice
2026-02-27, 13:29:09
Jein. Es ist so, die E-Kerne bei Raptor-Lake sind absoluter Kernschrott und nur dazu da um bei Cinebench-Zeugs gut dazustehen. Sie fressen wenig Fläche und das war's. Sie sind lahm und fressen viel Energie. Bei Arrow-Lake sieht die Sache anders aus. Die E-Kerne hier sind nur einen Ticken langsamer als die P-Kerne, fressen aber beträchtlich weniger Fläche und Energie. Die Dinger sind nagelneu. Was macht Intel also? Sie nehmen das neue E-Kerne-Design von Arrow-Lake und vergrößern es zu P-Kernen. Mehr ist das nicht.
Ja Du hast recht.
Hatte da gestern ein längeres Gespräch mit paar Mates.
Es macht durchaus mehr Sinn die Es zu nehmen und diese zu skalieren.
Ein Design.
Drei Zielrichtungen.
Performance
Density
Low Power
Wird schon werden.
Hoffentlich?
"Du kannst einen schmaleren Kern aufblasen aber du kannst einen maximal breiten Kern nicht sinnvoll schrumpfen"
Sicher? Was sagen die Programmierer hierzu?
Der Code "sieht" tatsächlich keinen Unterschied.
Zwischen Zen 3 und Zen 4 hat sich für Software nichts Grundlegendes geändert, was Scheduling oder Codepfade erzwingen würde.
Für Compiler, OS Scheduler oder Entwickler gilt:
Ein Core ist ein Core.
Gleiche ISA
gleiche Featureflags
gleiche Cache Hierarchie aus Sicht der Software
gleiche SMT Logik
Ein Programm erkennt nicht, ob es auf Zen 3 oder Zen 4 läuft, solange es nicht aktiv nach Mikroarchitektur IDs fragt.
Und selbst wenn:
Das beeinflusst keine Codepfade.
Optimierungen passieren weiterhin auf:
AVX Support
Cache Größen
Prefetch Verhalten
Branch Predictor Verhalten
nicht auf "Core Typ".
Genau deshalb funktionieren auch Zen und Zen c bei AMD.
Lehdro
2026-02-27, 15:55:14
Der Code "sieht" tatsächlich keinen Unterschied.
Zwischen Zen 3 und Zen 4 hat sich für Software nichts Grundlegendes geändert, was Scheduling oder Codepfade erzwingen würde.
Für Compiler, OS Scheduler oder Entwickler gilt:
[...]
AMD hat für Zen 3 und Zen 4 getrennte Compiler, weil sich die Architektur so massiv unterscheidet. Da geht es nicht nur um AVX/Instruktionen oder Cache, sondern um ein neues Scheduling Model, erweiterte Register, mehr interne Bandbreite, andere Bufferstrukturen/Größen (Branch/Re-Order) und alles zielend auf eine andere Fütterung der Ausführungseinheiten für mehr Durchsatz, denn das muss alles möglichst effizient angesprochen werden.
Ein besseres Beispiel wäre GoldenCove -> RaptorCove - da hat sich wirklich nicht viel getan, eigentlich nur der Prefetch Algo und der ist für Code/Compile quasi wurscht weil allein von der Microarchitektur genutzt. Oder halt der Klassiker: Zen 2 und 3. Außerhalb der breiteren Ausführungseinheiten und des besseren Brand Predictors hat sich hier kaum etwas getan, die Änderungen waren primär die Cache und Kernstruktur als Ganzes, nicht aber die Kerne an sich - diese wurden primär nur "breiter".
MiamiNice
2026-02-27, 16:39:34
Zwischen Zen 3 und Zen 4 hat sich für Software nichts Grundlegendes geändert.
Darum ging es hier.
Natürlich hast du recht, Lehdro. Das war aber nicht meine Aussage.
Es geht darum, was die Software "sieht".
Natürlich gibt es auch Software, die die CPU "sieht" bzw. ausliest – Benchmarks z. B.
Standardsoftware fragt die CPU jedoch nicht direkt ab. Da ist ein Zen 3 dasselbe wie ein Zen 4.
Platos
2026-02-27, 19:47:56
Wie oben schon beschrieben ;)
Und was hast du da beschrieben? Ist mir anscheinend entgangen. Kannst du mal genau eerklären, wo deine Argumentation zu "Diese CPU ergibt keinen Sinn" ist ? Was sind eigentlich deine Standpunkte? Du schreibst nämlich manchmal ziemlich unklar.
MiamiNice
2026-02-28, 00:42:42
Dann können es aber nicht die exakt gleichen Kerne sein, dann muss da architektonisch schon ein Unterschied herrschen, sonst könnte man sie ja gleich hoch takten lassen und weniger davon verbauen. Dann muss es ja schon eine abgespeckte version sein.
Du hast noch nicht ganz verinnerlicht, worum es hier eigentlich geht. Macht aber nichts, ging mir am Anfang auch so. ;)
Ich versuche es mal zu erklären:
Ein CPU-Kern hat keine natürliche, feste Frequenz. Er hat vielmehr eine Saft/Takt Kurve.
Zum Beispiel:
4,5 GHz bei niedriger VCore = sehr effizient
5,5 GHz bei höherer VCore = weniger effizient
6,0 GHz bei sehr hoher VCore = maximal auf Leistung getrimmt, aber ineffizient
Die letzten 500 MHz kosten deutlich mehr Energie, als sie an zusätzlicher Leistung bringen.
Wenn ich also 8 Kerne auf 6 GHz betreibe, verbrauchen sie extrem viel Strom.
Wenn ich stattdessen 24–32 Kerne mit 4,5 GHz laufen lasse, erhalte ich deutlich mehr Gesamtleistung pro Watt.
Baue ich ein paar 6-GHz-Kerne ein, halte ich die Single-Thread-Leistung hoch.
Packe ich zusätzlich mehrere 5,5-GHz-Kerne dazu, bleibt die Multi-Thread-Leistung stark.
Und wenn ich noch einige Kerne im Bereich von 4,5 GHz habe, können die 5,5- und 6-GHz-Kerne öfter schlafen und werden seltener geweckt – das spart wiederum Strom.
Das ist alles derselbe Kern, nur unterschiedlich getaktet und damit auf unterschiedlichen Leistungsstufen betrieben.
Dadurch habe ich weniger Entwicklungsaufwand, weil ich nur ein Design pflegen muss statt zwei. Weniger Kosten.
Dann kann man doch einfach weniger Kerne hoch takten.
Nein, denn hohe Taktraten laufen massiv ins Powerlimit, sobald mehrere Kerne gleichzeitig aktiv sind.
Die Leistungsaufnahme steigt quadratisch mit der Spannung. Das ist eigentlich Standardwissen, zumindest im OC Bereich.
€: Das Ganze setzt natürlich voraus, dass wir Software nutzen, die mit vielen Kernen auch wirklich umgehen kann.
Weil das aber meist nicht der Fall ist, deswegen gibt es noch P Kerne.
Ansonsten wären die CPUs vermutlich fast komplett mit E-Kernen gefüllt, die nur dann geweckt würden, wenn die LPE-Kerne nicht mehr genug Leistung liefern.
€2: Mir widerstrebt das übrigens genauso sehr wie Dir :D^^ Ich hätte auch lieber 8× 10 GHz in der Kiste statt dem, was da vermutlich auf uns zurollt.
Platos
2026-02-28, 09:59:38
Danke für deine Antwort, aber mir ist schon bewusst, dass es eine spannung/takt kurve gibt. Es ging mir mehr darum, dass wenn es exakt die gleichen Kerne wären, es dann keinen Sinn macht, diese niedrig zu takten (aus Intels Sicht am Desktop). Es macht natürlich Sinn aus effizienzgründen. Zen6 und Zen6c sind zwar die gleiche Arichtektur, aber nicht exakt die gleichen Kerne. Aber der Unterschied zwischen gleicher Architektur und nicht exakt gleiche Kerne wurde ja von anderen erklärt. Das war mir nicht so ganz bewusst.
Mir ging es darum. Das wird bei Intel auch so sein und es wird nicht exakt der gleiche Kern sein, sondern es wird so wie bei Zen6 und Zen6c sein (also Big-little mit gleicher Architektur). Ich habe nur den Begriff Architektur etwas falsch verwendet anscheinend. Aber wenn jemand sagt, der einzige Unterschied wäre die Spannung/Takt kurve, dann verstehe ich darunter, dass es kein big-little gibt und wirklich nur die Takt/spannungskurve der Unterschied ist und das bezweifle ich.
Mich nervt das mit den kleinen und grossen Kernen vor allem deshalb, weil ich dann ungleichstarke Threads habe. Ich kann nämlich (da ich neben Gaming auch noch anderes mache) quasi unendlich viele Kerne gebrauchen. Aber wenn die alle unterschiedlich schnell sind, bin ich mir nicht sicher, ob da nicht was ausgebremst wird, wenn man gleichmässig aufgeteilte Aufgaben hat und dann der eine Thread länger braucht, bis er fertig ist und der andere dann evtl. warten muss.
Weiss das jemand hier? Beispielsweise beim CPU-Encoden mit x265 oder svt-AV1. Wenn ich da grosse und kleine Kerne habe, kann es dann nicht sein, dass dann die Threads auf berechnungen der kleinen Threads warten müssen, oder sowas? Oder eben alternativ bei anderem Zeugs wie Videofiltering usw.
Ich mags aber auch nicht, wenn Kerne ein unterschiedliches Featureset haben, wobei dass ja dann nicht mehr der Fall sein soll, weil gleiche Architektur.
Aber AMD ist bei allem ausser niedriglasteffizuenz sowieso effizienter Momentan. Daher schiele ich auch eher auf Zen7 als auf Titan Lake.
MiamiNice
2026-02-28, 18:59:32
Warum muss Big-Little automatisch unterschiedliche Kerne bedeuten?
Platt übersetzt heißt das erstmal nur groß und klein.
Großer und kleiner Takt? :biggrin:
Wenn die Architektur gleich ist, warum sollte Scheduling dann ein Problem sein? Der Scheduler verteilt Threads sowieso dynamisch. Auch heute laufen Kerne nie alle exakt gleich schnell -> Boost, Temperatur, Powerlimit etc.
Beim Encoden wird das Projekt in kleine Teile zerlegt. Wenn ein Kern langsamer ist, bekommt er halt weniger oder kleinere Aufgaben. Es gibt da kein Warten auf den langsamsten Kern.
Exxtreme
2026-02-28, 19:33:48
Beim Encoden wird das Projekt in kleine Teile zerlegt. Wenn ein Kern langsamer ist, bekommt er halt weniger oder kleinere Aufgaben. Es gibt da kein Warten auf den langsamsten Kern.
Geht nicht. Denn man kann von Aussen einem Programm nicht ansehen was es macht geschweige denn wieviel Rechenleistung ein Thread verbrauchen wird und auf welchem Kern ein Thread optimal laufen wird.
Deshalb gibt es ja den Hickhack mit den CCDs bei AMD wo Spiele manuell als solche hinterlegt werden müssen. Denn Windows kann nicht erkennen ob ein Programm vom 3D-Cache profitieren wird.
MiamiNice
2026-02-28, 20:40:23
Natürlich nicht. Aber der Scheduler verteilt die "Teile" des Workloads so lange auf freie Kerne, bis keine "Teile" mehr übrig sind. Man wartet also nur am Ende auf die letzten Kerne, aber nicht generell auf die langsameren Kerne.
e: Praktisch gesprochen trägt ein langsamerer Kern einfach weniger zum Gesamtworkload bei, aber man wartet nicht zwangsläufig auf ihn. Kann passieren, muss aber nicht.
Rabiata
2026-03-02, 14:13:39
Das Ganze hat immerhin den Vorteil, daß es jetzt einen einheitlichen Befehlssatz gibt mit Blick auf AVX 512. Früher hing es ja von der Prozessorversion ab ob das überhaupt ging.
Lehdro
2026-03-02, 16:30:34
Aber AMD ist bei allem ausser niedriglasteffizuenz sowieso effizienter Momentan.
So pauschal inkorrekt.
Liegt primär an zwei Faktoren:
1. Chiplets (hohe Grundlast was Verbauch angeht), die APU Monolithen sind da sehr gut deswegen, weil der IOD wegfällt.
2. Race to idle/sleep: AMD setzt dieses Prinzip verdammt aggressiv um. Je schneller die CPU die Arbeit erledigt, desto schnell kann sie wieder idlen. AMD hat extrem viel Arbeit in schnellere und höhere Boosts gesteckt während Intel da seit dem Ende von RKL nachgelassen hat, auch begründet durch deren ineffiziente Architektur, man stelle sich z.B. einen in Nanosekunden boostenden 14900KS unter Volllast vor. Für die Spannungsregelung wäre das eine Tortur. Intel boostet meistens in 1-3 Schritten: Maximaler Takt für wenige ns, dann fast wieder idle, dann max Boost dauerhaft (dann sind die VRMs bereit). Bei AMD kommt man sowieso von höherem Idle Frequenzen (meist ~3 Ghz) und geht direkt auf die maximale Frequenz. Nur bei den Kotzgrenzenmodellen (> 5.4 GHz) hat man einen Zwischenschritt bei ca. 5 GHz für wenige ns. Apple hingegen boostet sanft jede ms hoch, brauch aber vergleichsweise ewig für die maximalen Frequenzen - dafür wird weniger nachgeregelt.
Aber ansonsten sind die Cores, ordentlich eingebremst, in der passenden V/F Curve, auch zu sehr guten Niedriglastverbräuchen in der Lage - das wird aber konzeptionell nicht angestrebt - da es mit Chiplets relativ egal ist und die Schwuppzidität für AMD mehr wert ist.
Aber wenn die alle unterschiedlich schnell sind, bin ich mir nicht sicher, ob da nicht was ausgebremst wird, wenn man gleichmässig aufgeteilte Aufgaben hat und dann der eine Thread länger braucht, bis er fertig ist und der andere dann evtl. warten muss.
Nur wenn man sich blöd anstellt.
vBulletin®, Copyright ©2000-2026, Jelsoft Enterprises Ltd.