Arrow Lake (Lion Cove+Skymont, Xe HPG, LGA1851, 20A+N3B, 2024)

[Exxtreme]

war das nicht so, dass je größer der Cash einer CPU ist desto größer die Latenz?

Ja, grundsätzlich ist das so. Ist mit ein Grund warum man mehrere Cache-Level hat und nicht nur einen sehr großen Level 1-Cache.

[dildo4u]

Gerade vom neuen Cache-Konzept hatten wir uns doch viel erhofft, da es den Anschein machte, dass man die Latenz der zusätzlichen Cache-Stufe komplett verstecken kann. Kann man sich jetzt schon fragen, was der ganze Aufwand sollte. L1D soll ja auch geringere Latenz haben als Raptor Cove bei gleicher Größe.

Könnte man bitte nen Raptor LAke mit den neuen eCores und 72MB L3 ausstatten, IMC noch mal updaten und das Ganze in Intel3 bringen? ;)


Wer soll das kaufen nach dem Degeneration Debakel Intel hat Glück das Arrow Lake alles ändert, sie werden alles tun um sich von Raptor Lake zu distanzieren.

[Kriegsgeier]

Eine Cash Zelle hat ja sehr viele Transistoren und jeder Transistor bedeutet Ladung und die Ladung Q ist in einem Kondensatorkonstrukt ist ja eine Zustandsgröße und die Zustandsgröße kann sich nicht sprunghaft ändern --> Somit braucht jedes Umladen kostbare Zeit...

So ist mein grobes Verständnis darüber

[HOT]

War nicht der Ringbus bei ARL deutlich niedriger getaktet? Das würde übrigens auch die Spieleleistung erklären...

[robbitop]

Natürlich ist mehr IPC in Spielen zu extrahieren, man muss halt größere Caches verbauen um nicht Memory-bounded zu sein. Nur das Problem von Lion Cove sind nicht Spiele.
Große Caches sind ein Einmal Effekt. Den hast du dann und dann?
Seit X3D ist das gegeben. Intel hat doch noch vor sich. Aber dann ist die o.g. Situation nicht ganz unwahrscheinlich.
Spiele sind ja auch nicht ausschließlich Cache limitiert.

[MiamiNice]

Miami ist echt zum schießen :ulol:

Wer ist schuld daran dass die Firma deren fanboi ich bin versagt hat? -Na klar, Obam--- ähh die Grünen?

Wer?:ucrazy:

- DIE GRÜÜNEN! (mit der Stimme von Seehofer)

:popcorn::popcorn::popcorn:

Du solltest lesen lernen. :freak:

Große Caches sind ein Einmal Effekt. Den hast du dann und dann?

Bis dahin ist aber noch ein langer Weg. Selbst der 3DCache von AMD suckt noch oft genug weil nicht die passenden Daten im Cache sind. Bis wir an Deinem Punkt sind, fließt noch viel Wasser den Rhein herunter. Und bis dahin würde es schon Sinn machen, ein schnelles Speichersubsyystem zu verbauen. Intel hat sich bei ARL leider dagegen entschieden.

[fondness]

Große Caches sind ein Einmal Effekt. Den hast du dann und dann?
Seit X3D ist das gegeben. Intel hat doch noch vor sich. Aber dann ist die o.g. Situation nicht ganz unwahrscheinlich.
Spiele sind ja auch nicht ausschließlich Cache limitiert.

Für mich ist das eine ähnliche Leier wie Leute die seit Jahrzehnten davor warnen, dass es keine kleineren Fertigungsprozesse mehr geben wird, weil man physikalisch am Limit ist. Genauso hört man seit Jahrzehnten, dass man die ipc nicht mehr steigern kann. Trotzdem ging es in beiden Fällen immer weiter, mal mehr mal weniger. Ich würde sagen den mutigen gehört die Welt, resignieren kann man im Grab. Kluge Köpfe werden immer wieder Möglichkeit finde, die Grenze des machbaren zu verschieben. Und wenn irgendwann wirklich nichts mehr gehen sollte, sieht man das früh genug. Da es aber unfassbar viele Schrauben gibt an die man da drehen kann, und ilp ein unfassbar komplexer Prozess ist, denke ich nicht, dass man da so schnell ansteht. Aber klar ähnlich wie beim Fertigungsprozess gibt es eine natürliche Barriere die man nicht überschreiten wird können, wo diese liegt weiß aber niemand.

AMD hat die IPC bei Zen5 um 17% erhöht, das ist mehr als der Durchschnitt der vorangegangenen Zen-Generationen. Für Spiele braucht man halt den Cache weil man sonst an der Speicherlatenz hängt. Der kommt aber bald. Ich sehe kein Problem. Die Probleme bei Intels P-Cores liegen ganz wo anders, siehe meine vorherigen Beitrag.

[Zossel]

Für mich ist das eine ähnliche Leier wie Leute die seit Jahrzehnten davor warnen, dass es keine kleineren Fertigungsprozesse mehr geben wird, weil man physikalisch am Limit ist.

Das ist primär eine wirtschaftliche Grenze, kein Schwein wird ein Telefon kaufen dessen CPU 10000 Euro kostet.

Siehe auch das Gejammer über die Preise für GPUs.

[Zossel]

Eine Cash Zelle hat ja sehr viele Transistoren und jeder Transistor bedeutet Ladung und die Ladung Q ist in einem Kondensatorkonstrukt ist ja eine Zustandsgröße und die Zustandsgröße kann sich nicht sprunghaft ändern --> Somit braucht jedes Umladen kostbare Zeit...

So ist mein grobes Verständnis darüber

Cache besteht im Regelfall aus SRAM nicht aus DRAM.

[Kriegsgeier]

und SRAM wird nicht aus MOSFEDs aufgebaut?
Das ständige refreshen der DRAM Zellen habe ich gar nicht gemeint.
Die Menge der MOSFEDs, die eine Cash Zelle benötigt ist wesentlich größer als die einer DRAM Zelle.

[Kriegsgeier]

Für mich ist das eine ähnliche Leier wie Leute die seit Jahrzehnten davor warnen, dass es keine kleineren Fertigungsprozesse mehr geben wird, weil man physikalisch am Limit ist. ...
Nun ja, wir sind nun mal an der Grenze angekommen: Stichworte Elektronenmigration und sogar der Tunneleffekt - beide parasitäre, ungewollte Effekte.
Dieser Sachverhalt kommt noch zu den exponential steigenden Fertigungskosten bei TSMC.

Im Endeffekt müsste genau TSMC jetzt die Physik überlisten und von ihrer Seite eine Lösung vorstellen, die genau dieses Angeht. Denn, NVIDIA-, Apple-, AMDChipdesigner geben schon alles was sie können. Nur die Physik ist da ob man will oder nicht.
Und wenn die Chipstruktur mehr Chipfläche erfordert und diese Chipfläche WESENTLICH teuerer ist als noch vor 5 Jahren, dann werden die Kosten einfach auf die Käufer dieser Chips umgeladen.

[fondness]

Das ist primär eine wirtschaftliche Grenze, kein Schwein wird ein Telefon kaufen dessen CPU 10000 Euro kostet.

Siehe auch das Gejammer über die Preise für GPUs.

Ja klar, noch sinkt aber der Preis pro Transistor. Und es ist natürlich iwann auch ein physikalisches Problem, ein Atom lässt sich nicht kleiner machen.

[robbitop]

Für mich ist das eine ähnliche Leier wie Leute die seit Jahrzehnten davor warnen, dass es keine kleineren Fertigungsprozesse mehr geben wird, weil man physikalisch am Limit ist. Genauso hört man seit Jahrzehnten, dass man die ipc nicht mehr steigern kann. Trotzdem ging es in beiden Fällen immer weiter, mal mehr mal weniger. Ich würde sagen den mutigen gehört die Welt, resignieren kann man im Grab. Kluge Köpfe werden immer wieder Möglichkeit finde, die Grenze des machbaren zu verschieben. Und wenn irgendwann wirklich nichts mehr gehen sollte, sieht man das früh genug. Da es aber unfassbar viele Schrauben gibt an die man da drehen kann, und ilp ein unfassbar komplexer Prozess ist, denke ich nicht, dass man da so schnell ansteht. Aber klar ähnlich wie beim Fertigungsprozess gibt es eine natürliche Barriere die man nicht überschreiten wird können, wo diese liegt weiß aber niemand.

AMD hat die IPC bei Zen5 um 17% erhöht, das ist mehr als der Durchschnitt der vorangegangenen Zen-Generationen. Für Spiele braucht man halt den Cache weil man sonst an der Speicherlatenz hängt. Der kommt aber bald. Ich sehe kein Problem. Die Probleme bei Intels P-Cores liegen ganz wo anders, siehe meine vorherigen Beitrag.

Die Vergangenheit ist kein Beleg für die Zukunft. Insofern bleibt nur Meinung von deinem Post über. Was ok ist - uns liegen keine Daten vor.
Ich habe ja auch nicht gesagt, dass wir definitiv an dem Punkt der Deminishing Returns sind sondern, dass das eine Möglichkeit ist. Und die kann man ohne Zahlen, Daten und Fakten nicht wegdiskutieren. ;)

Und das mit dem Cache hatten wir schon. Der große L3 Cache ist ein Einmaleffekt. Mal schauen ob der X3D Zen 5 überdurchschnittlich viel bringen wird oder ob er taktnormiert bei dem Abstand wie zwischen Zen 4 vs Zen 5 Vanilla bleiben wird.

[fondness]

Die Vergangenheit ist kein Beleg für die Zukunft. Insofern bleibt nur Meinung von deinem Post über. Was ok ist - uns liegen keine Daten vor.
Ich habe ja auch nicht gesagt, dass wir definitiv an dem Punkt der Deminishing Returns sind sondern, dass das eine Möglichkeit ist. Und die kann man ohne Zahlen, Daten und Fakten nicht wegdiskutieren. ;)

Und das mit dem Cache hatten wir schon. Der große L3 Cache ist ein Einmaleffekt. Mal schauen ob der X3D Zen 5 überdurchschnittlich viel bringen wird oder ob er taktnormiert bei dem Abstand wie zwischen Zen 4 vs Zen 5 Vanilla bleiben wird.

Ich habe nie für mich beansprucht die absolute Wahrheit zu kennen, zumal ich dir ja grundsätzlich zustimme. Man muss halt nur nicht jedesmal dieselbe diskussion führen imo. Im übrigen ist auch dein Beitrag nur Meinung ;-)

Und Cache als einmaleffekt zu bezeichnen finde ich seltsam. Cache ist dann seit Jahrzehnten ein einmaleffekt ;). Immer wenn das Speichersubsystem nicht mehr mithalten kann, wird der Cache vergrößert, oder schneller gemacht, etc. Ich sehe nicht das Problem, das weiter so zu handhaben.

[robbitop]

Du bist doch auf mein Posting eingegangen. Hättest du ja nicht gemusst. ;) Es ist immer eine valide Option, nicht zu posten. X-D
Und ich finde auch nicht, dass es nicht "jedes Mal" ist. Wann war das mal davor? Zu Skylake Zeiten? Das ist schon reichlich lange her.

[fondness]

Du bist doch auf mein Posting eingegangen. Hättest du ja nicht gemusst. ;) Es ist immer eine valide Option, nicht zu posten. X-D
Und ich finde auch nicht, dass es nicht "jedes Mal" ist. Wann war das mal davor? Zu Skylake Zeiten? Das ist schon reichlich lange her.

Du hattest eine Phase hier im forum, da hast du das gefühlt hundert Mal erwähnt :D. Und siehe auch meinen Edit oben zum Cache.

[robbitop]

Weiß nicht, welche Phase du meinst. Muss schon eine Weile her sein. Dennoch ist das hier ein offenes Forum und dementsprechend der Dialog. Wenn ein Thema nicht genehm ist, kann man sich jederzeit heraushalten. ;)

Was ich mit dem Einmaleffekt meine ist der große LLC, so wie wir ihn seit dem 5800X3D kennen (oder sogar in etwas langsamerer Form vom i7 5775c).
Das bringt einmal einen großen Sprung weil die Hitrate hochschießt. So wie der integrierte IMC - das brachte auch nur 1x was. Quasi wie ein stetiger offset.

[Der_Korken]

Als Beispiel kann man zB den zusätzlichen Cache-Level als sehr kritisch ansehen. Man darf nicht vergessen wenn eine CPU Daten benötigt überprüft man zuerst jedes Cache-Level und wenn es eine Miss gibt, greift man auf den RAM zu. Das zusätzliche Cache Level bringt vermutlich was in Fällen wo der bisheriger sehr große L2 zu langsam war, kostet aber Memory Latenz, was einem wieder bei der Spiele-Performance auf die Füße fällt.

Eigentlich ist gerade der neue Cache sehr unkritisch, da er offenbar zeitgleich mit dem L2 gequeried wird. Zumindest sieht man bei Lunar Lake nicht, dass die L2-Latenz irgendwie zunimmt (abgesehen davon dass er von 2MB auf 3MB wächst). Der einzige Nachteil dieses Caches ist für mich, dass er potentiell unnötig Strom kostet. Davon sieht man bei realen CPUs bisher aber wenig.

war das nicht so, dass je größer der Cash einer CPU ist desto größer die Latenz?

Ja, wurde ja schon beantwortet. Allerdings muss man bei mehrstufigen Cache-Designs auch immer bedenken, dass die Caches nacheinander durchsucht werden. Man darf also nicht zu viele Cache-Stufen einbauen, weil die hinteren Stufen sonst eine sehr hohe Latenz haben, obwohl sie als solche vielleicht gar nicht so viel eigene Latenz haben. Die einzige Ausnahme ist Intels neuer 192kB-"Zwischencache".

Edit:

Was ich mit dem Einmaleffekt meine ist der große LLC, so wie wir ihn seit dem 5800X3D kennen (oder sogar in etwas langsamerer Form vom i7 5775c).
Das bringt einmal einen großen Sprung weil die Hitrate hochschießt. So wie der integrierte IMC - das brachte auch nur 1x was. Quasi wie ein stetiger offset.

Das finde ich zu schwammig. Ansonsten könnte man auch sagen, dass ein µOp-Cache nicht nachhaltig ist, weil er nur einmal was gebracht hat. Und ein größerer ROB oder breiterer Decoder hat auch "nur einmal" Speed gebracht. Das Cache-Stacking als solches hat imho noch einiges an Potenzial, auch wenn einzelne Designs zwischendrin mal mit Cache ge/über-sättigt sein können.

[fondness]

Eigentlich ist gerade der neue Cache sehr unkritisch, da er offenbar zeitgleich mit dem L2 gequeried wird. Zumindest sieht man bei Lunar Lake nicht, dass die L2-Latenz irgendwie zunimmt (abgesehen davon dass er von 2MB auf 3MB wächst). Der einzige Nachteil dieses Caches ist für mich, dass er potentiell unnötig Strom kostet. Davon sieht man bei realen CPUs bisher aber wenig.



Ja, wurde ja schon beantwortet. Allerdings muss man bei mehrstufigen Cache-Designs auch immer bedenken, dass die Caches nacheinander durchsucht werden. Man darf also nicht zu viele Cache-Stufen einbauen, weil die hinteren Stufen sonst eine sehr hohe Latenz haben, obwohl sie als solche vielleicht gar nicht so viel eigene Latenz haben. Die einzige Ausnahme ist Intels neuer 192kB-"Zwischencache".

Wenn das so ohne weiteres möglich wäre die Caches zeitgleich zu durchsuchen, würde man das immer so machen. Das geht sicher auch nur mit einem tradeoff in anderen Bereichen. Interessant ist zudem nicht, ob die L2 Cache Latenz zunimmt, sondern wie es mit den Caches danach und der memory Latenz aussieht. Aber klar das ist natürlich eine extrem oberflächliche Diskussion ohne wirklich Intel HW eng zu sein und zu wissen, wie das intern genau abläuft.

Edit: das mit dem Cache sehe ich genauso.

[Der_Korken]

Wenn das so ohne weiteres möglich wäre die Caches zeitgleich zu durchsuchen, würde man das immer so machen. Das geht sicher auch nur mit einem tradeoff in anderen Bereichen. Interessant ist zudem nicht, ob die L2 Cache Latenz zunimmt, sondern wie es mit den Caches danach aussieht.

Der Tradeoff ist, dass ein Zugriff mehr Strom verbraucht, weil mehrere Caches zeitgleich durchsucht werden anstatt abzuwarten ob der kleinere nicht gereicht hätte. Und nein, wenn es Latenzproblem gäbe, müsste es beim L2 sichtbar sein und nicht danach, weil der neue Cache zwischen dem alten L1 und L2 sitzt. Der L2 ist bei Lunar Lake nach 17 (statt vorher 16) Takten durchsucht und ab dem 18. Takt geht es in den L3. Der L1,5 spielt dann keine Rolle mehr.

[fondness]

Der Tradeoff ist, dass ein Zugriff mehr Strom verbraucht, weil mehrere Caches zeitgleich durchsucht werden anstatt abzuwarten ob der kleinere nicht gereicht hätte. Und nein, wenn es Latenzproblem gäbe, müsste es beim L2 sichtbar sein und nicht danach, weil der neue Cache zwischen dem alten L1 und L2 sitzt. Der L2 ist bei Lunar Lake nach 17 (statt vorher 16) Takten durchsucht und ab dem 18. Takt geht es in den L3. Der L1,5 spielt dann keine Rolle mehr.

Ok du meinst mit L2 den l3, dann passt es. Ich finde die Bezeichnung als l1.5 seltsam. Ob das allerdings der einzige tradeoff ist stelle ich in Zweifel, erscheint mir nicht so kritisch wenn man dafür memory Latenz gewinnt die sehr hart erarbeitet ist. Aber wie gesagt das ist im Endeffekt Kaffeesatzleserei.

[robbitop]

Das finde ich zu schwammig. Ansonsten könnte man auch sagen, dass ein µOp-Cache nicht nachhaltig ist, weil er nur einmal was gebracht hat. Und ein größerer ROB oder breiterer Decoder hat auch "nur einmal" Speed gebracht. Das Cache-Stacking als solches hat imho noch einiges an Potenzial, auch wenn einzelne Designs zwischendrin mal mit Cache ge/über-sättigt sein können.
Ja aber der Effekt nimmt irgendwann stark ab. Der i7 5775c hat 2015 128 MiB LLC eingeführt. Der 5800X3D dann 2022 deutlich schnellere 96 MiB.
Jetzt könnte man auch mehr verbauen - das würde aber von der Latenz langsamer werden und auch immer weniger bringen.
So extrem viel Fortschritt ist da so schnell nicht zu erwarten vor dem Hintergrund dass SRAM praktisch kaum noch shrinkt.

ROB und uOP Caches sind schon was anderes. Haben aber ab einem gewissen Punkt ähnliche Charakteristik (wie fast alles) in Bezug auf deminishing returns.

Ja ist schwammig formuliert aber du weißt ja wie es gemeint ist. ;) (davon gehe ich bei dem Publikum in diesem Forum aus, dass man nicht alles perfekt ausdrücken muss weil das Publikum aus dem Kontext verstehen kann)

[fondness]

Ja aber der Effekt nimmt irgendwann stark ab. Der i7 5775c hat 2015 128 MiB LLC eingeführt. Der 5800X3D dann 2022 deutlich schnellere 96 MiB.
Jetzt könnte man auch mehr verbauen - das würde aber von der Latenz langsamer werden und auch immer weniger bringen.
So extrem viel Fortschritt ist da so schnell nicht zu erwarten vor dem Hintergrund dass SRAM praktisch kaum noch shrinkt.

ROB und uOP Caches sind schon was anderes. Haben aber ab einem gewissen Punkt ähnliche Charakteristik (wie fast alles) in Bezug auf deminishing returns.

Ja ist schwammig formuliert aber du weißt ja wie es gemeint ist. ;) (davon gehe ich bei dem Publikum in diesem Forum aus, dass man nicht alles perfekt ausdrücken muss weil das Publikum aus dem Kontext verstehen kann)

Das ergibt für mich noch immer keinen Sinn. Man hat vor Jahrzehnten ein paar Kb Cache eingeführt. Ja der Effekt nimmt etwas ab, das hat aber niemanden daran gehindert die Caches immer weiter zu vergrößern. Auch mehr als 96mb würde bei entsprechenden Anwendungen natürlich die hitrate weiter steigern.

[robbitop]

Klar würde mit anderen Anwendungen auch mehr Cache noch in der Hitrate skalieren. Aber anscheinend mit heutigen Spielen nicht unbedingt bzw deminishing returns. Und mehr würde auch immer mehr die Kosten nach oben treiben weil SRAM nicht mehr kleiner wird. Und das ist eine wesentliche Änderung zwischen damals und heute. Damals gab es mit jedem Node pro mm2 mehr SRAM. Jetzt ist das vorbei.

[fondness]

Klar würde mit anderen Anwendungen auch mehr Cache noch in der Hitrate skalieren. Aber anscheinend mit heutigen Spielen nicht unbedingt. Und mehr würde auch immer mehr die Kosten nach oben treiben weil SRAM nicht mehr kleiner wird.

Wie kommst du darauf, dass mehr Cache bei Spielen nichts mehr bringt?

[fondness]

Intel Core Ultra 200K pricing leaked: 285K at $589, 265K priced at $394, and 245K for $309

https://videocardz.com/newz/intel-core-ultra-200k-pricing-leaked-285k-at-589-265k-priced-at-394-and-245k-for-309

Preis bleibt also gleich oder sinkt sogar leicht ggü Vorgängern. Anhand der Leistung erwartungsgemäß.

[Zossel]

und SRAM wird nicht aus MOSFEDs aufgebaut?
Das ständige refreshen der DRAM Zellen habe ich gar nicht gemeint.
Die Menge der MOSFEDs, die eine Cash Zelle benötigt ist wesentlich größer als die einer DRAM Zelle.

Das man Energie benötigt um einen Zustand bewusst zu beeinflussen ist eine Binse.

Und selbst bei der berühmtesten Katze der Welt muss man den Deckel aufmachen :-)

[Zossel]

Ok du meinst mit L2 den l3, dann passt es. Ich finde die Bezeichnung als l1.5 seltsam. Ob das allerdings der einzige tradeoff ist stelle ich in Zweifel, erscheint mir nicht so kritisch wenn man dafür memory Latenz gewinnt die sehr hart erarbeitet ist. Aber wie gesagt das ist im Endeffekt Kaffeesatzleserei.

Der Mensch von Chips&Cheese wird das sicherlich ausmessen und uns ein schickes Diagramm liefern.

BTW: So ein Diagramm ist schon wesentlich schicker als diese Zahlenwerte die dieses Windows-Tool dessen Screenshots immer wieder gezeigt werden generiert.
Da muss dieser neue Cache erst rein programmiert werden.

[Zossel]

Wie kommst du darauf, dass mehr Cache bei Spielen nichts mehr bringt?

Gibt es eigentlich Messungen der Cache, TLB, usw. Hitraten von Spielen?

[Zossel]

Und das mit dem Cache hatten wir schon. Der große L3 Cache ist ein Einmaleffekt.

Du schließt zukünftige Verbesserungen am CPU-Caches aus?

[Zossel]

Ja, wurde ja schon beantwortet. Allerdings muss man bei mehrstufigen Cache-Designs auch immer bedenken, dass die Caches nacheinander durchsucht werden. Man darf also nicht zu viele Cache-Stufen einbauen, weil die hinteren Stufen sonst eine sehr hohe Latenz haben, obwohl sie als solche vielleicht gar nicht so viel eigene Latenz haben. Die einzige Ausnahme ist Intels neuer 192kB-"Zwischencache".


IMHO gibt es schon länger Cache-Hierarchien wo ein Ln-1 Cache die Tags des Ln Cache hält.

Möglicherweise ist das der Zaubertrick den uns Intel mal wieder als neu verkaufen will.

[robbitop]

Wie kommst du darauf, dass mehr Cache bei Spielen nichts mehr bringt?

Der X3D skaliert viel viel weniger mit Latenztuning als die non X3D. Klares Zeichen von diminishing returns IMO.

[robbitop]

Du schließt zukünftige Verbesserungen am CPU-Caches aus?

Nicht generell und grundsätzlich. Bitte aus dem Kontext lesen und nicht versuchen das Haar in der Suppe zu suchen. Es nervt immer umständlich alles wasserdicht hoch und runter beschreiben zu müssen damit neunmalkluge Schlaubi Schlümpfe nicht getriggert werden. Ich gehe davon aus, dass die hier Anwesenden gut informiert sind, mitdenken und konstruktiv diskutieren.
Gemeint ist natürlich relativ mittelfristig und vor dem Hintergrund dass sram Zellen praktisch nicht mehr schrumpfen mit modernen Nodes.

[ChaosTM]

Its 3DCenter...
Die Schlaubischlumpf Dichte ist die höchste in allen mir bekannten Tech-Foren. ^^

Add.: ich gehör da die in bestimmten Fäden auch dazu..

[Gipsel]

IMHO gibt es schon länger Cache-Hierarchien wo ein Ln-1 Cache die Tags des Ln Cache hält.Gleichzeitiges/paralleles Durchsuchen dürfte da sinnvoller sein.
Bei (vorwiegend) exklusiven Caches kann man aber andersrum die Tags des Ln-1 Caches im Ln-Cache duplizieren, weil man so die Cachekohärenz ziwschen mehreren getrennten Ln-Caches schneller sicherstellen kann (man muß nur die Ln-Cache[s] checken, nicht auch noch alle Ln-1-Caches). Aufgrund des deutlich größeren Tags eines Ln-Caches kann das sonst im Ln-1-Cache verdammt viel Platz wegnehmen. Ein 3 MB L2 wie bei Arrowlake benötigt ~384kB Tags, das wird ungünstig bei den nur 192kB L1/L1.5. Und für die 192kB L1/L1.5 messen die Tags ~24kB, also auch schon die Hälfte des L0. Und die Arrays für die Tags sind typischerweise größer als für die eigentlichen Cachelines (weil für die schnelle Suche anders drauf zugegriffen werden muß).

[Zossel]

Klar würde mit anderen Anwendungen auch mehr Cache noch in der Hitrate skalieren. Aber anscheinend mit heutigen Spielen nicht unbedingt bzw deminishing returns. Und mehr würde auch immer mehr die Kosten nach oben treiben weil SRAM nicht mehr kleiner wird. Und das ist eine wesentliche Änderung zwischen damals und heute. Damals gab es mit jedem Node pro mm2 mehr SRAM. Jetzt ist das vorbei.
Der neunmalkluge Schlaubi Schlümpf erinnert sich gerade an dies:
The CFET SRAM cell area, write margin, read margin, and performance are evaluated and compared with FinFET (FF)-based SRAM. The CFET 111 and 122 SRAM provides up to 43.75% and 35% area gain w.r.t. FF 111 and 122 SRAM, respectively. Moreover, the CFET 122 SRAM has 11% faster read operation than FF 122 SRAM, respectively.
https://ieeexplore.ieee.org/document/9604065

Vielleicht solltest du einfach weniger Basta-mässig formulieren.

[Gipsel]

Und ganz allgemein für die Cachegrößen, das man zuallererst mal auf einer logarithmischen Skale betrachten. Um einen vergleichbaren Vorteil wie beim Schritt von den 32MB L3 auf die 96MB L3 der X3Ds zu sehen, muß man den L3 wieder um einen Faktor 3 vergrößern (also mindestens mal so gepflegte 288MB pro CCD). Dies geht allerdings davon aus, daß man ähnlich verteilte Datenlokalität auf allen Größenskalen hat. Praktisch wird dies aber durch die effektiv aktive Größe des Workingsets begrenzt (was recht unscharf definiert ist). Bei typischen Desktopanwendungen (die wenig datenintensiv sind) dürfte das vermutlich oft nur wenige 10 MB sein. Datenintensive Anwendungen können natürlich von Cache oft kaum genug bekommen. Bei Spielen sind es offensichtlich meist deutlich mehr als 32MB (außer ein paar ganz alten, wo offenbar machmal quasi Alles bereits in 32MB paßt und der X3D dann quasi keinen Vorteil mehr bietet). Ich könnte mir vorstellen, daß bei einigen hundert MB bis auf Ausnahmefällen auch bei modernen Spielen Schluß ist (die belegen zwar etliche GB, aber jeden Frame mehrfach angefaßt wird deutlich weniger). Dies schneidet die mögliche Datenlokalität bei einer gewissen Größe quasi ab, noch größere Caches bringen dann nur noch sehr wenig. Aber 256MB oder auch 384MB sollten bei einer merklichen Anzahl an Spielen noch was bringen, sollte man es hinbekommen, daß die Latenz des Caches kaum steigt (z.B. durch cleveres 3D-Stacking mit 4x 64MB-Dies). Dies dürfte im Moment aber wohl zu teuer sein, als daß es sich lohnt. Aber in ein paar Jahren, wer weiß. Aber wenn das aktuell wird könnten Spiele wohl auch von 1GB Cache oder mehr profitieren, weil die dann auch mehr nutzen. ;)

[fondness]

Der neunmalkluge Schlaubi Schlümpf erinnert sich gerade an dies:

https://ieeexplore.ieee.org/document/9604065

Vielleicht solltest du einfach weniger Basta-mässig formulieren.

Da braucht man nicht mal ein ieee paper, AMD hat bei Zen 5 die Cache Packdichte mal eben verdoppelt(!). Das es da keine Entwicklung mehr gibt sehe ich nicht.

[fondness]

Der X3D skaliert viel viel weniger mit Latenztuning als die non X3D. Klares Zeichen von diminishing returns IMO.

Naja das ist logisch, wenn ich weniger memory bounded bin bringt schnellerer Speicher auch weniger. So wie ich dich verstanden habe ging es ja um zukünftige Skalierung. Erstmals ist ja der 3D Cache ausreichend.

[fondness]

Gibt es eigentlich Messungen der Cache, TLB, usw. Hitraten von Spielen?

Nicht dass ich wüsste.

[Zossel]

Nicht dass ich wüsste.

Wie ist das eigentlich mit wine/proton, laufen die laufenden Windows-Applikationen als reguläre OS-Prozesse um sich mit perf daran zu hängen zu können?
Notfalls könnte man auch eine ganze VM mit durchgereichter GPU messen.

So könnte man mit überschaubaren Aufwand einen ersten Eindruck bekommen was da eigentlich vor sich geht.

https://perf.wiki.kernel.org/index.php/Tutorial

Hier mal ein Ergebnis von einem just4fun Test den ich mal mit xz&Co bzgl. hugepages gemacht habe, diverse weitere Counter bzgl. Caches kann man da genauso angeben:

Performance counter stats for 'sh -c GLIBC_TUNABLES=glibc.malloc.hugetlb=0 xz -6 < b > /dev/null':

131.477.846 dTLB-load-misses
146.717 iTLB-load-misses

16,049542952 seconds time elapsed

15,992333000 seconds user
0,056764000 seconds sys

Performance counter stats for 'sh -c GLIBC_TUNABLES=glibc.malloc.hugetlb=2 xz -6 < b > /dev/null':

1.241.753 dTLB-load-misses
84.440 iTLB-load-misses

14,517356365 seconds time elapsed

14,494404000 seconds user
0,022724000 seconds sys

Und die "Prozente" dazu (Wir sind ja im 3DCenter Forum):

$ python3 -c "print((16.049542952/14.517356365))"
1.1055417080408634
$ python3 -c "print(1.0/(16.049542952/14.517356365))"
0.9045339427058845
$

Und die Testschleife dazu:

#!/bin/bash
bash -c 'export log=/tmp/log-$$; echo $log; for cmd in zstd bzip2 xz lzip gzip; do for level in $(seq 0 9); do for huge in $(seq 0 2); do for i in $(seq 0 4); do dd if=/dev/zero of=/dev/null conv=ascii count=64 bs=1M 2> /dev/null; perf stat -e dTLB-load-misses,iTLB-load-misses sh -c "GLIBC_TUNABLES=glibc.malloc.hugetlb=$huge $cmd -$(if [ $cmd = "bzip2" ] && [ $level -eq 0 ]; then echo 1; else if [ $cmd = zstd ]; then echo $(( $level * 2 + 1 )); else echo $level; fi fi) < b > /dev/null" 2>> $log ; done; done; done; done'

[Der_Korken]

Gibt es eigentlich Messungen der Cache, TLB, usw. Hitraten von Spielen?

Am ehesten sowas: https://chipsandcheese.com/p/hot-chips-2023-characterizing-gaming-workloads-on-zen-4?utm_source=publication-search

Da wird eine Menge gemessen. Ich interpretiere das so, dass Frontend-Latenzen, Load-Latenzen und vielleicht ein zu kleiner ROB die Flaschenhälse bei Zen 4 sind. Mit dem 3D-Cache erschlägt man den zweiten Punkt offenbar ein gutes Stück weit, sonst würde der nicht so reinhauen bei Spielen.

Mit Frontend-Latenzen kann ich nicht so viel anfangen. Der BTB ist bei Zen 5 massiv schneller geworden, weil der L1BTB bei gleicher Latenz jetzt einfach mal 16K statt 1,5K Einträge hat (wie auch immer das möglich ist ...). Das hat aber bisher nicht so viel gerissen. Eventuell hätte es geholfen wenn ein Thread beide Decode-Cluster hätte nutzen können, um bei branchigem Code zeitgleich an mehreren Stellen ansetzen zu können (könnte der µOp-Cache das eigentlich?). Lion Cove ist mit einem 8er Decoder ähnlich "unflexibel" wie Zen 5, nur dass er noch mehr Instruktionen am Stück decoden kann. Wenn ich mir aber angucke, dass 17% der Instruktionen Branches sind, bringt das überhaupt noch was? Im Erwartungswert habe ich nach einem Branch nur 5-6 Instruktionen stehen bevor wieder ein Branch kam. Das gleiche gilt auch für den µOp-Cache: Mit 9 Instruktionen wie Zen 4 decoded man doch quasi immer jede Menge über den nächsten Branch hinaus ohne zu wissen, ob er genommen wird. Weiß man wie der µOp bei Intel organisiert ist?

Sehe gerade, er schon mit einem 7950X3D testet und trotzdem das Backend am stärksten am Speicher hängt. Da kann man sich ausrechnen, wie das ohne 3D-Cache aussieht. Die L2-Hitrate ist hier relativ schlecht, würde ich sagen. Da könnten sich die 2-3MB von Intel durchaus auszahlen.

Ansonsten bringen weder bei Zen 5 noch bei Lion Cove das 6-wide INT große Vorteile.

[Zossel]

Am ehesten sowas: https://chipsandcheese.com/p/hot-chips-2023-characterizing-gaming-workloads-on-zen-4?utm_source=publication-search

Da wird eine Menge gemessen. Ich interpretiere das so, dass Frontend-Latenzen, Load-Latenzen und vielleicht ein zu kleiner ROB die Flaschenhälse bei Zen 4 sind. Mit dem 3D-Cache erschlägt man den zweiten Punkt offenbar ein gutes Stück weit, sonst würde der nicht so reinhauen bei Spielen.

Ja, der benutzt auch perf. Mit Wine/Proton oder kompletten VMs könnte man wohl auch auch Windows Spiele vermessen.

Ich sehe gerade das man mit perf auch die Lieblingsmetrik des 3DCenter Forums vermessen kann, die IPC!!!

Deswegen auch gleich ein Beispiel wo eine "höhere" IPC schlechter ist. AES mit und ohne AES-NI :-)

$ perf stat -B -ecycles:u,instructions:u -a sh -c 'OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-gcm'
You have chosen to measure elapsed time instead of user CPU time.
Doing AES-128-GCM for 3s on 16 size blocks: 31436929 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 64 size blocks: 9129367 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 256 size blocks: 5219182 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 1024 size blocks: 1380650 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 8192 size blocks: 174923 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 16384 size blocks: 87486 AES-128-GCM's in 3.00s
version: 3.0.13
built on: Tue Aug 20 17:05:36 2024 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/openssl-WgbqpY/openssl-3.0.13=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/openssl-WgbqpY/openssl-3.0.13=/usr/src/openssl-3.0.13-0ubuntu3.4 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=3
CPUINFO: OPENSSL_ia32cap=0x7cd83209078bffff:0x0 env:~0x200000200000000
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
AES-128-GCM 167663.62k 194759.83k 445370.20k 471261.87k 477656.41k 477790.21k

Performance counter stats for 'system wide':

94.708.594.987 cycles:u
377.687.072.083 instructions:u # 3,99 insn per cycle

18,003199519 seconds time elapsed

$ perf stat -B -ecycles:u,instructions:u -a sh -c 'openssl speed -elapsed -evp aes-128-gcm'
You have chosen to measure elapsed time instead of user CPU time.
Doing AES-128-GCM for 3s on 16 size blocks: 202077793 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 64 size blocks: 181743777 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 256 size blocks: 102970344 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 1024 size blocks: 29340930 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 8192 size blocks: 5939211 AES-128-GCM's in 3.00s
Doing AES-128-GCM for 3s on 16384 size blocks: 3088139 AES-128-GCM's in 3.00s
version: 3.0.13
built on: Tue Aug 20 17:05:36 2024 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -fzero-call-used-regs=used-gpr -DOPENSSL_TLS_SECURITY_LEVEL=2 -Wa,--noexecstack -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/openssl-WgbqpY/openssl-3.0.13=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/openssl-WgbqpY/openssl-3.0.13=/usr/src/openssl-3.0.13-0ubuntu3.4 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=3
CPUINFO: OPENSSL_ia32cap=0x7ed8320b078bffff:0x405fdef1bf97a9
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
AES-128-GCM 1077748.23k 3877200.58k 8786802.69k 10015037.44k 16218005.50k 16865356.46k

Performance counter stats for 'system wide':

94.187.846.882 cycles:u
248.086.416.040 instructions:u # 2,63 insn per cycle

18,003323210 seconds time elapsed

$ lscpu | grep "Model n"
Model name: AMD Ryzen 7 7700 8-Core Processor
$ lsb_release -a
No LSB modules are available.
Distributor ID: Linuxmint
Description: Linux Mint 22
Release: 22
Codename: wilma
$

[mksn7]

[QUOTE=Zossel;13627560]
Deswegen auch gleich ein Beispiel wo eine "höhere" IPC schlechter ist. AES mit und ohne AES-NI :-)
[CODE]

Ja, Vektorisierung ist auch immer ganz schlecht für die IPC... Auch gut: spin locks haben schön hohe IPC, deswegen haben codes mit load imbalance manchmal höhere IPC. Auch schon gesehen in Echt, da hieß es eine HPC Anwendung wäre gut optimiert, weil hohe IPC. Dabei haben einfach threads viel Zeit in der OpenMP barrier verbracht.

Ach ja, mit perf oder Likwid könnte man schonmal was messen. Was für Spiele gehen denn unkompliziert unter Linux? Ich hab eigentlich gerade keine Lust mich mit Proton/Wine zu beschäftigen.

[Zossel]

Auch gut: spin locks haben schön hohe IPCGenau mein Humor :-)

[robbitop]

Der neunmalkluge Schlaubi Schlümpf erinnert sich gerade an dies:

https://ieeexplore.ieee.org/document/9604065

Vielleicht solltest du einfach weniger Basta-mässig formulieren.
Das muss erstmal auf Seriensilizium ankommen. TSMC war bis dato sehr klar, dass das SRAM shrinken (zumindest die Zellgröße selbst) erstmal vorbei ist.
Und ich habe ja auch "mittelfristig" geschrieben. Und wie ich schon geschrieben habe - bitte im Kontext denken.

Und ganz allgemein für die Cachegrößen, das man zuallererst mal auf einer logarithmischen Skale betrachten. Um einen vergleichbaren Vorteil wie beim Schritt von den 32MB L3 auf die 96MB L3 der X3Ds zu sehen, muß man den L3 wieder um einen Faktor 3 vergrößern (also mindestens mal so gepflegte 288MB pro CCD). Dies geht allerdings davon aus, daß man ähnlich verteilte Datenlokalität auf allen Größenskalen hat. Praktisch wird dies aber durch die effektiv aktive Größe des Workingsets begrenzt (was recht unscharf definiert ist). Bei typischen Desktopanwendungen (die wenig datenintensiv sind) dürfte das vermutlich oft nur wenige 10 MB sein. Datenintensive Anwendungen können natürlich von Cache oft kaum genug bekommen. Bei Spielen sind es offensichtlich meist deutlich mehr als 32MB (außer ein paar ganz alten, wo offenbar machmal quasi Alles bereits in 32MB paßt und der X3D dann quasi keinen Vorteil mehr bietet). Ich könnte mir vorstellen, daß bei einigen hundert MB bis auf Ausnahmefällen auch bei modernen Spielen Schluß ist (die belegen zwar etliche GB, aber jeden Frame mehrfach angefaßt wird deutlich weniger). Dies schneidet die mögliche Datenlokalität bei einer gewissen Größe quasi ab, noch größere Caches bringen dann nur noch sehr wenig. Aber 256MB oder auch 384MB sollten bei einer merklichen Anzahl an Spielen noch was bringen, sollte man es hinbekommen, daß die Latenz des Caches kaum steigt (z.B. durch cleveres 3D-Stacking mit 4x 64MB-Dies). Dies dürfte im Moment aber wohl zu teuer sein, als daß es sich lohnt. Aber in ein paar Jahren, wer weiß. Aber wenn das aktuell wird könnten Spiele wohl auch von 1GB Cache oder mehr profitieren, weil die dann auch mehr nutzen. ;)
This.

[dildo4u]

Arrow Lake Präsentation in Englisch


https://videocardz.com/newz/intel-core-ultra-200s-arrow-lake-s-desktop-processors-announced-lion-cove-skymont-xe-lpg-npu-and-lga-1851

[aceCrasher]

Arrow Lake Präsentation in Englisch


https://videocardz.com/newz/intel-core-ultra-200s-arrow-lake-s-desktop-processors-announced-lion-cove-skymont-xe-lpg-npu-and-lga-1851
Also haben sich die Gerückte bewahrheitet, Arrowlake ist im Gaming wirklich nicht schneller als Raptorlake. Das wird eine harte Zeit gegen den 9800X3D. Wenn ein Hersteller selbst schon ausschließlich von Perf/W gains kann man einen realen Leistungssprung quasi vergessen. Abgesehen davon finde ich es trotzdem schön dass Intel sich was den Verbrauch angeht wieder in realistische Sphären zurückentwickelt.

[Hakim]

Ja dennoch wäre es gut gewesen wenn man den Vorgänger in Spielen zumindest leicht schlagen würde. Glaube Leute die bei AMDs 7xxx oder intels raptoren zugeschlagen haben können halt beide neuen gens ez und ohne schlechtes Gewissen überspringen. Ok wenn man Stromzähler nicht berücksichtigt :)

[basix]

Ich sehe es trotzdem enorm positiv. Man ist gleich schnell / marginal schneller, doch man verbraucht massiv weniger Energie. Einen 9800X3D und Co. wird man definitiv nicht schlagen. Aber man ist nicht schlecht aufgestellt gegen alles, was nicht X3D ist oder falls man mehr MT-Performance als ein 9800X3D benötigt. Selbst ein 245K dürfte einem 9700X in den meisten Szenarien auf Augenhöhe begegnen (ST, MT, Gaming), vermutlich aber auch nicht wirklich weniger teuer sein.

Unter dem Strich:
Intel ist konkurrenzfähig mit dem Zen 5 Portfolio, mit Ausnahme maximaler Gaming-Performance.

[ChaosTM]

Definitiv.
Starke Konkurrenz sorgt für Innovationen.
Hilft uns allen.. (cheesy, ich weiß..)

[Cubitus]

Berechnet man den Leerlaufverbrauch mit ein, so benötigt ein Intel im Desktopmodus 2-3 Watt.

Das ist besser als ein AMD, der 30-50 Watt im Leerlauf oder beim browsen säuft.
Addiert man dies, erweist sich der Intel am Ende des Tages sogar als effizienter. :wink:

[MiamiNice]

Ich sehe es trotzdem enorm positiv. Man ist gleich schnell / marginal schneller, doch man verbraucht massiv weniger Energie. Einen 9800X3D und Co. wird man definitiv nicht schlagen. Aber man ist nicht schlecht aufgestellt gegen alles, was nicht X3D ist oder falls man mehr MT-Performance als ein 9800X3D benötigt. Selbst ein 245K dürfte einem 9700X in den meisten Szenarien auf Augenhöhe begegnen (ST, MT, Gaming), vermutlich aber auch nicht wirklich weniger teuer sein.

Unter dem Strich:
Intel ist konkurrenzfähig mit dem Zen 5 Portfolio, mit Ausnahme maximaler Gaming-Performance.

Das sehe ich leider komplett anders. Bei den getesteten Games auf den Folien sind ausschließlich neuere Vertreter dabei. Keine Indie Games, keine VR Games, keine MMORPGs und keine Aufbaugames wie z.b. Anno 1800. Also die ganze Palette an Games die eher nicht so sehr an den Latenzen hängen. Man kann imo davon ausgehen, dass ARL im Vergleich zu RPL in den Spielen, weswegen man sich einen Intel kauft, eher noch weiter absackt als auf den Folien zu sehen. Niemanden interessiert, ob er bei F12024 200 oder 250 FPS hat. Aber ob man bei Anno 40 oder 60 FPS im Endgame hat, ist schon relevant.
Intel war immer gut um nicht optimierten Kram zu beschleunigen. So Spiele wie z.b. Star Citizen oder Escape from Tarkov. Aufgrund des schnellen Speichersubsystems konnte man diese Games immer mit Power erschlagen, bis sie halbwegs anständig liefen. Mit einem zusammengeklebtem Chip auf Sparflamme mit internen Latenzen direkt aus der Hölle, ist das leider nicht mehr drin.

Daher nicht mit Ausnahme der maximalen Gaming Performance, sondern mit Ausnahme jedweder Gaming Performance abseits des AAA Marktes. Intel ist nun nicht mehr erste Wahl für Spieler abseits AAA, die konstante Power haben wollen. Man hat entweder mit weniger Leistung zu leben bei Intel, oder einen AMD mit inkonsitenter Leistung zu kaufen (3D Cache funktioniert nicht in jedem Game gut).

[fondness]

Ich sehe es trotzdem enorm positiv. Man ist gleich schnell / marginal schneller, doch man verbraucht massiv weniger Energie. Einen 9800X3D und Co. wird man definitiv nicht schlagen. Aber man ist nicht schlecht aufgestellt gegen alles, was nicht X3D ist oder falls man mehr MT-Performance als ein 9800X3D benötigt. Selbst ein 245K dürfte einem 9700X in den meisten Szenarien auf Augenhöhe begegnen (ST, MT, Gaming), vermutlich aber auch nicht wirklich weniger teuer sein.

Unter dem Strich:
Intel ist konkurrenzfähig mit dem Zen 5 Portfolio, mit Ausnahme maximaler Gaming-Performance.

Enorm positiv halte ich doch für ein klein wenig übertrieben. :D
Defacto liefert Intel 2 Jahre später dieselbe Performance mit weniger Leistungsaufnahme. Wobei das weniger an Leistungsaufnahme wohl ausschließlich am TSMC 3nm Prozess liegt und den niedrigeren Taktraten.

Man fällt zudem bei der Entwicklungsgeschwindigkeit immer weiter zurück. Der 13900K war noch klar schneller als der 5800X3D. Der 14900K war bereits knapp hinter dem 7800X3D. Der 285K wird wohl deutlich hinter dem 9800X3D liegen.

Der Einmaleffekt, als man endlich den 10nm Prozess in den Griff bekam und das unendliche Skylake-Refresh-Desaster in 14nm++++++ beenden konnte, ist also vollständig verpufft.

[dreas]

Kommen eigentlich heute noch Reviews?

[fondness]

Kommen eigentlich heute noch Reviews?

24.

[x-force]

Man hat entweder mit weniger Leistung zu leben bei Intel, oder einen AMD mit inkonsitenter Leistung zu kaufen (3D Cache funktioniert nicht in jedem Game gut).

x3d funktioniert in jedem game. wenn du es stressfrei willst, darfst du halt nur 8 kerne kaufen.
da, wo er sich nicht gegen non x3d absetzt, hast du eh genügend power.

insbesondere deine beiden beispiele tarkov und das groschengrab star citizen laufen mit x3d wesentlich besser.

[basix]

Enorm positiv halte ich doch für ein klein wenig übertrieben. :D
Defacto liefert Intel 2 Jahre später dieselbe Performance mit weniger Leistungsaufnahme. Wobei das weniger an Leistungsaufnahme wohl ausschließlich am TSMC 3nm Prozess liegt und den niedrigeren Taktraten.

Man fällt zudem bei der Entwicklungsgeschwindigkeit immer weiter zurück. Der 13900K war noch klar schneller als der 5800X3D. Der 14900K war bereits knapp hinter dem 7800X3D. Der 285K wird wohl deutlich hinter dem 9800X3D liegen.

Der Einmaleffekt, als man endlich den 10nm Prozess in den Griff bekam und das unendliche Skylake-Refresh-Desaster in 14nm++++++ beenden konnte, ist also vollständig verpufft.

Ausserhalb von Ausnahmen und schlecht optimierten Spielen (das was Miami anspricht): Wo limitiert die CPU Performance eines 14900K? Da nehme ich deutlich lieber reduzierten Stromverbrauch ;) Die paar wenigen Enthusiasten machen beim Umsatz für Intel keine Höschen nass. Ich habe auch gerne nonplusultra Performance aber wenn ich 40 -> 60fps bei Anno haben will, sind auch +20% Performance bei weitem nicht genug. Da wäre es sinnvoller, die Software zu optimieren. Epic hat bei der UE 5.5 anscheinend nochmals 2x CPU-Performance rausgeholt (2x gab es schon bei 5.3 -> 5.4). Was interessieren mich hier also +10...20% CPU-Performance? Die Entwickler sollen ihre Spiele ordentlich programmieren, nur immer "mehr HW draufwerfen" klappt einfach nicht mehr, das gibt die Halbleiter-Entwicklung nicht mehr her. Das selbe gilt auch generell für SW. Wenn man die HW adäquat nutzt, ist eine heutige CPU extrem schnell.

[Lehdro]

Die Entwickler sollen ihre Spiele ordentlich programmieren, nur immer "mehr HW draufwerfen" klappt einfach nicht mehr, das gibt die Halbleiter-Entwicklung nicht mehr her. Das selbe gilt auch generell für SW.
Gibt genug Fälle von denen wir wissen dass da softwaretechnisch nichts mehr kommt und wir das nur mit Leistung (nicht Watt) erschlagen können. Gerade im Gaming. Da gibt es eben keine andere Option als auf noch stärkere Hardware zu hoffen.

<<<Dieser Abschnitt bezieht sich explizit aufs Gaming.>>>
Bin eh gespannt wie das Urteil der Reviewer ausfallen wird, AMD wurde trotz Preissenkungen und (überschaubarer) Mehrperformance ziemlich hart angegangen - bei gleichbleibender Plattform. Wie das wohl bei Intel mit Leistungsrückschritten trotz gleichbleibenden Preisen aussieht? Wenn man AMD nicht mindestens bei der Effizienz einholt, besser noch deutlich überholt, kann das eigentlich nur negativ ausfallen. Eine komplett neue Plattform mit Performanceeinbußen ist eigentlich ziemlich einzigartig.
<<<Dieser Abschnitt bezieht sich explizit aufs Gaming.>>>

[Prinzenrolle]

Arrow Lake Präsentation in Englisch


Finde ich jetzt gar nicht so schlecht. Vorrausgesetzt die Werte stimmen, hat man abgesehen von 15-20% bei Gaming (die wohl auf den 9800X3D fehlen werden) eigentlich ne ganz gute CPU gebaut.

Jetzt braucht man halt auch eine Variante mit Zusatzcache.
Ziemliches Kräftemessen auf Augenhöhe würde ich behaupten. Vielleicht geht noch etwas mit Ringbus/RAM OC.

[ChaosTM]

"Ordentlich programmieren" stößt auch schön langsam an unsere Grenzen als Sapiens.
Wir brauchen was besseres und da..

ok.. ich hab in letzter Zeit wirklich zu viel über maschinelles Lernen und A(G)I gelesen..

[dildo4u]

Finde ich jetzt gar nicht so schlecht. Vorrausgesetzt die Werte stimmen, hat man abgesehen von 15-20% bei Gaming (die wohl auf den 9800X3D fehlen werden) eigentlich ne ganz gute CPU gebaut.

Jetzt braucht man halt auch eine Variante mit Zusatzcache.
Ziemliches Kräftemessen auf Augenhöhe würde ich behaupten. Vielleicht geht noch etwas mit Rinbus/RAM OC.
Wo ist das auf Augenhöhe wenn Intel dafür 3nm braucht?
AMD kann Zen 5 Preise um 50% reduzieren und trotzdem Geld machen.

[MiamiNice]

x3d funktioniert in jedem game. wenn du es stressfrei willst, darfst du halt nur 8 kerne kaufen.
da, wo er sich nicht gegen non x3d absetzt, hast du eh genügend power.

insbesondere deine beiden beispiele tarkov und das groschengrab star citizen laufen mit x3d wesentlich besser.

Da hast Du nur bedingt recht und schrieb glaub ich "Spiele wie". Beide Games sind auch schon älter. Neuere Games aus dem Bereich sind hier meist nicht bekannt, daher meine Nennung.
EFT war am Release gar nicht auf AMD HW spielbar, auf Intel nur bedingt. Hartes ST und Latenz Problem. Das ging erst gut mit OC Intels und massig RAM OC. Mittlerweile ist es anders.
Bei SC fegen noch heute die OC RPLs mit den Zen Auskopplungen den Boden auf, zumindest in den Städten, in Weltraum sind wir eh bei 200+ FPS. Vor dem Gen 12 Update war bei SC gar kein Boden mit den Ryzens dieser Welt zu sehen.
Beide Spiele haben sich entwickelt und der 3DCache wurde auch immer besser. Trotzdem gibt es auch noch heute Games denen der 3DCache nicht schmeckt. Je weiter man sich von den quad A Titeln dieser Welt entfernt, desto eher merkt man das.
Da kann man schon von inkosistent reden ggü. dem was Intel bisher auf den Markt gebraucht hat. Intel hat das Problem quasi bei der Wurzel gepackt, AMD umgeht das Problem mit dem Cache. Umgehungen sind nicht immer gut.

Wo ist das auf Augenhöhe wenn Intel dafür 3nm braucht?
AMD kann Zen 5 Preise um 50% reduzieren und trotzdem Geld machen.

Angeblich kostet Intel das Fremdfertigen weniger als in den eignen Fabs. Da gab es wohl mal irgendeinen Post. Habe ich in einem anderen Forum gelesen, leider keine Links.

[dildo4u]

3nm TSMC kostet trotzdem mher als 4nm, nicht mal Nvidia zahlt das.

[MSABK]

What, Inte nutzt hier TSMc 3nm? Hatte ich total vergessen, da ist es ja nicht gerade prickelnd was die abliefern. Da kann AMD entspannter sein mit Zen6 in 3nm als Konter.

[dildo4u]

What, Inte nutzt hier TSMc 3nm? Hatte ich total vergessen, da ist es ja nicht gerade prickelnd was die abliefern. Da kann AMD entspannter sein mit Zen6 in 3nm als Konter.
Ursprünglich sollten gewisse Modelle mit Intel 20A gefertigt werden was aufgegeben werden musste.

[MiamiNice]

What, Inte nutzt hier TSMc 3nm? Hatte ich total vergessen, da ist es ja nicht gerade prickelnd was die abliefern. Da kann AMD entspannter sein mit Zen6 in 3nm als Konter.

Da braucht es imo keinen Zen6. Schon Zen 5 ohne 3D wird oft schneller sein, mit 3D wahrschienlich um 20 Prozent schneller als jedwede ARL basierter CPU. Selbst ein OC 14900k wird abseits von 4k Gaming, in den meisten Games schneller (AAA) bis deutlich schneller (non AAA) sein.

[maximus_hertus]

Angeblich kostet Intel das Fremdfertigen weniger als in den eignen Fabs. Da gab es wohl mal irgendeinen Post. Habe ich in einem anderen Forum gelesen, leider keine Links.

Ja und nein. Die eigenen Fabs werden sicherlich entsprechend nicht voll ausgelastet und haben trotzdem die gleichen Fixkosten.

Ich habe jedoch keine (genauen) Zahlen und es handelt sich eher um eine Vermutung. Es sieht aber eher nicht so gut für Intel aus. ARL-S scheint wirklich eine Enttäuschung zu werden und man will oder muss damit dann noch 2+ Jahre überbrücken.

Vor allem muss Intel eher früher als später dann auch wieder die Desktop CPUs wieder bei sich fertigen. Oder die Fabs abstossen.

18A ist gefühlt die "All-In" Wette von Intel. Klappt das, dann könnte es wieder prächtig aufwärts gheen. Scheitert man (auch) damit, dann wird es häßlich. Sehr häßlich, falls AMD entsprechend performt bzw. die nächsten Schritte machen kann.

[basix]

Gibt genug Fälle von denen wir wissen dass da softwaretechnisch nichts mehr kommt und wir das nur mit Leistung (nicht Watt) erschlagen können. Gerade im Gaming. Da gibt es eben keine andere Option als auf noch stärkere Hardware zu hoffen.

Bis auf so Sachen wie LinPack oder y-Cruncher fällt mir nicht viel dazu ein. Und diese hängen ziemlich schnell an der Bandbreite, was sich mit DDR6 einfach mal um 2x nach oben verschieben sollte. Welche SW hast du den im Sinn?

Viele SW hat zu viele Zwischenlayer oder ein paar wenige unoptimierte Stellen machen 80% der Performance / Schwuppdizität aus. Und in den meisten Fällen lässt sich dort noch viel rausholen. Alles was x-Mal übers Netzwerk telefoniert (MS Office lässt grüssen) läuft generell viel schlechter als es tun könnte. Was ich da so im professionellen Umfeld so sehe ist zum Teil wahnsinn. Wegen irgendwelchen Security / Malware / Licensing usw. Diensten im Hintergrund sowie generell schlechtem SW/UI-Design geht so viel Produktivität verloren. Eine DB-Abfrage um sich ein paar Details anzuzeigen? 5sec warten. Da darf man sich gar nicht ausrechnen, was das eigentlich kostet, sonst würde da schon lange was passieren (passiert aber nicht auch wenn eigentlich alle die es nutzen jeweils das Feedback geben, dass es in einem schlechten Zustand ist).

"Ordentlich programmieren" stößt auch schön langsam an unsere Grenzen als Sapiens.
Wir brauchen was besseres und da..
Das Problem ist vor allem Zeit. Niemand kann oder will es sich mehr leisten, die SW gut zu optimieren. "Ist ja schnell genug". Das gilt eigentlich für alle Consumer-SW. Sobald es in Richtung Professional SW geht (CAD, DB, Server) ist es oftmals besser optimiert, da Server-Zeit Geld kostet. Aber auch da limitiert die "Homo Sapiens" Zeit den Optimierungsgrad.
Viele Software ist ausserdem aus vielen Submodulen zusammengesetzt, wo keiner mehr den Überblick hat und sich vermutlich gegenseitig negativ beeinflusst. Macht es auch nicht besser.


ok.. ich hab in letzter Zeit wirklich zu viel über maschinelles Lernen und A(G)I gelesen..
...und genau hier könnte AI die zu geringe "Homo Sapiens" Zeit kompensieren. CoPilot / Pair-Programming ist hier ein guter Ansatz und AI sollte auch gutes Performance-Profiling hinbekommen (oder zumindest unterstützen können). Ich glaube nicht, das AI die SW selbst schreibt aber die Zeit der Programmierer schont und das wiederum im Schnitt in (hoffentlich) besserer Qualität und Performance münden sollte. User Experience ist hier das grosse Sprichwort und gerade Apple-Geräte werden ja gelobt, dass sie so flott zu bedienen sind. Das ist also schon was Wert, auch im Consumer Bereich. Ich nehme aber an, dass zuerst professionelle Tools "AI-enhanced" werden, weil dort der relative monetäre Gewinn deutlich höher ist und auch besser messbar ist. Consumer wird dann durch Trickle Down bedient (bessere Entwickler-Effizienz = Geringere Entwicklungskosten).

[ChaosTM]

Ich hoffe du hast recht, sonst sehen wir uns das nächster mal am Arbeitsamt

TBH.: früher (2030) oder später (2031) sind wir alle ohne Job.

[dildo4u]

Gameing Tests waren mit DDR5 6400 für Arrow Lake und 5600 für 14900k.


1X99I_dCBwA

[MiamiNice]

Gameing Tests waren mit DDR5 6400 für Arrow Lake und 5600 für 14900k.


https://youtu.be/1X99I_dCBwA

;D
Der 14900k wird mit dem ARL Lineup den Boden wischen.

PS: Ich frage mich gerade ob es nicht besser ist einen 14900k zu kaufen und den mit CUDIMMS zu fahren. Die Kombi dürfte schneller sein, als alles was man von ARL sehen wird.

[arcanum]

Interessant wenn man sich z.B. die Warhammer-Zahlen anschaut. Im PCGH-Benchmark ist die CPU Package Power mit Raptor Lake 8+16 bei 190-210W auf den Screenshots im CPU-Benchmark. ARL müsste dann mit dem 285k mit minimal mehr Performance bei <=50W Package Power landen.

[basix]

TBH.: früher (2030) oder später (2031) sind wir alle ohne Job.

Wird nicht passieren. Es wird nur so sein, dass sich dein Arbeitsinhalt ändern könnte ;)

[ChaosTM]

Mein "Arbeitsinhalt" ist jetzt schon so gut wie weg.
Man lässt sich nur Zeit um nicht zu gierig auszuschauen..

@ Basix - in welchem Bereich arbeitest du ?

[Gipsel]

Interessant wenn man sich z.B. die Warhammer-Zahlen anschaut. Im PCGH-Benchmark ist die CPU Package Power mit Raptor Lake 8+16 bei 190-210W auf den Screenshots im CPU-Benchmark. ADL müsste dann mit dem 285k mit minimal mehr Performance bei <=50W Package Power landen.Space Marine 2 scheint ein Outlier zu sein, da das auf Raptor Lake in einigen Situationen quasi an den 253W klebte. Irgendwas scheint da bei RPL diesen hohen Verbrauch zu triggern. Das Spiel ist zwar recht CPU-lastig, aber wenn dieses Raptorlake-spezifische Problem wegfällt, dann könnte ArrowLake mit seinem besseren teillastverbrauch da z.B. so bei um 100W Package Power oder knapp drunter rauskommen (z.B. -150W zum 14900K), der Rest ist Netzteileffizienz.

[mczak]

Wie kommt der 265K eigentlich (laut der offiziellen Präsentation) auf 30M L3? Das geht irgendwie nicht auf für die 8+12 Konfiguration mit 3MB L3 Cache-Slices...

[Undertaker]

;D
Der 14900k wird mit dem ARL Lineup den Boden wischen.

PS: Ich frage mich gerade ob es nicht besser ist einen 14900k zu kaufen und den mit CUDIMMS zu fahren. Die Kombi dürfte schneller sein, als alles was man von ARL sehen wird.

Besseren Default-Speichersupport auch in den Benchmarks zu verwenden, ist ja erst einmal valide. Was das für einen max. OC-Vergleich bedeutet, bleibt noch abzuwarten: Wie hat sich die Taktbarkeit des IMC verändert, wie hat sich die Speicherskalierung verändert? Das müsste man noch genauer herausmessen. Und auch generell die Taktbarkeit der Kerne ist ja aktuell noch nicht wirklich bekannt.

[Zossel]

Ich hoffe du hast recht, sonst sehen wir uns das nächster mal am Arbeitsamt

TBH.: früher (2030) oder später (2031) sind wir alle ohne Job.

Und wer debuggt, supportet und troubleshootet den ganzen Kram?

[arcanum]

Space Marine 2 scheint ein Outlier zu sein, da das auf Raptor Lake in einigen Situationen quasi an den 253W klebte. Irgendwas scheint da bei RPL diesen hohen Verbrauch zu triggern. Das Spiel ist zwar recht CPU-lastig, aber wenn dieses Raptorlake-spezifische Problem wegfällt, dann könnte ArrowLake mit seinem besseren teillastverbrauch da z.B. so bei um 100W Package Power oder knapp drunter rauskommen (z.B. -150W zum 14900K), der Rest ist Netzteileffizienz.

Bei War Hammer kommen aber noch 4% mehr Performance dazu. D.h. dass sich u.A. die Graka schon mal ein paar Watt mehr schnappt. Egal ob Outlier oder nicht, das sind 65% weniger Energieverbrauch bei besserer Performance verglichen zu dem von dir angenommenen Worst Case von ”hängt an 253W". Und Age of Mythology Retold scheint schon der nächste Outlier zu sein mit -136W bei 6% mehr Performance. Bei CB24 verspricht Intel auch 50% weniger Verbrauch bei gleicher Performance ggü. Raptor Lake Refresh und wenn man sich diese Folie anschaut, sieht man min. 25% mehr Verbrauch beim 9950x bei gleicher CB24 Score. Alles in allem scheint ARL ein Effizienzmonster zu werden. Wahrscheinlich mehr in Anwendungen als in Spielen verglichen mit Zen.

[y33H@]

ARL bitte, nicht ADL ^^

[arcanum]

An Alder Lake gedacht. Jetzt korrigiert.

[Zossel]

Was ist den da bei Intel los? Support für ECC?
Und kein Sternchen auf der Folie.

https://pics.computerbase.de/1/1/4/4/5/0-0e461b78be18e58f/41-1080.fa4c427b.png

[dildo4u]

Z890 Maximus Hero

uZIKwx8dJ6U

[][immy]

Oh man. Arrow lake ist echt langweilig. Als hätten sie einfach ein wenig max takt weg genommen und damit die tdp senken können. Dazu noch ein neuer Chipsatz der erforderlich ist und nebenbei beim Speicher tricksen um gegen die eigenen CPUs besser da zu stehen.


Für das Sockelshopping von Intel habe ich absolut kein Verständnis mehr. Die könnten den auch mal länger nutzrn vor allem da ja eh immer mehr in der CPU ist. Würde auch der Umwelt zugute kommen. Die Verbrauchswerte sind nach wie vor lächerlich. Wird Zeit das die bei der Fertigung mal wirklich weiter kommen.

[w0mbat]

Ich finde ARL ist das Gegenteil von Langweilig.

[Badesalz]

Ich finde ARL ist das Gegenteil von Langweilig.Stimme zu. Hab auch schon mitgekriegt, daß es eher aufregend ist. Also, schon zigfach mitgelesen wo ex-Fanboys sich aufregen.

[][immy]

Nun bei den ganzen Komponenten gefertigt von tsmc hätte ich halt schon mehr erwartet.
Und dazu die Speicherkonfigurationen, wo man in der Vergangenheit gerne mal schnellerer Speicher für die eigenen Prozessoren genutzt hat und nun bei dem Vergleich plötzlich auf langsameren Speicher geht.

[ChaosTM]

ok, ich dachte Intel fertigt Arrow noch in House.

dann ist das gar nicht mal so gut, aber zumindest bezüglich Effizienz halbwegs aufzuschließen ist ein Schritt vorwärts

[Denniss]

Nur Design, Interposer und Assembly ist bei/von Intel, der ganze Rest kommt von TSMC

[iamthebear]

Technologisch ist Arrow Lake sehr interessant. Aus Gamer Käufersicht jedoch komplett uninteressant.
Zen5 wurde als Fail bezeichnet hat aber mit den neustens Updates zumindest 5-10% heraus geholt und angeblich das Taktproblem bei X3D gelöst. Alles auf fast demselben Node ohne die Die size zu erhöhen.

Intel macht 2 Node Jumps und schafft lediglich etwas mehr Effizienz von der aber ein Teil gar nicht von der CPU (Package Power) zu kommen scheint.

[ChaosTM]

Die CPUs scheinen bezüglich IPC ziemlich ausgereizt zu sein.
Dank der Konkurrenz.

Man wird sich hier was neues einfallen lassen müssen, eventuell wäre jetzt der Moment gekommen, um endlich all die Altlasten ein für alle mal los zu werden -> A** ?

[Zossel]

Man wird sich hier was neues einfallen lassen müssen, eventuell wäre jetzt der Moment gekommen, um endlich all die Altlasten ein für alle mal los zu werden -> A** ?

Dann auch gleich Carry & Co entsorgen, so wie risc-v.

[Badesalz]

Man wird sich hier was neues einfallen lassen müssen, eventuell wäre jetzt der Moment gekommen, um endlich all die Altlasten ein für alle mal los zu werden -> A** ?Welche Altlasten? Hat man da mehr von als AMD?

[Ben Carter]

Aus meiner Sicht sind sowohl ARL als auch Zen5 recht große Umstellungen, die in der ersten Version noch nicht so viel mehr Performance liefern. Wobei das auch relativ ist, abseits von Gaming ist Zen5 ja durchaus in Ordnung und mal sehen, was mit X3D kommt und rein von dem IPC Sprung her, sehe ich auch ARL als in Ordnung, wobei es hier zugegebenermaßen mehr die E-Cores sind. ARL hat halt einfach das "Problem", dass RPL sehr hoch taktet und ARL da nicht mehr rankommt.

Jedenfalls habe ich das Gefühl, dass die beiden Generationen die Grundlage sind und die darauf aufbauenden Generationen davon profitieren werden. Auch Software, Compiler, etc. müssen und werden sich anpassen und irgendwo noch das eine oder andere Prozent an Leistung finden.

Wie gut/schlecht ARL im Vergleich zu Zen5 bzw. dann Zen5 X3D und RPL ist, beurteile ich erst, wenn ich die Benchmarks im Verhältnis zum Verbrauch sehe. Wenn die Effizienz wirklich deutlich besser ist und in Richtung von Zen5 geht (da bin ich mir noch nicht so sicher), dann war es ein massiver Schritt. Wenn es nur 10-25% besser als RPL ist, dann... naja.. nicht so.

[fondness]

Zusammenfassung von CB:
https://www.computerbase.de/artikel/prozessoren/intel-arrow-lake-s-core-ultra-200s-details.89465/

Das könnte ganz ungut werden mit der Gaming-Leistung:

Gaming-Leistung: Intel sagt zwar, dass man das Niveau des Core i9-14900K halten wird (und damit Ryzen 7000X3D knapp verfehlt), die präsentierten Daten geben das auch im Vergleich mit dem, was Intel im Vergleich zu 9950X und 7950X3D zeigt, aber nicht her. Außerdem kamen viele Titel mit Intels APO-Toolkit zum Einsatz, auf das nur Intels CPUs reagieren. In unabhängigen Test könnte am 24. Oktober deshalb schnell zu Tage kommen, dass Arrow Lake in Spielen doch noch langsamer ist, vor allem eben, wenn APO-Titel nicht dabei sind, die das Bild in Intels Benchmarks nach oben ziehen.

[Gipsel]

Hat eigentlich schon mal irgendwer anhand eines Fotos (oder Samples) die genauen Größen der einzelnen Tiles vermessen?
Ein gut aufgelöster Dieshot des Compute-Tiles wäre auch nett.
Ich meine, die E-Cores sehen ja ganz gut aus und erreichen auch in fast allen Modellen gleichen Takt. Und in den SKUs mit niedriger TDP (z.B. 35W T-Modelle) laufen P- und E-Cores ja quasi schon mit fast dem gleichen Takt. Das heißt im Prinzip, daß die E-Cores auch auf 5GHz oder gehen könnten, wenn intel da für Last auf wenigen Threads wie beim Boost der P-Cores die Effizienz vernachlässigt). Wenn die E-Cores also weiterhin nur 1/3 der Größe der P-Cores wären, sollte intel die Architektur der P-Cores mal wirklich gut überdenken.

[Badesalz]

Mal das Video von Canucks (YT) anschauen bezüglich 200er und Effizienz...

"Halbwegs aufschliessen" ist... also wie schlecht ist der 9700X einfach so für sich selbst, auf 65W? Ob Intel da so "halbwegs" rankommen kann?

@Gipsel
Sehe ich auch so. Wieviel Royal-Core steckt eigentlich schon in den E-Cores? :wink:
Zweitens aber auch, wieviel der unzähligen ISA-Erweiterungen können die E-Cores eigentlich? Oder sind die diesbezüglich 1:1 zu den P-Cores?

[basix]

Hat eigentlich schon mal irgendwer anhand eines Fotos (oder Samples) die genauen Größen der einzelnen Tiles vermessen?
Ein gut aufgelöster Dieshot des Compute-Tiles wäre auch nett.
Ich meine, die E-Cores sehen ja ganz gut aus und erreichen auch in fast allen Modellen gleichen Takt. Und in den SKUs mit niedriger TDP (z.B. 35W T-Modelle) laufen P- und E-Cores ja quasi schon mit fast dem gleichen Takt. Das heißt im Prinzip, daß die E-Cores auch auf 5GHz oder gehen könnten, wenn intel da für Last auf wenigen Threads wie beim Boost der P-Cores die Effizienz vernachlässigt). Wenn die E-Cores also weiterhin nur 1/3 der Größe der P-Cores wären, sollte intel die Architektur der P-Cores mal wirklich gut überdenken.

Gibt das von Lunar Lake. Sollte ja auch bei ARL N3B sein. Das Lunar Lake Compute Tile soll 140mm2 gross sein.

Bei den Server Benchmarks zu GNR sieht man schon, dass die P-Cores je nach Workload deutlich mehr Bumms haben. Wie viel davon AVX512 & AMX ist: Keine Ahnung.

[Gipsel]

Gibt das von Lunar Lake. Sollte ja auch bei ARL N3B sein. Das Lunar Lake Compute Tile soll 140mm2 gross sein.Das könnten aber leicht andere Kerne sein (E-Cores dort sind ja die LPE-Variante), die auch weniger hoch boosten (3,7GHz in Lunar vs. 4,6GHz in Arrow Lake). AMD verbaut in StrixPoint ja auch etwas andere (kleiner, etwas niedrigerer Maximaltakt, physisch entfernte 512bit Vektoreinheiten) Kerne als auf dem Desktop, trotz gleichem Prozeß (zumindest für die Zen5-Kerne [gleicher Prozeß, anderer Zen5-Kern], die Zen5c von Turin dense sind sowohl anders [AVX512] also auch anderer Prozeß).
Aber in Lunar Lake sehen wir einen Faktor von ~2,6 für die P-Kerne (oder E-Kerne haben ~38% der Größe der P-Kerne), jeweils inklusive L2 und ohne L3.
Interessanterweise takten die LunarLake E-Cores genau so wie die Zen5c in Turin dense. Und beide werden in einem N3-Prozeß bei TSMC gefertigt (N3B vs. N3E, wobei N3B minimal dichter sein soll, N3E dafür etwas besser in Sachen Performance). Da wäre ein Vergleich mal interessant.

[mocad_tom]

Hier mal Material um die Diskussion anzufetten:

https://x.com/p1cturedump/status/1844741988194664947

Auf dem ARL-SoC-Die sitzen zwei Crestmont

Der Unterschied zwischen dem Meteor Lake SoC-Die und dem Arrow Lake SoC-Die wird minimal sein.

Deshalb könne wir uns jetzt auch mal über das im roten Kasten unterhalten.
Der Ring.
Der läuft durch den Soc-Die durch, hat dort als Ringbus-Teilnehmer den IMC.
Am oberen Ende ist der Ringbus-Teilnehmer igpu rangehängt.

Es hat bei der Meteor Lake-Vorstellung keinen interessiert - ich frage es jetzt mal, weil eigentlich müsste das mit der Meteor Lake Vorstellung alles gesagt worden sein:

-"sind das zwei Ringbus und sie "küssen" sich in der Mitte vergleichbar mit einer 8"
oder
-"ist das wirklich ein Ringbus also ein ganz schmales hohes O"

Es wird dann wohl darauf hinauslaufen, dass man austestet, wie hoch man den Ringbus jagen kann (der ist ja dann der Flaschenhals).
Ich denke das wird finetuning beim BIOS brauchen.

Dann noch die 265KF -Frage:
Warum gibt es 265KF, aber keinen 285KF?
Könnte es sein, dass man den Ringbus höher jagen kann, wenn die igpu gar nicht als Chiplet mit drin sitzt? Und könnte es nachträglich noch einen 285KF mit werksseitig OC am Ring geben?

[w0mbat]

Ich würde auf die Renderbilder nichts geben.

[mocad_tom]

https://hc34.hotchips.org/assets/program/conference/day2/Mobile%20and%20Edge/Meteor_Lake_Hotchips%20_%20Wilfred%20_%20final_submit%20(1).pdf

In dem Hotchips paper sah das aber auch schon so aus.
Im Rahmen von wissenschaftlichen Vorträgen darf man nicht so schludern.

[bbott]

Was ist den da bei Intel los? Support für ECC?
Und kein Sternchen auf der Folie.

https://pics.computerbase.de/1/1/4/4/5/0-0e461b78be18e58f/41-1080.fa4c427b.png
Ist bestimmt das interne ecc des DDR 5 gemeint. (Hoffentlich nicht ;) )

[bbott]

Technologisch ist Arrow Lake sehr interessant. Aus Gamer Käufersicht jedoch komplett uninteressant.
Zen5 wurde als Fail bezeichnet hat aber mit den neustens Updates zumindest 5-10% heraus geholt und angeblich das Taktproblem bei X3D gelöst. Alles auf fast demselben Node ohne die Die size zu erhöhen.

Intel macht 2 Node Jumps und schafft lediglich etwas mehr Effizienz von der aber ein Teil gar nicht von der CPU (Package Power) zu kommen scheint.
Bingo! AL 3nm vs. Zen 4nm

Gleicher node: 5-10% mehr Games Performance und 15+% mehr bei Apps, eine Enttäuschung
Zwei Nodesprünge: Quasi identische Performance bei Stromverbrauch ähnlich zu Konkurrenz, und einige schreien Wow....

Intel hat mit 3nm, durch die Rosa Brille im Best Case ein Patt zu alten Gen und Konkurrenz geschaffen ... :freak:

Games (voraussichtlich) AL - 20% vs Zen 5 3D sind auf einmal egal, bei Zen 5 waren 5% bei vielen relevant und ein MEGA Fail :freak:

Man müsste jetztmal die Posts vergleichen :D

[robbitop]

Wobei man sagen muss dass Intel mit ARL und LNL nur die Assi Version (kleiner Spaß falls sich jmd getriggert fühlt) von N3 hat. N3B. Die ist kaum besser als N4 seitens Performance und Power. Erst N3E bringt einen ordentlichen Sprung wie man an M4 (N3E) vs M3 (N3B) vs M2 (N4/N4P?) sehen kann.

[fondness]

Wobei man sagen muss dass Intel mit ARL und LNL nur die Assi Version (kleiner Spaß falls sich jmd getriggert fühlt) von N3 hat. N3B. Die ist kaum besser als N4 seitens Performance und Power. Erst N3E bringt einen ordentlichen Sprung wie man an M4 (N3E) vs M3 (N3B) vs M2 (N4/N4P?) sehen kann.

Bestenfalls ein Indiz, mehr nicht. Könnte auch schlicht am M3 liegen, dass es nicht soviel mehr perf/Watt vs. M2 gibt. Apple hat ja auch die Taktraten erhöht.

Würde es nichts bringen, hätte Intel oder Apple auch N4 nehmen können. Wäre erheblich billiger gewesen.

Noch dazu wenn man berücksichtigt woher Intel kommt, das sind ja quasi 2 full node shrinks vs dem Vorgänger kann man da schon etwas mehr erwarten.

[Zossel]

Wobei man sagen muss dass Intel mit ARL und LNL nur die Assi Version von N3 hat. N3B. Die ist kaum besser als N4 seitens Performance und Power. Erst N3E bringt einen ordentlichen Sprung wie man an M4 (N3E) vs M3 (N3B) vs M2 (N4/N4P?) sehen kann.

Die Zielgruppe von Intel sind eben keine Versuchstauben die jede neue Skinnerbox für beliebige Preise kaufen und für jede Software freudig strahlend die 1/3 Applesteuer ablatzen.
Und obendrein bekommst du noch wie geil es doch ist das ihr Geld jetzt jemand anders hat (Marktkapitalisierung von Apple).

[mocad_tom]

@Zossel ECC

Mein 13700K Arbeitsrechner mit W680 Chipset arbeitet auch mit ECC-Speicher.
Richtigem ECC.

[robbitop]

Bestenfalls ein Indiz, mehr nicht. Könnte auch schlicht am M3 liegen, dass es nicht soviel mehr perf/Watt vs. M2 gibt. Apple hat ja auch die Taktraten erhöht.

Würde es nichts bringen, hätte Intel oder Apple auch N4 nehmen können. Wäre erheblich billiger gewesen.

Noch dazu wenn man berücksichtigt woher Intel kommt, das sind ja quasi 2 full node shrinks vs dem Vorgänger kann man da schon etwas mehr erwarten.

Ich will hauptsächlich sagen dass N3B auf keinen Fall mit N3E gleichzusetzen ist weil ein gutes Stück besser. Top Notch ist N3E.

[basix]

Der M4 ist nicht gross effizienter als M3. Der ist zwar einiges schneller, schluckt aber auch einiges mehr.

[robbitop]

Sicher? Das iPad Pro ist ein gutes Stück dünner und leichter geworden und schneller ohne an Akkulaufzeit zu verlieren. Wie soll das ohne Effizienzsteigerung gehen?
Und das M4 Macbook ist doch laut den leaks auch um einiges schneller als das M3 und das wahrscheinlich auch ohne Akkulaufzeit zu verlieren.

[Undertaker]

Ich meine, die E-Cores sehen ja ganz gut aus und erreichen auch in fast allen Modellen gleichen Takt. Und in den SKUs mit niedriger TDP (z.B. 35W T-Modelle) laufen P- und E-Cores ja quasi schon mit fast dem gleichen Takt. Das heißt im Prinzip, daß die E-Cores auch auf 5GHz oder gehen könnten, wenn intel da für Last auf wenigen Threads wie beim Boost der P-Cores die Effizienz vernachlässigt). Wenn die E-Cores also weiterhin nur 1/3 der Größe der P-Cores wären, sollte intel die Architektur der P-Cores mal wirklich gut überdenken.

So einfach ist die Rechnung wohl eher nicht. Zunächst einmal reden wir über aktuell 24% Taktdifferenz zwischen E- und P-Cores im jeweiligen Maximalausbau. Zusammen mit der IPC-Differenz ergibt das über 35% (!) Unterschied in der Pro-Thread-Leistung, das ist mehr als signifikant und schlicht unverzichtbar für Desktop- und Mobile.

Jetzt nimmst du an, dass die P-Cores bei den vorliegenden Maximaltaktraten mehr "ausgequetscht" sind als die E-Cores. Kann man spekulieren, auch wenn es dafür zunächst einmal keinen Beleg gibt. Das ein gewisser Effizienzverzicht in Form höher getakteter E-Cores diese 35% Performanceabstand jedoch signifikant reduzieren könnte, ist schon arg weit hergeholt. In der Vergangenheit war es so, dass die P-Cores am unteren Rand ihres Betriebsbereiches effizienter als die E-Cores am oberen Rand ihres Taktfensters agierten – schlechte Voraussetzungen, um hier selbst bei noch stärkerer Vernachlässigung der Effizienz einem P-Core Konkurrenz zu machen. Vor allem aber werden die dicht gepackten E-Cores nicht annähernd in der Lage sein, überhaupt wirklich hohe Taktraten zu erreichen. Selbst bei 5 GHz blieben 25% Leistungsdifferenz zur aktuell maximalen P-Core Ausbaustufe und es ist zweifelhaft, ob dieser Mehrtakt (auch wenn man mit Mehrspannung um sich wirft) vom Design überhaupt erreichbar wäre. Bei Zen 4 vs 4C meine ich, dass AMD allein 50% Fläche nur für die bessere Taktbarkeit von Zen 4 investiert hatte.

Bei den P- vs. E-Cores kommen nun noch Differenzen wie ein 3x so großer L2-Cache der P-Cores ins Spiel. Allein das kostet sicher massiv viel Fläche bei in vielen Fällen marginalem Leistungsgewinn, in Cache-lastigen Szenarien (-> Spiele) dürfte das aber wohl noch deutlich mehr als die gemittelten ~10% zwischen P- und E-Cores bringen.

Summa summarum: Ob ein um 35% Pro-Thread-Leistung aufgebohrter E-Core letztendlich tatsächlich kleiner und/oder effizienter als der aktuelle P-Core wäre, kann hier keiner valide abschätzen. Dass jedes Prozent IPC und Taktbarkeit überproportional teuer erkauft werden muss, ist jedenfalls weder neu noch überraschend. ;)

[Zossel]

In der Vergangenheit war es so, dass die P-Cores am unteren Rand ihres Betriebsbereiches effizienter als die E-Cores am oberen Rand ihres Taktfensters agierten – schlechte Voraussetzungen, um hier selbst bei noch stärkerer Vernachlässigung der Effizienz einem P-Core Konkurrenz zu machen.

IMHO lohnt es sich nicht sich sich mit dem alten Zeug zu beschäftigen.
Das was Intel da abgezogen hat wird wahrscheinlich als Pentium4 2.0, Titanium 2.0 oder als Bulldozer 2.0 in die CPU-Geschichte eingehen. (Shit, wir brauchen unbedingt mehr Kerne, was haben wir den in der Kiste liegen um möglichst schnell viel Kerne auf den Markt zu bringen)

Intel wird ein paar Jahre (einstellig - mittel bis hoch) brauchen um wieder sauber an einem Masterplan lang aufeinander aufbauend seine neuen Produkte entwickeln zu können.
Für non-x86 Produkte wird es eher länger dauern, Intel braucht allerdings dringend brauchbare Marktanteile in non-x86 Märkten.
Fabs sind ein anderes Thema, wahrscheinlich wäre ein eigener CEO für die Fabs besser um das bewältigen zu können, 2 so unterschiedliche und komplexe Themen im selben Kopf klingt nach einem Plan zum scheitern.

Die Grundlagen das z.b. AMD jetzt in recht kurzer Zeit (wenige Monate) die verschiedenen Zen5 Varianten (Mobil, Desktop, Server, Zenxc@!3!nm, X3D) auf den Markt bringen kann wurden vor 5-10 Jahren gelegt.
Im Mobilbereich ist AMD (noch) nicht soweit um sich Millionen Teile auf Halde legen zu können um kurzfristig Stückzahlen liefern zu können, aber bevor man sowas machen kann steht ganz klar eine gute Execution, wie man so schön auf neudeutsch sagt.

Vielleicht schreibt F. Su noch mal ihre Memoiren und verrät uns den Trick wie man die ganzen BWL-Heißluftgebläse in einem US-Konzern dieser Größenordnung unter Kontrolle behält :-)

[basix]

Sicher? Das iPad Pro ist ein gutes Stück dünner und leichter geworden und schneller ohne an Akkulaufzeit zu verlieren. Wie soll das ohne Effizienzsteigerung gehen?
Und das M4 Macbook ist doch laut den leaks auch um einiges schneller als das M3 und das wahrscheinlich auch ohne Akkulaufzeit zu verlieren.

Tests wie diese sprechen eine eindeutige Sprache, Apple kocht auch nur mit Wasser ;) 7-9W Single Core sind mal eine Ansage, der M3 lag eher bei ~5W
https://youtu.be/EbDPvcbilCs?t=506
https://youtu.be/EbDPvcbilCs?t=643

Peak Verbrauch ist deutlich höher. Bei gleicher Frequenz faktisch gleicher Verbrauch. Bei Spec hat der da 3-5% höhere Effizienz gemessen (bei gleichen Taktraten). Bei anderen Applikationen kann es etwas besser aussehen (wenn die IPC besser durchschlägt), aber bei max. Taktraten ist man sicher nicht effizienter als M3.
Apple hat beim M4 vermutlich die Hot Spots besser optimiert und bei den Geräten generell die thermische Ableitung verbessert. Das bringt enorm was, wenn man mehr verbraucht.

Akkulaufzeit-Tests sind Teillastbetrieb. Das hat noch nicht viel zum Peak-Verbrauch zu sagen. Und evtl. ist einfach das Display des iPad effizienter geworden, das macht bei einem Tablet sehr viel aus.

[Gipsel]

So einfach ist die Rechnung wohl eher nicht. Zunächst einmal reden wir über aktuell 24% Taktdifferenz zwischen E- und P-Cores im jeweiligen Maximalausbau.Das Argument ist, daß die 4,6GHz für die E-Cores nicht wirklich das Maximum sind (wie die 5,7 GHz der P-Cores, die nur mit allen möglichen Boosttechniken erreicht werden). Geht man im Produktstack nur ein wenig runter und schaut sich die Frequenzen ohne die Extra-Boosttechniken für die P-Cores an, schrumpft der Abstand doch beträchtlich. Im Topmodell mit den 5,7GHz P-Cores stecken die besten Bins und intel limitiert offenbar die E-Cores bei 4,6GHz (die auch keinen eTVB und solche Spielereien spendiert bekommen, die die P-Cores überhaupt erst auf ihren Maximaltakt kommen lassen). Bei den niedrigeren Bins sieht intel offenbar keine Veranlassung, den E-Core-Takt irgendwie merklich zu reduzieren. Dies sagt mir, daß die 4,6GHz der E-Cores quasi sicher von fast jedem Die erreicht werden können. Das impliziert natürlich, daß bessere Bins höher gehen würden, wenn intel das wollte. Hier spielt für das Argument Effizienz auch keine Rolle, denn die wirft intel für den Boost der P-Cores ja auch aus dem Fenster (das könnte man für einen der E-Core-Cluster also vielleicht auch tun und den auf 5+GHz quetschen).
Wenn der Größenunterschied der Cores wirklich immer noch >Faktor 2,5 ist, fragt man sich schon, ob man nicht zukünftig lieber ein wenig mehr Aufwand in eine moderate Erweiterung der E-Cores steckt und die taktmäßig ein wenig höher treibt, als Unmengen an Diefläche in P-Cores zu investieren.
Der Takt-und Leistungsunterschied ist in der Spitze ja kleiner als zwischen Zen5 und Zen5c (oder Zen4 und Zen4c) bei größerem relativem Flächenunterschied (was wohl hauptächlich an den eher mittelprächtigen P-Cores liegt, die Skymonts sind ja wie gesagt ganz gut und takten auch ansprechend).

[Der_Korken]

Als ST-Booster kann man die P-Kerne sicher noch eine Generation mitschleppen, wobei vier von denen locker reichen sollten. Alles schlecht skalierende und viel L2 benötigende wäre versorgt und die Breite stemmen die dann nochmals verbesserten E-Kerne. Rechnerisch würden dadurch 10 weitere E-Kerne auf den Die passen, also 4+26 (was man dann zu 4+24 abrunden würde). Da braucht Intel auch kein SMT mehr in die P-Kerne reinfriemeln, denn das spielt für die MT-Leistung des Gesamtchips keine Rolle mehr. Dann lieber noch +200Mhz rausholen für mehr ST. SMT auf den E-Kernen dagegen wäre ein krasser MT-Boost.

[Zossel]

Der Takt-und Leistungsunterschied ist in der Spitze ja kleiner als zwischen Zen5 und Zen5c (oder Zen4 und Zen4c) bei größerem relativem Flächenunterschied

Wo finden sich die Vergleichsdaten zwischen den Chiplet Ausführungen von Zen5 und Zen5c, am besten auch mit einer Gegenüberstellung Zen4(c)? (Ich hatte bisher keine Muße gehabt danach zu suchen)

[HOT]

Als ST-Booster kann man die P-Kerne sicher noch eine Generation mitschleppen, wobei vier von denen locker reichen sollten. Alles schlecht skalierende und viel L2 benötigende wäre versorgt und die Breite stemmen die dann nochmals verbesserten E-Kerne. Rechnerisch würden dadurch 10 weitere E-Kerne auf den Die passen, also 4+26 (was man dann zu 4+24 abrunden würde). Da braucht Intel auch kein SMT mehr in die P-Kerne reinfriemeln, denn das spielt für die MT-Leistung des Gesamtchips keine Rolle mehr. Dann lieber noch +200Mhz rausholen für mehr ST. SMT auf den E-Kernen dagegen wäre ein krasser MT-Boost.


Sieht jetzt doch so aus, als käme ein Panther Lake S mit 8+16, danach Nova Lake S mit 8+16, mit durch schleppen trifft wohl nicht so ganz zu.

[Undertaker]

Das Argument ist, daß die 4,6GHz für die E-Cores nicht wirklich das Maximum sind (wie die 5,7 GHz der P-Cores, die nur mit allen möglichen Boosttechniken erreicht werden).

Wie gesagt, ob und in welchem Ausmaß die E-Cores mehr relativen Taktspielraum als die P-Cores haben, bleibt Spekulation. Ich meine in einem der Reviews (ggf. auch auf Youtube) gehört zu haben, dass Intel von 5 GHz OC-Potential bei den E-Cores sprach (vielleicht findet das noch jemand); falls das so war, wären für einen serientauglichen Betrieb wohl kaum mehr als ~200 MHz mehr realistisch. Die gleiche Frage nach dem Taktspielraum müsste man nun ebenso bei den P-Cores stellen, Abstufungen in der Modellpalette zur Produktdifferenzierung (die bei ST nun einmal nur über den P-Core Maximaltakt geht, MT wird bereits über P-Core-Takt/P-Core-Anzahl/E-Core-Anzahl differenziert) sind hier kein sinnvoller Indikator. Zumal die P-Cores taktseitig auch eher durch Temperaturen und Maximalströme limitiert werden, bei den E-Cores auf geringerem Verbrauchsniveau dagegen eher designbedingte Faktoren den Takt begrenzen dürften. Ein solches Limit dürfte eine viel schmälere Gauß-Verteilung bzgl. erreichbarer Maximaltaktraten als bei einem P-Core ergeben. Und: eTVB ist bei einem E-Core bei weniger kritischen Verbrauchs- und Temperaturlimits ebenfalls tendenziell weniger wirkungsvoll.

So oder so: An den aktuellen ~35% ST-Differenz zwischen P- und E-Cores lässt sich so allenfalls Kosmetik betreiben. IPC-Steigerungen kosten immer überproportional Fläche, mehr Taktpotential verlangt geringere Packdichten und schadet idR sogar der IPC, wenn dafür relative Cache-Latenzen steigen oder Pipelines verlängert werden müssen. Was du implizierst ist, dass sich das aktuelle E-Core-Design bei weniger Verbrauch oder Fläche auf die ST-Performance der aktuellen P-Cores bringen ließe. Ich sage, dass die dafür erforderlichen Umbauten in Anbetracht der vorliegenden Differenz immens wären und die Abschätzung, um welchen Faktor der Flächenbedarf dabei steigt, für uns als Außenstehende kaum zu treffen ist.

Wenn der Größenunterschied der Cores wirklich immer noch >Faktor 2,5 ist

Noch kenne ich keine Zahlen, allerdings lassen ~10 vs. 32% IPC-Wachstum sowie die Annäherung der Maximaltaktraten eine tendenzielle Annäherung in Fläche und Transistorzahl vermuten. Und ich würde hier insbesondere auch die Cachegrößen nicht vernachlässigen (3-fache L2-Menge der P-Cores), die gerade im Anwendungsmittel oft eher wenig Performanceeinfluss haben, jedoch einen durchaus großen Flächenanteil einnehmen.

[Undertaker]

Als ST-Booster kann man die P-Kerne sicher noch eine Generation mitschleppen, wobei vier von denen locker reichen sollten. Alles schlecht skalierende und viel L2 benötigende wäre versorgt und die Breite stemmen die dann nochmals verbesserten E-Kerne. Rechnerisch würden dadurch 10 weitere E-Kerne auf den Die passen, also 4+26 (was man dann zu 4+24 abrunden würde).

Für Anwendungen sicher eine valide Strategie, allerdings könnte ich mir hierdurch Einbußen insbesondere bei Spielen vorstellen. Bei nur noch 4 P-Cores würden mehr Threads auf den E-Cores liegen, die durch erheblich kleinere Caches bei speicherlastigen Aufgaben mutmaßlich überproportional zurückliegen. Auch die Kern-zu-Kern-Kommunikation zwischen P- und E-Cores wäre bei einem solchen Design in Spielen wohl deutlich performancekritischer und gegenüber einer vorrangig P-Core-internen Auslastung unterlegen.

[Der_Korken]

Für Anwendungen sicher eine valide Strategie, allerdings könnte ich mir hierdurch Einbußen insbesondere bei Spielen vorstellen. Bei nur noch 4 P-Cores würden mehr Threads auf den E-Cores liegen, die durch erheblich kleinere Caches bei speicherlastigen Aufgaben mutmaßlich überproportional zurückliegen. Auch die Kern-zu-Kern-Kommunikation zwischen P- und E-Cores wäre bei einem solchen Design in Spielen wohl deutlich performancekritischer und gegenüber einer vorrangig P-Core-internen Auslastung unterlegen.

Die Frage ist, ob alle Spielethreads überhaupt Zugriff auf viel Cache brauchen oder ob es nur wenige Main-Threads sind, die die ganzen Cache-Misses produzieren und dadurch alle anderen ausbremsen.

[ryan]

Sieht jetzt doch so aus, als käme ein Panther Lake S mit 8+16, danach Nova Lake S mit 8+16, mit durch schleppen trifft wohl nicht so ganz zu.


Kein PTL-S, sondern ein langweiliger ARL refresh. Nova Lake braucht einen neuen Sockel.



Noch kenne ich keine Zahlen, allerdings lassen ~10 vs. 32% IPC-Wachstum sowie die Annäherung der Maximaltaktraten eine tendenzielle Annäherung in Fläche und Transistorzahl vermuten. Und ich würde hier insbesondere auch die Cachegrößen nicht vernachlässigen (3-fache L2-Menge der P-Cores), die gerade im Anwendungsmittel oft eher wenig Performanceeinfluss haben, jedoch einen durchaus großen Flächenanteil einnehmen.


Warum sollte die Kerngröße von Skymont LPE in LNL abweichen? Denen fehlt doch nur der L3 Zugriff, die Kerne selber sollten komplett identisch sein. 3 Skymont LPE entsprechen etwa 1 Lion Cove.

[HOT]

Kein PTL-S, sondern ein langweiliger ARL refresh. Nova Lake braucht einen neuen Sockel.
[...]

MLID brachte PTL-S in der letzt FAQ-Episode wieder auf. Nicht als Leak, aber als Roumor aus seinen Industriequellen. Irgendwas ist da im Busch.

[ryan]

MLID brachte PTL-S in der letzt FAQ-Episode wieder auf. Nicht als Leak, aber als Roumor aus seinen Industriequellen. Irgendwas ist da im Busch.


Bei seiner schlechten Trefferquote würde ich von ihm nichts glauben. Später nutzt er dann seine Behauptung gegen Intel, das macht er gerne. So hat er gleich zusätzlichen Content.

[HOT]

Bei seiner schlechten Trefferquote würde ich von ihm nichts glauben. Später nutzt er dann seine Behauptung gegen Intel, das macht er gerne. So hat er gleich zusätzlichen Content.
MLID hat bei Leaks ne enorm gute Trefferquote, seine eigenen Interpretationen sind oft nicht gut, das ist was anderes.

[ryan]

MLID hat bei Leaks ne enorm gute Trefferquote, seine eigenen Interpretationen sind oft nicht gut, das ist was anderes.


Nur bei Codenamen und einigen Details wie der Kernanzahl. Bei allen anderen hat er eine unglaublich schlechte Trefferquote. Solange kein seriöser Leaker von PTL-S spricht und es keine anderen Anzeichen gibt, kann man das vergessen.

[arcanum]

Entscheidungen die Intel mindestens 12 Monaten früher getroffen hat, wusste doch auch keiner. Z.B. die Falschannahme, dass 6+8 ARL mit Intel 20A produziert wird, die zudem noch von vielen Ahnungslosen vehement verteidigt wurde. So eine Entscheidungen trifft man nicht kurz vor Release sondern viel früher wegen der Vorlaufzeit.

[ryan]

20A war geplant für ARL, hat doch Intel selber bestätigt gehabt noch Ende 2023. Eine Falschannahme war das nicht. Die Entscheidung 20A auszulassen kam erst viel später, wobei sich das mit der Zeit abgezeichnet hatte. Von 20A war kaum noch die Rede dieses Jahr. PTL-S war auch mal geplant, wurde aber gestrichen.

[arcanum]

Vom 235 gibt es schon ES oder gar QS. D.h. dass die Entscheidung für 6+8 auf TSMC vor mindestens 7, 10 oder mehr Monaten getroffen wurde. Und was ich damit sagen will ist, dass die meisten rein gar nichts wissen und nur rumraten. Damit ist die Wahrscheinlichkeit dass es einen PTL-S geben wird genauso hoch wie ein ARL-S Refresh. Wissen werden wir es nur wenige Wochen vor der Vorstellung.

[reaperrr]

Vom 235 gibt es schon ES oder gar QS. D.h. dass die Entscheidung für 6+8 auf TSMC vor mindestens 7, 10 oder mehr Monaten getroffen wurde.
Was hat die TSMC-Variante mit der 20A-Variante zu tun?

Es war halt beides geplant, die 20A-Variante sollte für einige Mainstream-Desktop-Modelle verwendet werden.

[arcanum]

Was hat die TSMC-Variante mit der 20A-Variante zu tun?

Es war halt beides geplant, die 20A-Variante sollte für einige Mainstream-Desktop-Modelle verwendet werden.

Wo werden denn die 6+X Varianten jetzt produziert?

[ryan]

Vom 235 gibt es schon ES oder gar QS. D.h. dass die Entscheidung für 6+8 auf TSMC vor mindestens 7, 10 oder mehr Monaten getroffen wurde. Und was ich damit sagen will ist, dass die meisten rein gar nichts wissen und nur rumraten. Damit ist die Wahrscheinlichkeit dass es einen PTL-S geben wird genauso hoch wie ein ARL-S Refresh. Wissen werden wir es nur wenige Wochen vor der Vorstellung.



Die meisten ja. Dennoch gibt es Leute, die was wissen. MLID gehört nicht in diese Kategorie. Intel selber beschreibt PTL als mobile CPU im übrigen. Die Wahrscheinlichkeit auf einen ARL refresh liegt viel viel höher. Schon die letzten Tick Generationen waren immer rein mobile. Und nein das werden wir nicht erst wenige Wochen vor der Vorstellung wissen. Genauso wie wir heute schon die Kerngrößen von PTL-UPH kennen. Alles schon bekannt von Intel selber auf den entsprechenden Plattformen.

[Zossel]

Die Frage ist, ob alle Spielethreads überhaupt Zugriff auf viel Cache brauchen oder ob es nur wenige Main-Threads sind, die die ganzen Cache-Misses produzieren und dadurch alle anderen ausbremsen.

Alles was Zugriff auf die Daten der eigentlichen Spielelogik benötigt profitiert von einem schnellen Zugriffspfad.

[ryan]

Vom 235 gibt es schon ES oder gar QS. D.h. dass die Entscheidung für 6+8 auf TSMC vor mindestens 7, 10 oder mehr Monaten getroffen wurde. Und was ich damit sagen will ist, dass die meisten rein gar nichts wissen und nur rumraten. Damit ist die Wahrscheinlichkeit dass es einen PTL-S geben wird genauso hoch wie ein ARL-S Refresh. Wissen werden wir es nur wenige Wochen vor der Vorstellung.


Nein kann man nicht, weil beides geplant war. Die hätten beides bringen können. Intel müsste nur klar gewesen sein, dass 20A viel später bereit sein würde als N3B. Die letzten Gerüchte vor der offiziellen Streichung sprachen von mitte 2025 für 20A, sofern nicht komplett gestrichen. Intel hat das kommen sehen. Ob 20A oder N3B ist was ganz anderes als bei der Frage PTL-S ja oder nein, der Vergleich hinkt. Eine Streichung von ARL-S stand nie im Raum.

[iamthebear]

Das mit 20A kann mehrere Gründe haben:
a) Zu spät verfügbar

b) Zu schlechte Performance: Wenn 20A schlechter ist als 20A sollte Intel sich hüten beide Nodes mit demselben Design zu launchen wo man wunderbar vergleichen kann. Das würde dem Foundrygeschäft echt nicht gut tun. Nicht wegen den potentiellen Kunden (weil die machen sowieso ihre Tests) sondern weil deren Produkte dann bei den Kunden unten durch sind (so wie keiner die SOCs aus den Samsung Fabs will).

c) Die Yields waren zu schlecht sodass man nur wenige Stück produziert hätte was sich wirtschaftlich nicht lohnt.

[robbitop]

Vom Namen (20 A für Angstrom) impliziert man ja sogar mehr als Parität mit TSMCs N3 sondern eher mit einem 2 nm Prozess der bei TSMC ja noch in der Zukunft liegt.
Ich habe damals schon gesagt als Intel die ganzen selbstbewussten Claims mit 5 Prozessen in 5 Jahren und leadership gebracht haben dass die erstmal abliefern sollen bevor sie den Mund soweit aufreißen (und war sehr sehr skeptisch). Bisher war das Abgelieferte jedenfalls nicht vor TSMC. Nicht einmal annähernd.

[Zossel]

Vom Namen (20 A für Angstrom) impliziert man ja sogar mehr als Parität mit TSMCs N3 sondern eher mit einem 2 nm Prozess der bei TSMC ja noch in der Zukunft liegt.

2000pm@Intel soll ja Strom von unten liefern was IMHO auch für eine spätere Iteration von 0,002µm@TSMC geplant ist.

Aber man sollte aktuell eher misstrauisch sein wenn ein Konkurrent von TSMC mal eben ein paar Entwicklungsiterationen von TSMC überspringen will.

[Lehdro]

Ich habe gerade ein Deja-vú:
https://pbs.twimg.com/media/GZwhqkPaAAEgtH4?format=jpg&name=large

Ein Rückschritt gegenüber RPL-S, denn das Extreme Profile ist raus aus der Gewährleistung. Mal sehen ob diesmal die sich widersprechenden Querverweise wegfallen, oder ob das genau so wisch-waschi wie bei RPL-S ist.

[fondness]

Ich habe gerade ein Deja-vú:
https://pbs.twimg.com/media/GZwhqkPaAAEgtH4?format=jpg&name=large

Ein Rückschritt gegenüber RPL-S, denn das Extreme Profile ist raus aus der Gewährleistung. Mal sehen ob diesmal die sich widersprechenden Querverweise wegfallen, oder ob das genau so wisch-waschi wie bei RPL-S ist.

So kann man die Probleme mit dem kaputten CPUs auch vermeiden. Einfach keine Garantie mehr geben.

[iamthebear]

Solange alle Reviews mit dem Performance Profil gemacht werden und Boardhersteller eine klare Warnung einbauen ist das doch OK.
Ich sehe persönlich auch nicht wirklich eine Notwendigkeit über 250W PL2 zu gehen. Ich würde eher dazu neigen das PL1 im Alltagsbetrieb auf 150-200W herunter zu stellen damit ich bei Volllast nicht immer glaube ein Helikopter landet gerade.

[BavarianRealist]

Was mich etwas verwundert:
Intels Arrow-Lake dürfte extrem teuer in der Herstellung sein: 4 Dice auf einem weiteren Interposer und das Größte davon im teuersten N3B-Prozess, also ungleich teurer als AMDs Zen5-Derivate.

Zudem erscheinen die Leistungsdaten aus meiner Sicht ziemlich enttäuschend: er ist in allen Belangen nur Mittelklasse: keine Chance im Gaming gegen Zen5-X3D, nicht besonders effizient und die integrierte iGPU/NPU an sich umsonst, weil er als APU gegen AMDs Zen5-APUs in allen Belangen verliert, vor allem taugt er ohne dedizierte GPU nicht für KI.

Zuletzt soll die Plattform keinen Nachfolger erhalten. Wer setzt dann überhaupt darauf?

Könnte es sein, dass Intel am Ende von Arrow-Lake kaum was produzieren wird, nachdem zudem zuvor geplant war, die kleineren Varianten des Arrow-Lake-CPU-Tile in Intels 20A zu produzieren, was aber angeblich ja auch nun wegfallen soll; d.h. Intel womöglich gar nicht die nötigen Kapazitäten für N3B reserviert hat? Womöglich kalkuliert man jetzt gezielt damit, eine Knappheit im CPU-Segment entstehen zu lassen, damit man dennoch die verfügbaren Stückzahlen zu guten Preisen los wird, weil AMD nur eine begrenzte Menge des Market-Share übernehmen kann?

[ryan]

Zudem erscheinen die Leistungsdaten aus meiner Sicht ziemlich enttäuschend: er ist in allen Belangen nur Mittelklasse: keine Chance im Gaming gegen Zen5-X3D, nicht besonders effizient und die integrierte iGPU/NPU an sich umsonst, weil er als APU gegen AMDs Zen5-APUs in allen Belangen verliert, vor allem taugt er ohne dedizierte GPU nicht für KI.



AMD verbaut eine wesentlich schwächere iGPU, das als Argument gegen ARL-S hört sich seltsam an. Ein großer Pluspunkt wäre hier die Media Engine, die bei Intel einfach viel besser ist.

[aufkrawall]

Was macht man denn mit seiner Media Engine in einem Mobile-SoC so, dass AMD da in der praktischen Nutzungserfahrung nennenswert abgehängt wäre?
Selbst Phoenix hatte schon einen AV1-Encoder, der recht brauchbar sein dürfte.

[ryan]

Was macht man denn mit seiner Media Engine in einem Mobile-SoC so, dass AMD da in der praktischen Nutzungserfahrung nennenswert abgehängt wäre?
Selbst Phoenix hatte schon einen AV1-Encoder, der recht brauchbar sein dürfte.


Kein AV1 Encoder und schlechtere Qualität und Performance für h264+H265.

[Zossel]

Was mich etwas verwundert:
Intels Arrow-Lake dürfte extrem teuer in der Herstellung sein: 4 Dice auf einem weiteren Interposer und das Größte davon im teuersten N3B-Prozess, also ungleich teurer als AMDs Zen5-Derivate.
Ach:"Inakzeptable Margen"

Gelsinger macht den Investoren derweil Zugeständnisse: "[…] Die Margen sind inakzeptabel. Und intern konzentrieren wir uns sehr darauf, dass wir sehr schnell wieder in die 4er und dann wieder in die 5er kommen müssen. Und natürlich müssen manche unserer Produktlinien in den 6er-Bereich kommen."

Gemeint ist die Bruttomarge, die aktuell bei 35,4 Prozent hängt und langfristig wieder auf mehr als 50 Prozent steigen soll. Die hohe Profitabilität machte Intel einst für Anleger besonders attraktiv.

https://www.heise.de/hintergrund/Intel-Machtspiele-zwischen-Chefs-und-Investoren-9854448.html

Und die neuen fetten Flatschen für die Server dürften auch nicht sonderlich Marge abwerfen.

[aufkrawall]

Kein AV1 Encoder
Nö?

Max Video Encode Bandwidth (SDR)
4320p60 8/10bpc AV1
https://www.amd.com/en/products/processors/laptop/ryzen/300-series/amd-ryzen-ai-9-hx-370.html

[ryan]

Nö?

https://www.amd.com/en/products/processors/laptop/ryzen/300-series/amd-ryzen-ai-9-hx-370.html



Wir reden von Desktop CPUs mit Zen 5. Dort kommt nur die 2CU RDNA2 zum Einsatz. ARL-S bekommt die Media Einheit von Alchemist, die wirklich was kann und die Rechenleistung der iGPU steigt um den Faktor 2,4 zur Raptor Lake-S iGPU.

[BavarianRealist]

AMD verbaut eine wesentlich schwächere iGPU, das als Argument gegen ARL-S hört sich seltsam an. Ein großer Pluspunkt wäre hier die Media Engine, die bei Intel einfach viel besser ist.

Wen interessiert die iGPU in so einer CPU, die im Regelfall ja eh mit einer diskreten Graka verbaut wird, um überhaupt auch die nötige KI-Leistung zu haben. Andernfalls empfiehlt sich viel mehr eine "einfache" APU, z.B. eine Strix oder Krakan, die genügend KI-Performance als auch Grafikleistung hat.

[robbitop]

Wir reden von Desktop CPUs mit Zen 5. Dort kommt nur die 2CU RDNA2 zum Einsatz. ARL-S bekommt die Media Einheit von Alchemist, die wirklich was kann und die Rechenleistung der iGPU steigt um den Faktor 2,4 zur Raptor Lake-S iGPU.

Weil iGPUs im Desktop auch relevant sind für die Leute die vorhaben AV1 zu transcodieren. Im Desktop hat man eine dGPU die das mit abdeckt. ;)

[ryan]

Wen interessiert die iGPU in so einer CPU, die im Regelfall ja eh mit einer diskreten Graka verbaut wird, um überhaupt auch die nötige KI-Leistung zu haben. Andernfalls empfiehlt sich viel mehr eine "einfache" APU, z.B. eine Strix oder Krakan, die genügend KI-Performance als auch Grafikleistung hat.


Dich interessiert es. Du hast doch die iGPU als Nachteil für ARL-S hingestellt, weil diese gegen Zen 5 unterlegen wäre. Zen 5 mit der kleinen 2CU RDNA2 wird nicht so gut aussehen, die ist eher auf Niveau von Raptor Lake-S. Das als Argument gegen ARL-S zu verwenden, ist seltsam.

Weil iGPUs im Desktop auch relevant sind für die Leute die vorhaben AV1 zu transcodieren. Im Desktop hat man eine dGPU die das mit abdeckt. ;)


Auch dann kann es durchaus Sinn machen. Mit einer AMD dGPU, die nicht so gut ist.

[fondness]

Auch dann kann es durchaus Sinn machen. Mit einer AMD dGPU, die nicht so gut ist.

Blödsinn.

[Lehdro]

keine Chance im Gaming gegen Zen5-X3D, nicht besonders effizient und die integrierte iGPU/NPU an sich umsonst, weil er als APU gegen AMDs Zen5-APUs in allen Belangen verliert, vor allem taugt er ohne dedizierte GPU nicht für KI.

AMD verbaut eine wesentlich schwächere iGPU, das als Argument gegen ARL-S hört sich seltsam an. Ein großer Pluspunkt wäre hier die Media Engine, die bei Intel einfach viel besser ist.
Wir reden von Desktop CPUs mit Zen 5. Dort kommt nur die 2CU RDNA2 zum Einsatz. ARL-S bekommt die Media Einheit von Alchemist, die wirklich was kann und die Rechenleistung der iGPU steigt um den Faktor 2,4 zur Raptor Lake-S iGPU.
Bei dem Austausch musste ich schon schmunzeln, richtig lesen hilft.

Und er hat Recht: Intel sitzt mit ARL-S zwischen allen Stühlen:
- in jedem Bereich wird einem mindestens Paroli geboten werden, in den meisten liegt man aber wohl hinten
- die Kostenfaktoren sind jenseits von Gut und Böse vs. AMD
- die Plattform ist im Desktop ein riesiges Fragezeichen
- selbst die Quantität ist fraglich, da man fremdfertigen lässt

=> ARL-S ist als Lernstruktur gedacht und wird wohl kein glorreiches Leben haben. Im Mobile wird er aber eine wichtige Position für Intel einnehmen, da wäre sonst ein schwarzes Loch. AMD will ja anscheinend nicht und Snapdragons können das nicht.

[robbitop]

Auch dann kann es durchaus Sinn machen. Mit einer AMD dGPU, die nicht so gut ist.

Völlig weltfremd. IGPUs werden in Desktops nur genutzt wenn es irgendeine 0815 Büro Möhre ist. Wer AV1 transcodiert gehört zu 99% nicht in die Kategorie und hat eine dGPU. Das ist ein absoluter Strohhalm.

[MiamiNice]

Wen interessiert die iGPU in so einer CPU, die im Regelfall ja eh mit einer diskreten Graka verbaut wird, um überhaupt auch die nötige KI-Leistung zu haben. Andernfalls empfiehlt sich viel mehr eine "einfache" APU, z.B. eine Strix oder Krakan, die genügend KI-Performance als auch Grafikleistung hat.

Das liest sich für mich komisch. Die iGPU interessiert die meisten Kunden einer solchen CPU. Den ca. 90% davon landen, meiner Meinung nach, in Workstations im prof. Umfeld ohne extra iGPU.
Das mit der KI Leistung verstehe ich leider gar nicht. Welche nötige KI Leistung? Für was?

[fondness]

Dich interessiert es. Du hast doch die iGPU als Nachteil für ARL-S hingestellt, weil diese gegen Zen 5 unterlegen wäre. Zen 5 mit der kleinen 2CU RDNA2 wird nicht so gut aussehen, die ist eher auf Niveau von Raptor Lake-S. Das als Argument gegen ARL-S zu verwenden, ist seltsam.


Er meinte vs. Strix und das stimmt auch. Die iGPU von ARL ist für mobile zu schwach und für Desktop unnötig stark. Ein Kompromiss weil man nicht so wie AMD zwischen Desktop und mobile trennt. Das ist natürlich auch einer der Gründe, warum die Marge ein Problem ist. Dasselbe gilt für die NPU. Für Copilot zu schwach und damit weitgehend unnötiger Ballast.

[ryan]

Blödsinn.


Warum? AMDs Media Engine kann nicht mithalten, das weiß doch jeder. Ist schon ewig so.

Völlig weltfremd. IGPUs werden in Desktops nur genutzt wenn es irgendeine 0815 Büro Möhre ist. Wer AV1 transcodiert gehört zu 99% nicht in die Kategorie und hat eine dGPU. Das ist ein absoluter Strohhalm.


Für jeden der mit einer GPU decodiert kann es sinnvoll sein, sofern die dGPU schwächer ist, was bei AMD bekanntlich der Fall ist. Das geht auch mit einer dGPU problemlos, die iGPU zu verwenden dafür.


Er meinte vs. Strix und das stimmt auch. Die iGPU von ARL ist für mobile zu schwach und für Desktop unnötig stark. Ein Kompromiss weil man nicht so wie AMD zwischen Desktop und mobile trennt. Das ist natürlich auch einer der Gründe, warum die Marge ein Problem ist. Dasselbe gilt für die NPU. Für Copilot zu schwach und damit weitgehend unnötiger Ballast.


Warum redet er dann vom Zen5-X3D wenn er Strix Point meint und warum kommt er dann mit einer dGPU? Ich habe noch keine iGPU Benchmarks von ARL-H gesehen, du etwa? So viel stärker ist Strix jetzt auch nicht zu Meteor Lake bei 28+ Watt. ist jetzt nicht so, als wenn Strix Point doppelt so schnell wäre. Wenn jetzt ARL-H zu schwach wäre laut dir, kann Strix Point auch nicht der Hit sein.

[aufkrawall]

Jeder, der etwas ernsthafter mit dGPUs transkodiert, hat schon lange eine GeForce und wird auch immer eine haben.

[ryan]

ARL-S bekommt die Media Einheit von Alchemist, die wirklich was kann...


Korrektur bei der Media Version. Alchemist DG2= 12.5, MTL+ARL-S/H= 13.0, somit neuer als die von Alchemist DG2. Mit BMG G21 werde ich mal schauen, ob sich was bei der Qualität geändert hat. Sollte praktisch gleich sein mit dessen 13.01.

Nur Lunar Lake hat mit 20.0 die neueste Version (inklusive VVC Decoding). Panther Lake Xe3_LPG (https://github.com/ColinIanKing/linux-next/blob/0cca97bf23640ff68a6e8a74e9b6659fdc27f48c/drivers/gpu/drm/xe/xe_wa.c#L262) wird mit 30.0 angegeben.

[reaperrr]

Warum redet er dann vom Zen5-X3D wenn er Strix Point meint und warum kommt er dann mit einer dGPU?
Ich habe es eher so verstanden, dass ARL-S einfach zu viel Silizium und ein zu komplexes Konstrukt für das Gebotene braucht.

- Grafikeinheit für die Grafikleistung viel zu groß
- CPU-Leistung für den Aufwand im Vergleich zu Zen5X3D zu gering
- trotz des hohen Gesamt-Silizium-Aufwandes keine Copilot+-taugliche NPU

Eine iGPU mit 8 EUs wäre für ARL-S eigentlich völlig ausreichend, kein vernünftiger Mensch spielt mit dem Ding ohne Graka Spiele und für alles andere sollten auch weniger EUs reichen.
Die Media-Engine kann man ja trotzdem verbauen.

Und die 11(?) TOPs-NPU hat auch wenig Nutzen, die hätte man auch gleich ganz weglassen können.

Desktop-Zen5 konzentriert sich halt wesentlich besser aufs Wesentliche, während Intel mit ARL-S versucht die Eiermilch-legende Wollmilchsau anzubieten, dabei aber im Bereich iGPU und NPU Transistoren vergeudet, die ihnen gegen Zen5 auch nicht viel helfen werden und z.B. in größerem CPU-L3 besser angelegt gewesen wären.

[KarlKastor]

Intels Arrow-Lake dürfte extrem teuer in der Herstellung sein: 4 Dice auf einem weiteren Interposer und das Größte davon im teuersten N3B-Prozess, also ungleich teurer als AMDs Zen5-Derivate.

Der größte Die ist der SoC Die, der ist nicht in N3B.

[KarlKastor]

Solange alle Reviews mit dem Performance Profil gemacht werden und Boardhersteller eine klare Warnung einbauen ist das doch OK.
Ich sehe persönlich auch nicht wirklich eine Notwendigkeit über 250W PL2 zu gehen. Ich würde eher dazu neigen das PL1 im Alltagsbetrieb auf 150-200W herunter zu stellen damit ich bei Volllast nicht immer glaube ein Helikopter landet gerade.
Aber die 250W hat nur der i9. Die andren K/KF nur 125W. Das wird definitiv einen Einfluss auf Benchmarkresultate haben. Verwunderlich, dass Intel so konservativ geht.
So extrem wie bei Raptor Lake muss ja nicht, aber ich hätte bei allen K Modellen 250W dauerhaft erwartet. Oder zumindest beim i7. Der i5 wird wohl ganz gut mit 125W auskommen.

[amdfanuwe]

89774
https://www.computerbase.de/artikel/prozessoren/intel-arrow-lake-s-core-ultra-200s-details.89465/

[Gipsel]

89774
https://www.computerbase.de/artikel/prozessoren/intel-arrow-lake-s-core-ultra-200s-details.89465/
Widerspricht dem hier (oder ist wenig aussagekräftig, da PL1 und PL2 nicht richtig dranstehen):
https://pbs.twimg.com/media/GZwhqkPaAAEgtH4?format=jpg&name=large

Für das Performance-Profil (das ist Standard) gilt dies hier:
Modellreihe| PL1 | PL2
Ultra 5 K/KF|125W|159W
Ultra 7 K/KF|125W|250W
Ultra 9 K/KF|250W|250W
non-K/KF| 65W? | ?

[Prinzenrolle]

Alles was für mich über 125W hinausgeht und damit nicht mehr schön mit Luft gekühlt werden kann, ist uninteressant. Für wird es dann wohl die 65W Variante.

[MiamiNice]

Man kann mehr als 125 Watt nicht mehr "schön" mit Luft kühlen? Welche Eigenschaften muss eine Kühlung haben um als schön durchzugehen? Nur 2 Heatpipes statt 3??? :D Auf gängigen CPU Luftkühlern, dato heute, stehen oft Werte bis über 300 Watt im Datenblatt. 120 Watt kann man quasi passiv kühlen, oder meist Du das als "schöne" Kühlung?

[aceCrasher]

Man kann mehr als 125 Watt nicht mehr "schön" mit Luft kühlen? Welche Eigenschaften muss eine Kühlung haben um als schön durchzugehen? Nur 2 Heatpipes statt 3??? :D Auf gängigen CPU Luftkühlern, dato heute, stehen oft Werte bis über 300 Watt im Datenblatt. 120 Watt kann man quasi passiv kühlen, oder meist Du das als "schöne" Kühlung?
"Schön" ist <1000rpm Lüfterdrehzahl selbst bei anhaltender Vollast würde ich sagen.

[Badesalz]

Alles was für mich über 125W hinausgeht und damit nicht mehr schön mit Luft gekühlt werden kann, ist uninteressant.Was werkelt denn da aktuell?

[fondness]

MSI scheint gerne Zeug zu leaken:
https://videocardz.com/newz/msi-claims-unlocked-core-ultra-9-285k-will-require-less-power-and-offer-lower-temps-than-i9-14900k

[fondness]

Warum? AMDs Media Engine kann nicht mithalten, das weiß doch jeder. Ist schon ewig so.


AMD hat hier mit RDNA3 deutlich nachgelegt. Auch wenn ich es zugegebenermaßen selbst nicht verwende.

[Wuge]

Völlig weltfremd. IGPUs werden in Desktops nur genutzt wenn es irgendeine 0815 Büro Möhre ist.

Für meinen Vater würde das sogar schon langsam reichen... Anno + Command & Conquer ;)

Und hey - in der letzten Scalperphase, als die 3090 schon verkauft und die 4090 schwer zu bekommen war hab ich auf der iGPU ganz passabel Forza Horizon spielen können. Also für n kleines Game zwischen durch am Productivity PC taugen die schon. Vielleicht ist das sogar ein Verkaufsargument an Steuerberater, Ingenieure ohne CAD und sonstige Officehelden :D

[fondness]

Für meinen Vater würde das sogar schon langsam reichen... Anno + Command & Conquer ;)

Und hey - in der letzten Scalperphase, als die 3090 schon verkauft und die 4090 schwer zu bekommen war hab ich auf der iGPU ganz passabel Forza Horizon spielen können. Also für n kleines Game zwischen durch am Productivity PC taugen die schon. Vielleicht ist das sogar ein Verkaufsargument an Steuerberater, Ingenieure ohne CAD und sonstige Officehelden :D

Da kauf ich mir dann aber auch eher sowas mit ordentlicher APU:
https://www.computerbase.de/artikel/pc-systeme/beelink-ser9-amd-ryzen-ai-9-hx-370-test.89812/

Anstatt ein riesen Desktop-Gehäuse dass dann völlig leer ist ohne dGPU.

[Prinzenrolle]

"Schön" ist <1000rpm Lüfterdrehzahl selbst bei anhaltender Vollast würde ich sagen.

Richtig.

Was werkelt denn da aktuell?

11900F, der wird langsam etwas langsam für die 4090.

[Der_Korken]

MSI scheint gerne Zeug zu leaken:
https://videocardz.com/newz/msi-claims-unlocked-core-ultra-9-285k-will-require-less-power-and-offer-lower-temps-than-i9-14900k

Spricht ehrlich gesagt nicht so für die Effizienz, wenn man von 250 auf 300W noch 10% im Cinebench rausholt. Ich hatte gehofft, der 285K wäre mit 250W bereits völlig übersättigt.

[Gipsel]

Spricht ehrlich gesagt nicht so für die Effizienz, wenn man von 250 auf 300W noch 10% im Cinebench rausholt. Ich hatte gehofft, der 285K wäre mit 250W bereits völlig übersättigt.Im Prinzip demonstriert da MSI, wie schlecht die Effizienz ihrer VRMs auf dem Arrowlake-Board ist, unter 87% (im Vergleich zu den ~94% des Raptorlake Boards). :freak:

[ChaosTM]

Scheinen die gleichen Saufköpfe zu sein wie der/die Vorgänger, aber immerhin können Enthusiasten jetzt das letzte aus den CPUs rausquetschen ohne Angst haben zu müssen, dass die Dinger abrauchen.
Mal abwarten ob sich letzteres auch bewahrheitet.

Effizienzwunder sind es natürlich keine.

[Der_Korken]

Im Prinzip demonstriert da MSI, wie schlecht die Effizienz ihrer VRMs auf dem Arrowlake-Board ist, unter 87% (im Vergleich zu den ~94% des Raptorlake Boards). :freak:

Nope, Arrow Lake kommt bei beiden Boards auf 86-87%. Die 94% sind der 14900K (warum auch immer die VRM-Effizienz da so viel besser ist).

Sorry, falsch gelesen. Delete.

[Prinzenrolle]

Effizienzwunder sind es natürlich keine.

Natürlich kann man immer noch etwas mit OC herausholen, das muss ja nichts bedeuten. Ein Bekannter hat vor Wochen getestet ein 285K bringt bei leicht über 100Watt 13900K Performance im Cinebench R23.
Das ist dann schon effizient, es kommt auf den Betriebspunkt an.

[basix]

Im Prinzip demonstriert da MSI, wie schlecht die Effizienz ihrer VRMs auf dem Arrowlake-Board ist, unter 87% (im Vergleich zu den ~94% des Raptorlake Boards). :freak:

Habe mir das selbe gedacht ;D

Aber hey, wenn es gut kühlbar bleibt, under dem Strich immer noch deutlich weniger Energie aufnimmt wenn man nicht gerade das Max. Profil nutzt (da ARL effizienter ist) und dazu noch günstiger wird (da günstigere VRMs) ist doch alles gut ;)

[dildo4u]

OC Tool für Arrow Lake verfügbar.


Es gibt zwei Versionen von Intel® XTU:

Intel® XTU Version 7.14.2.14: Unterstützt Intel® Core™Prozessoren mit freiem Multiplikator (14. Generation) und ältere Prozessoren.
Intel® XTU Version 10.0 oder höher: unterstützt entsperrte Intel® Core™ Ultra Prozessoren (Serie 2)


Changes
• Replaced XTU drivers with the Intel® Innovation Platform Framework (Intel®
IPF)
• Only supported processor family is Arrow Lake
• Added SA Fabric controls
• Added Dual Reference Clock controls
• Added support for Granular per-core ratios
• Added support for Maximum Voltage
• Added per-point Real Time Memory Timings controls
• Added Core Parking controls
• Security improvements
• Per-core ratio controls will no longer be automatically tuned based on values
tuned in the active-core ratios.
o 1 Active Core Ratio will be automatically tuned upwards if per-core
ratios are tuned above the current 1 Active Core Ratio. Otherwise,
active-core ratios controls will no longer be automatically tuned based
on values tuned in the per-core ratios.
o The effective ratio will be the lower of the applicable active-core and
per-core ratios
• "Default" voltage has been removed from Voltage Override controls. All
Voltage Override controls will now reflect their true value, even at boot.
• OC TVB is now available on E-Cores, per-cor





https://downloadmirror.intel.com/831304/XTU-10.0.0.76-ReleaseNotes.pdf


https://www.intel.de/content/www/de/de/download/17881/intel-extreme-tuning-utility-intel-xtu.html

[MiamiNice]

Die viel interessante Meldung ist eigentlich, dass Error Lake deutlich besser OCbar sein soll als der Vorgänger. Man kann quasi alles einzeln OCén, jeder Core hat z.b. eine seperate Spannungsversorgung. Man kann jeden Bus einzeln OCen + Voltage anpassen. Das gilt auch insbesondere für den Bus der die Chiplets verbindet und generell für jedes Chiplet auch einzeln. Der Memory Controller soll der beste sein den Intel jemals gebaut hat und die höchsten Taktraten erlauben die man je auf einem Intel (und damit generell) gesehen hat.
Der Bauer hat das Teil seit Wochen stehen 285k + 780 Apex und lässt zwischen den Zeilen gerne was fallen auf overclockers oder in seinem ARL Video.

Vielleicht, ganz vielleicht, wird das Teil mit OC doch brauchbar. Hängt imo daran wie hoch man mit dem Interposer, MC und Ram Speed kommt. Wenn sich die Latency auf unter 50ns drücken lässt, wird es geil. Ansonsten AMD X3D.

[Edgecrusher86]

Wenn man ehrlich ist, lohnt von Raptor-Lake(-R) oder Zen 4 X3D kommend, sowohl Arrow, als auch Zen 5 X3D nicht. Ich für meinen Teil führe nur noch Sockelupgrades aus, wenn es MINDESTENS 50-100% Mehrleistung durch die Bank gibt.
Aber wer Zeit und Spaß hat und gerne bastelt und testet - warum nicht? Jedenfalls hole ich dann lieber nur alle zwei bis vier Jahre eine neue Enthusiasten-GPU, wenn die Plattform noch solide Grundleistung dafür bietet. Für mich sind das locker drei GPU-Generationen.
Früher hab ich auch alle 1-2 Jahre den Sockel gewechselt, aber nun ja - es lohnt einfach nicht mehr wirklich - für mich zumindest. Ende 2023 war es aber mal wieder an der Zeit - denn auch wenn ich idR mit nem 60er Cap spiele - der halte Haswell-E OC kam je Engine
doch net mehr hinterher bzw. es gab merkliche Drops - langt mir nun wieder bis grob zum nächsten Jahrzehnt (die RTX 5090 wird hier auch ausgelassen, da ich sie derweil eh nicht wirklich auslasten würde bei 99% DIV Raster und so etwas wie CP 2077 PT nur mal alle Jahre angeworfen wird). xD

Ja, sicherlich wird Z890 wieder der Benchmark für RAM-OC-Freunde werden, das steht außer Frage. Wir werden wohl bis 12800 MT/s sehen innerhalb der nächsten zwei Jahre mit CUDIMM.
Bezüglich CPU-OC...ich denke nicht, dass 6,0+ GHz drin sein werden - vermutlich maximal 5,7-5,9 GHz Allcore.

[Wuge]

Die viel interessante Meldung ist eigentlich, dass Error Lake deutlich besser OCbar sein soll als der Vorgänger. Man kann quasi alles einzeln OCén, jeder Core hat z.b. eine seperate Spannungsversorgung. Man kann jeden Bus einzeln OCen + Voltage anpassen. Das gilt auch insbesondere für den Bus der die Chiplets verbindet und generell für jedes Chiplet auch einzeln. Der Memory Controller soll der beste sein den Intel jemals gebaut hat und die höchsten Taktraten erlauben die man je auf einem Intel (und damit generell) gesehen hat.
Der Bauer hat das Teil seit Wochen stehen 285k + 780 Apex und lässt zwischen den Zeilen gerne was fallen auf overclockers oder in seinem ARL Video.

Vielleicht, ganz vielleicht, wird das Teil mit OC doch brauchbar. Hängt imo daran wie hoch man mit dem Interposer, MC und Ram Speed kommt. Wenn sich die Latency auf unter 50ns drücken lässt, wird es geil. Ansonsten AMD X3D.

Das wird unheimlich komplex wenn man alle Taktdomänen ans Limit fahren will. S1700 braucht ja schon Wochen um alles perfekt auszulöten. Könnte spannend werden mit ARL.

Ich denke beim Fabric liegt das meiste Potenzial. Das Zeug ist traditionell konservativ getaket. Vielleicht lässt sich da die Spieleleistung fixen.

Und natürlich ist der IMC der beste aller Zeiten. Wäre ja auch schlimm, wenn man einen schlechteren verbaut als bisher ;)

[MiamiNice]

Ja natürlich erwartet man einen besseren MC in einer neuen Gen ;) Dieser soll aber außergewöhnlich gut sein, was auch immer das heißen mag.

[E39Driver]

Ich muss ja meinen ehrlichen technischen Respekt an Leute aussprechen, die sich heutzutage noch OC bei CPUs antun. Finde ich interessant zu lesen was mit entsprechenden Aufwand wohl immer noch raus zu holen ist. Das Thema scheint ja sehr komplex und zeitaufwendig geworden zu sein für überschaubare Mehrwerte. Früher konnte man prozentual ja deutlich mehr mit weniger Aufwand erreichen.

Ich war beim OC immer nur opportunistisch unterwegs und hab es mal gemacht für:

Athlon XP-M: als armer geiziger Schüler der sich nichts besseres leisten konnte und so das Maximum für kleines Geld herausholen konnte
Intel Sandy Bridge /Broadwell-E Generation: Einfach weil es so einfach war und man ohne Aufwand zweistellige Zugewinne hatte
Vega 64: Aus Geldgier beim Cryptomining Boom 2017^^ Hab 2 Wochen Arbeit in eine händisch perfektionierte Vega 64 gesteckt. Am Ende hat die Karte wahlweise 1600 Mhz unter Luft erreicht oder aber minimierten Verbrauch bei maximierten Cryptonight-Algo Output und war damit beim Effizienzvergleich wohl einer der 5 besten gewesen. In den Foren kaum einen gesehen der an diese Werte ran kam

[MiamiNice]

tuZkT45FTFU

gCmK70tVYX4

[Wuge]

Ich war beim OC immer nur opportunistisch unterwegs und hab es mal gemacht für:

Athlon XP-M: als armer geiziger Schüler der sich nichts besseres leisten konnte und so das Maximum für kleines Geld herausholen konnte
Intel Sandy Bridge /Broadwell-E Generation: Einfach weil es so einfach war und man ohne Aufwand zweistellige Zugewinne hatte
Vega 64: Aus Geldgier beim Cryptomining Boom 2017^^ Hab 2


Bei mir gings mit dem ersten PC los, Pentium 133 auf 160. Am geilsten war der Northwood C, 2.4er über 3 Ghz geprügelt. Solche Zeiten gibts nicht mehr... bei Broadwell-E war aber wirklich noch viel zu holen.

[ChaosTM]

ESCOM 386DX20 - konnte DOS 3.2 monochrom mir 60hz fahren.
Und das ohne dediziert GPU!

Arrow Lake ist leider ziemlich uninteressant, zumindest für mich.

[dildo4u]

285k für 620€ bei Proshop(Vorbestellung)


https://www.proshop.de/CPU/Intel-Core-Ultra-9-285K-Arrow-Lake-S-CPU-24-Kerne-37-GHz-Intel-LGA1851-Intel-Boxed-ohne-Kuehler/3295794?utm_source=geizhals&utm_medium=cpc&utm_campaign=pricesite

[Matrix316]

Mehr Effizienz für gleiche (oder teils weniger) Leistung - wer denkt sich sowas aus? =)

Raptor Lake war doch eigentlich schon relativ effizient, wenn man mal die Power etwas runter limitiert. Warum geht Intel nicht auch den 3D Cache Weg? Macht das Power Limit auf 125W, gebt den P Cores 3D Cache - oder einfach deutlich mehr Cache, wenn 3D nicht geht und schon müssten die Gaming Benchmarks nach oben schnellen, oder? :uponder:

[Zossel]

Ich muss ja meinen ehrlichen technischen Respekt an Leute aussprechen, die sich heutzutage noch OC bei CPUs antun.
Mit Technik hat das eher wenig zu tun, das ist stumpfes Try & Error.
Früher konnte man prozentual ja deutlich mehr mit weniger Aufwand erreichen.
Mittlerweile sind die Sensorik und die physikalischen Modelle der Chips einfach besser geworden. Ist auch viel besser so als wenn einem ein zerfummelter Chip die Platte schreddert.

[Zossel]

ESCOM 386DX20 - konnte DOS 3.2 monochrom mir 60hz fahren.

Auf so einer CPU konnte man doch schon richtige Betriebssysteme nutzen.
Besonders lustig fand ich damals immer diese Konstruktionen wie damals Mailboxen mit mehreren Modems unter DOS betrieben wurden.
Da hatte jedes Modem einen eigenen Rechner unter DOS und die Rechner wurden mit Novell vernetzt. Und das alles nur weil diese Software nicht mit einer simplen seriellen Mehrport-Karte umgehen konnte.

[Badesalz]

@Zossel
Bis dann endlich die Amigas kamen ;)

[Zossel]

@Zossel
Bis dann endlich die Amigas kamen ;)

Stimmt, irgendwann gab es auch uucp für diese Kisten.

[Badesalz]

Es gab auch MultiFace(Card) oder so eine von vom C= selbst. Das lief alles ohne Murren und sich auf den Mailboxen spätestens mit dem 68030 selbst noch angesichts Win95 Software wie Hardware problemlos gehalten.

Und das war auch die letzte... Kommunikationshardware die von außen einfach nicht hackbar war. Jegliche solche Versuche führten ausnahmslos zum sofortigen Notstop (Guru Meditation) :tongue:
Nicht wie das neumodische Zeug später mit MMUs & Co. :wink:

OT ende

[Zossel]

Es gab auch MultiFace(Card) oder so eine von vom C= selbst. Das lief alles ohne Murren und sich auf den Mailboxen spätestens mit dem 68030 selbst noch angesichts Win95 Software wie Hardware problemlos gehalten.


Oder man hat einfach den 8250 gegen einen 16550 getauscht.

[dildo4u]

Blender Werte genau zwischen 14900KS und 9950X


https://www.pcgameshardware.de/Core-Ultra-9-285K-CPU-280886/News/Anwendungsbenchmarks-mit-Blender-und-CPU-Z-1457814/

[Prinzenrolle]

Blender ist nicht die Paradedisziplin von Arrow Lake.

[M4xw0lf]

Blender ist nicht die Paradedisziplin von Arrow Lake.
Mal schauen was neben dem CPU-Z Benchmark als Paradedisziplin bleibt.

https://pbs.twimg.com/media/GaJj0e1awAADdX-?format=png&name=900x900

https://x.com/harukaze5719/status/1847148619763536224

[Gipsel]

In CB23 ist der 285K angeblich quasi gleichauf zum 9950X bei nur etwas höherem Powerlimit.
https://www.pcgameshardware.de/screenshots/1280x1024/2024/10/Screenshot-2024-10-19-at-21-18-51-Intel-Core-Ultra-9-285K-CPU-Is-Up-To-6_-Faster-at-250W-Versus-Core-i9-14900KS-At-Extreme-Mode-pcgh.png
https://www.pcgameshardware.de/Core-Ultra-9-285K-CPU-280886/News/250-Watt-im-Cinebench-R23-1457967/

[aufkrawall]

Wenn der genauso kacke kühlbar ist wie RTL, sind die Werte für 250W völlig uninteressant für 99% der Käufer.

[Loeschzwerg]

6.6GHz mit einem 285K, das Ergebnis wurde bei CPU-Z leider schon wieder gelöscht:
https://x.com/momomo_us/status/1848025439354372360

[Gipsel]

6.6GHz mit einem 285K, das Ergebnis wurde bei CPU-Z leider schon wieder gelöscht:
https://x.com/momomo_us/status/1848025439354372360
Alle Kerne bis auf einen deaktiviert (nur 2 E-Kerne liefen noch zusätzlich zum P-Kern) bei knapp 1,6V von einem bekannten Extrem-Übertakter. Kühlung? Ich meine, unter flüssigem Stickstoff wäre das jetzt nicht so beeindruckend.

[MiamiNice]

Das muss Wasser gewesen sein, Custom Loop. Für LN2 zu wenig, für Luft eigentlich ein Stück zu viel. Aber wer weiß, aufgrund der Fertigung und es Verbrauchs pro Kern, könnte das ggf. auch Luft sein. Das wäre dann schon beeindruckendm, auch auf einem Kern.

[MSABK]

Die mobilen Chips sollen eine bessere GPU als Lunar Lake haben. Dachte die sind gleich.

https://www.notebookcheck.com/Intel-Arc-140T-iGPU-von-Arrow-Lake-H-uebertrifft-Arc-140V-von-Lunar-Lake-in-ersten-Benchmarks.905369.0.html

[RoNsOn Xs]

Anscheinend Lieferprobleme, bzw die Großlieferanten haben nichts bestellt. Wird wohl kaum bis keine Auslieferungen zum 24.10. geben, was man so liest.

[maximus_hertus]

Anscheinend Lieferprobleme, bzw die Großlieferanten haben nichts bestellt. Wird wohl kaum bis keine Auslieferungen zum 24.10. geben, was man so liest.

Wie meinen? Nur geringe Stückzahlen am 24.10. (und auch darüber hinaus) verfügbar?

Kann ich mir eigentlich kaum vorstellen. Auf der anderen Seite will man wohl asap RPL "los werden" (als "Flaggschiff). Ich bin gespannt.

[RoNsOn Xs]

Mehrere Shops schrieben verschiedene Vorbestellern, dass sie von ihren Lieferanten keine Ware rechtzeitig bekommen. Man spricht mittlerweile von einer langen Verzögerung Richtung Ende des Jahres.
Unterstrichen wird das mittlerweile von den Listungen auf Geizhals, die zurück gingen.
Hinzu kommen so Aussagen wie von Igor:
https://www.igorslab.de/community/threads/intel-arrow-lake-s-und-h-in-der-kurzvorstellung-deutlich-h%C3%B6here-effizienz-k%C3%BChler-und-nicht-langsamer.10360/page-2#post-284752

[horn 12]

Ja, man will vorher von RL abverkaufen
und da die Händler die Preise der NON 3D Prozessoren senkte
und der 9800X3D vor der Türe steht hat man wohl nicht die Allerbesten Aussichten auf Guten Absatz der intel CPU´s

[E39Driver]

Interessante Wendung. Da kann der Launch Übermorgen ja doch noch spannend werden, welche Überraschung einen da erwartet und scheinbar für die Verzögerung sorgt

[Zossel]

Ja, man will vorher von RL abverkaufen

Die neuen Intels kommen erst im Jahr 2026?

[dildo4u]

Paar Cinebench R23 Werte mit offenen Power Limit 46K 370Watt.
Stock 279 Watt 42k.


https://videocardz.com/pixel/unlocked-intel-core-ultra-9-285k-approaches-370w-power-draw-during-cinebench-test

[y33H@]

stock 279W ist nicht korrekt weil bei 250W abgeriegelt werden sollte.

[fondness]

Die-Shot:
Für mich immer noch unfassbar wie groß die P-Cores im Verhältnis zu den eCores sind...

https://i.postimg.cc/tTp4HXbd/image.jpg (https://postimg.cc/DWpTr38m)

Hier auch noch weitere Shots aller Chiplets: https://x.com/9550pro/status/1848573032799080586

[fondness]

Das erklärt wohl die schlechte Spieleperformance:

https://i.postimg.cc/fL8DnmBZ/image.jpg (https://postimages.org/)

https://x.com/9550pro/status/1848345024624468441

[Raff]

Die (gegenüber RPL, Zen etc.) miese DRAM-Zugriffszeit hatte Leo letztens in den News thematisiert. Das ist ein Erbe von Lunar Lake bzw. kommt anscheinend durch die Chiplets.

MfG
Raff

[dildo4u]

Der 9950X schafft unter 70ns also ein Problem mit Intels implementierung?


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

[Raff]

Scheint so. Mit einem manuell aufgedonnerten RPL kommt man in tiefe 50er-Bereiche: https://extreme.pcgameshardware.de/attachments/1729162620666-png.1472302/ (DDR5-8000 "maxed")

MfG
Raff

[MiamiNice]

Das erklärt wohl die schlechte Spieleperformance:

https://i.postimg.cc/fL8DnmBZ/image.jpg (https://postimages.org/)

https://x.com/9550pro/status/1848345024624468441

Das ist zwar das Problem vom ARL, aber wer auch immer diesen Screen gemacht, macht es nicht richtig. Das ist wieder mal völlig am Publikum vorbei getestet, wahrscheinlich mit 5600er DDR5. Die Kiste hält sich ohne OC vom Ring irgendwo bei um 70ns auf. Das ist klar viel zu hoch, aber eben nicht dreistellig.

[Exxtreme]

Ja, die 109 ns werden wehtun in Spielen. Aber auch Anwendungen, die in verwalteten Umgebungen laufen, werden hier nicht gut harmonieren. Damit meine ich Java- oder Javascript- oder Python-Programme. Gut, eventuell werden bessere Microcode-Versionen das etwas verbessern.

[fondness]

Das ist zwar das Problem vom ARL, aber wer auch immer diesen Screen gemacht, macht es nicht richtig. Das ist wieder mal völlig am Publikum vorbei getestet, wahrscheinlich mit 5600er DDR5. Die Kiste hält sich ohne OC vom Ring irgendwo bei um 70ns auf. Das ist klar viel zu hoch, aber eben nicht dreistellig.

Schon klar, dass das nicht maxxed out ist, aber maxxed out sind auch nicht die ~67ns eines 9950X. Mit default settings über 100ns ist jedenfalls extrem schlecht.

Hätte mir nicht gedacht, dass Intel so dumm ist und massiv Speicherlatenz opfert. Ist doch klar wozu das führt. Gab zwar schon Spekulationen dazu, dass der ausgelagerte MC dazu führt, aber so richtig glauben wollte ich es nicht.

[Der_Korken]

Das ist zwar das Problem vom ARL, aber wer auch immer diesen Screen gemacht, macht es nicht richtig. Das ist wieder mal völlig am Publikum vorbei getestet, wahrscheinlich mit 5600er DDR5. Die Kiste hält sich ohne OC vom Ring irgendwo bei um 70ns auf. Das ist klar viel zu hoch, aber eben nicht dreistellig.

(120,39 GB/s) / (128 B) = 7,52 Ghz, d.h. der RAM muss mit min. 7520 Mhz gelaufen sein, um auf diese Leserate zu kommen.

Edit: Und ja, 100ns wäre absolut katastrophal. Das dürfte sogar noch schlechter sein als die allererste Generation an Threadrippern, wo mehrere Dies über ein Package einen verteilten RAM-Zugriff gefahren sind. Aber halt mit 1333Mhz IF-Takt und ohne advanced packaging.

Edit²: OK, Der 1950X lag bei knapp 110ns, aber dafür nur mit popeligem 2400er-RAM: https://www.anandtech.com/show/11726/retesting-amd-ryzen-threadrippers-game-mode-halving-cores-for-more-performance

[dildo4u]

Ja ich würde den neuen Ram Controller nicht so hypen der Standard bleibt bei 5600 nur die neuen DDR5 Module mit Extra Hardware bringen mehr was nix mit der CPU an sich zu tun hat.

[Zossel]

Ja, die 109 ns werden wehtun in Spielen. Aber auch Anwendungen, die in verwalteten Umgebungen laufen, werden hier nicht gut harmonieren. Damit meine ich Java- oder Javascript- oder Python-Programme. Gut, eventuell werden bessere Microcode-Versionen das etwas verbessern.

Was verstehst du unter "verwalteten Umgebungen"?
Java, Javascript, Python reagieren stark auf DRAM-Latenzen?
Kannst du ein Worte der Erklärung dazu schreiben oder ist das lediglich eine Beobachtung?

[Exxtreme]

Was verstehst du unter "verwalteten Umgebungen"?
Java, Javascript, Python reagieren stark auf DRAM-Latenzen?
Kannst du ein Worte der Erklärung dazu schreiben oder ist das lediglich eine Beobachtung?

Verwaltete Umgebung = sowas wie die Java Virtual Machine.

Und es ist so, diese Programmiersprachen verwenden Zeiger/Referenzen für die normalsten Dinge. Die Datenstrukturen, auf die diese Zeiger/Referenzen verweisen, landen auf dem Heap. Und das harmoniert wiederum sehr schlecht mit CPU-Caches. Denn wenn man Speicher allokiert dann hat man keinerlei Kontrolle darüber wo der Speicher physisch ist, den man bekommt. Speicher zuweisen macht das OS. Sprich, die Datenstrukturen, auf die die Zeiger/Referenzen zeigen, werden sehr oft im RAM landen und schlechte Latenzen werden hier negative Auswirkungen haben.

[Gipsel]

(120,39 GB/s) / (128 B) = 7,52 Ghz, d.h. der RAM muss mit min. 7520 Mhz gelaufen sein, um auf diese Leserate zu kommen.

Edit: Und ja, 100ns wäre absolut katastrophal.DDR5 >8000 mit Gear 4?
Mit Gear 2 sollten die Latenzen besser aussehen. Ansonsten ist nicht klar, warum bei den gestackten Dies von intel die Latenzen soviel schlechter sein sollten als bei den Zens mit über das PCB verbundenem IO-Die.

[w0mbat]

Ich kann mir die Latenz nicht vorstellen. Zen 5 muss via IFoP vom CCX zum IOD und wieder zurück, das ist nicht mal "advanced" packaging.

ARL-S nutzt 2.5D stacking mit Foveros. Die Leitungen verlassen da nicht das Silizium und auch die Distanz sollte kürzer sein.

Was läuft da falsch?

[Kriegsgeier]

Treiber/Microcode noch nicht fertig?

[Gipsel]

Ich kann mir die Latenz nicht vorstellen. Zen 5 muss via IFoP vom CCX zum IOD und wieder zurück, das ist nicht mal "advanced" packaging.

ARL-S nutzt 2.5D stacking mit Foveros. Die Leitungen verlassen da nicht das Silizium und auch die Distanz sollte kürzer sein.

Was läuft da falsch?Intels FOVEROS ist ziemlich schlecht im Vergleich z.B zum hybrid bonding für AMDs VCache. Und die Latenz hängt eher am Fabric, nicht wie die Leitungen über 15mm laufen (der Stromverbrauch des Interfaces wird davon aber beeinflußt).
Ich meine, die 100ns sieht man nur unter bestimmten Umständen (Gear 4? Aida noch nicht auf Arrow Lake getuned?).

[HOT]

Design verkackt würde ich sagen. Vielleicht ließe das noch per Software etwas optimieren, aber ich glaube, dass da einfach blöde Entscheidungen getroffen wurden.

[mboeller]

Treiber/Microcode noch nicht fertig?

2 Tage bevor du die CPU kaufen kannst?

[Linmoum]

2 Tage bevor du die CPU kaufen kannst?Ist ja nicht so, als hätte es das noch nie gegeben...

Dass das aber keine Software-Geschichte ist, lassen die eigenen Benchmarks von Intel schon erahnen. In unabhängigen Reviews wird das übermorgen mit Sicherheit auch noch mal schlechter ausfallen. Vermutlich wird man "nur" über die Effizienz punkten können und auch da wird man womöglich gegenüber AMD trotzdem noch das Nachsehen haben.

[Exxtreme]

2 Tage bevor du die CPU kaufen kannst?

Bei Raptor Lake dauerte es zwei Jahre nach der Veröffentlichung bis der finale und gefixte Microcode da war. ;D Und Intel hatte schon immer eine extreme Software-Schwäche.

[Kriegsgeier]

ich wette der Igor weiß schon was diesbezüglich. Sollte er hier mitlesen: gib ein Zeichen, dass es so ist.

[Daredevil]

Wenn man bedenkt, das Lunar Lake und Arrow Lake für Intel ja in der Tat was "völlig neues" sein sollten und eben nicht der verhasste drölfte 14nm++++++ Refresh, dann ist es imho durchaus verkraftbar, wenn man ein wenig "Zen1" in einem Tik Schritt hat, sofern der Tok Schritt dann auch ähnlich wie bei AMD deutliche Besserung bringt.

Selbstverständlich erwartet man als High Performance Individual mehr von Intel als von AMD, so das ich auch verstehen kann, das Miami geknickt ist mit diesem Schritt. Vielleicht ist es auf langer Sicher aber das beste, ein ordentliches Chiplet Fundament zu haben als mit 450w gegen ne Mauer zu brettern. Intel konnte halt nicht mit dem weiter machen, was sie gerade gemacht haben, weil mit jedem Jahr AMD und Zen Intel belächelt wird.

Das AMD nun, obwohl Intel ja offenbar "Unbewaffnet" ist, direkt mit einem X3D und Preissenkung kontert, ist endlich mal die Härte, die ich in den letzen Jahren bei AMD so vermisst habe.
Angst ist das sicherlich nicht, sondern Intel in die Ecke drängen. Ich hoffe das spornt Intel zu mehr Geschwindigkeit an. :)
Ich habe allerdings ein Gefühl, das Arrow Lake auch Überraschungen bringen wird und freue mich sehr auf die ersten Reviews. Das Hallock offen zugibt, das man im Gaming nicht mithalten kann, lässt für mich zwischen den Zeilen lesen, das sie woanders besser sein werden. Entweder MT Performance, P/W oder im Traumland sogar beides.

Bastelspaß wird es auf jeden Fall geben. Ich könnte mir gut vorstellen, sofern Intel die Software liefert, manche Games auch einfach nur auf den E-Cores laufen zu lassen, wenn sich das in der Leistungsaufnahme abzeichnet. Die finde ich ein wenig spannender als den Rest als jemand, der effiziente MT Leistung will.

[Kriegsgeier]

Wäre es denkbar, dass Intel oder AMD Unrealengine Code in ihre CPU-Architektur aufnehmen/berücksichtigen? Da in 1-2 Jahren 90% der Spiele auf eben dieser Engine basieren werden?

Wer das als erster macht hat doch direkt in fast allen Gamebenchmarks haushoch gewonnen, oder?

[dildo4u]

So lange AMD die Konsolen im Griff hat müssen sie nix extra bauen die Engine muss auf PS5 und 6 performen.

Es gibt Pläne das die Konsolen selbst mit Hardware Raytracing mit 60fps laufen sollen.

9 Generation ist PS5

https://twistedvoxel.com/unreal-engine-5-lumen-60-fps-on-ps5-aiming-for-120-fps/

[Exxtreme]

Wäre es denkbar, dass Intel oder AMD Unrealengine Code in ihre CPU-Architektur aufnehmen/berücksichtigen?

Nein. Denn sowas wie "Unreal-Code" gibt es eigentlich nicht. Denn da reicht schon ein anderer Compiler und schon ist "Unreal-Code" ein ganz anderer. Und dann, was ist mit "Unreal-Code" unter Linux? Das ist auch ein ganz anderer Code als unter Windows etc.

[Prinzenrolle]

Hinzu kommen so Aussagen wie von Igor

Komplettsysteme sind genügend auf Halde, warum Shops nicht bestellen sollen, keinen Schimmer. Ja, ist nicht der Oberburner zum Zocken, mittlerweile weiß ichs auch, aber ansonsten nicht schlecht. Igor halt.

Mit default settings über 100ns ist jedenfalls extrem schlecht.

Damit würde man abstinken.;D Die Gaming Leistung wird mit diesem Gear Modus definitiv unterhalb des 14900K liegen. Irgendwelche Prerelease Tests aus dem Flurfunk hin oder her.

[dildo4u]

Es geht nicht nur um High-End Modell zum zocken man bekommt mittlerweile brauchbare B650 Boards für 110€, das dauert bis es neue Intel Boards in diesem Bereich gibt.

https://geizhals.de/asrock-b650m-hdv-m-2-90-mxbla0-a0uayz-a2914109.html?hloc=at&hloc=de

Man muss immer die ganze Plattform betrachten nicht nur die CPU.

[Wuge]

Naja + 15ns auf Raptor Lake für den IMC außerhalb des rings, +5-10ns für den niedrigeren Ring Takt, +4ns für CUDIMM und +10-15ns weil die RAM-Timings nicht ausgereizt sind. voilla.

[Lehdro]

Naja + 15ns auf Raptor Lake für den IMC außerhalb des rings, +5-10ns für den niedrigeren Ring Takt, +4ns für CUDIMM und +10-15ns weil die RAM-Timings nicht ausgereizt sind. voilla.
Du hast den Gear Mode auf "4" vergesssen. :tongue:

Aber wir wissen doch schon lange wo ARL-S bei den Speicherlatenzen landet: Bei 75-80ns bei halbwegs vernünftigem Speicher und ohne Gear 4. (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13611813&postcount=1257) Das ergibt dann auch alles halbwegs Sinn, wenn man auf AMD schielt. Theoretisch ist da auch noch Spielraum nach unten mit besseren Timings/Takt und mehr Ringbus Takt.

Die 100ns werden einfach an Gear 4 und relaxten Timings liegen. Der Ring wird quasi auch komatös sein. Das wird ein "max RAM frequency Run" sein...

[Undertaker]

Ist das im Link nicht ggf. auch mit CUDIMMs gemessen? Erstmal apples to apples vergleichen und dann bewerten würde ich vorschlagen... ;)

[Zossel]

Verwaltete Umgebung = sowas wie die Java Virtual Machine.

Und es ist so, diese Programmiersprachen verwenden Zeiger/Referenzen für die normalsten Dinge. Die Datenstrukturen, auf die diese Zeiger/Referenzen verweisen, landen auf dem Heap. Und das harmoniert wiederum sehr schlecht mit CPU-Caches. Denn wenn man Speicher allokiert dann hat man keinerlei Kontrolle darüber wo der Speicher physisch ist, den man bekommt. Speicher zuweisen macht das OS. Sprich, die Datenstrukturen, auf die die Zeiger/Referenzen zeigen, werden sehr oft im RAM landen und schlechte Latenzen werden hier negative Auswirkungen haben.
Nun ja, sobald man ernsthafteren Code in C schreibt der vielleicht auch noch was mit der realen Welt draußen was zu tun hat sieht das aber auch da nicht großartig anders aus.
Mein persönlicher Rekord in C waren 8 oder 9 "*" hintereinander, und malloc und free wurden da aufgerufen als gäbe es kein morgen.

In einer "verwalteten Umgebung" passiert derartiges allerdings für jeden kleinsten Pups den eine Software von sich geben soll.

[Zossel]

Ist das im Link nicht ggf. auch mit CUDIMMs gemessen?

Der Kram ändert doch nichts signifikant an Latenzen.

[mksn7]

Wäre es denkbar, dass Intel oder AMD Unrealengine Code in ihre CPU-Architektur aufnehmen/berücksichtigen? Da in 1-2 Jahren 90% der Spiele auf eben dieser Engine basieren werden?

Wer das als erster macht hat doch direkt in fast allen Gamebenchmarks haushoch gewonnen, oder?

Ja das geht, man könnte z.B. die branch prediction verbessern, caches schneller und größer machen, Taktraten erhöhen, OoO verbessern.

Ach ne warte, dann hätten sie einfach eine insgesamt schnellere CPU gebaut.

[Undertaker]

Der Kram ändert doch nichts signifikant an Latenzen.

Gibt es denn dazu schon Messungen? Ich könnte jetzt nicht erklären, ob das Durchschleifen und Verstärken genau 1ns, 5ns oder 10ns dauern sollte...

[Altehardware]

Wie lange die Latenz ist ne physische Sache und hängt vom pcb und den kupfermaterialstärke ab
Neben Temperatur und leitungslänge
Im chip reden wir über silizium vs trägermaterial was auf die kontakt Fläche mit den sockel gibt
Das sind in de regel kupferplätchen.
Wenn es also so große L3 zu ram gibt kann das nur am soc tile liegen wo der imc sitzt der mit den cpu tile verbunden wurde dafür wird ein Silizium interposer genutzt dieser scheint aber in nenn schlechteren node geringer zu Takten folge mehr cyclen zu warten Latenz steigt.

ab dem Sockel ist der mainbord Hersteller für die Stabilität zuständig
Da gilt die specs von Intel oder amd einhalten und ich ahne das intel hier mal wieder unrealistische Anforderungen gemacht hat etwa 24 layer t-topology dual dimm das keiner nutzt
realistisch sehe ich sogar ddr5 4133 in dual channel in 2-1 oder ddr5 8500 6-1 (gear 6)
Das ist vernichtend für die Latenzen.
ich nehme an das man die cudimms nutzen soll mit ddr5 5600
Die grundlegenden Latenzprobleme zwischen die tiles wird es nicht fixen damit sind die 100-130ns zum ram zementiert
Die cpu werden die langsamsten cpu fürs gaming sein und auf level der zen3 liegen von 2021

[Zossel]

Wie lange die Latenz ist ne physische Sache und hängt vom pcb und den kupfermaterialstärke ab
Neben Temperatur und leitungslänge

Miami hat schon mal ähnliches Zeug erzählt.

Hier kannst du dir ein real existierendes DRAM-Layout anschauen: https://github.com/ciaa/Hardware/tree/master/PCB/ACC/CIAA_ACC
Zum anglotzen kicad installieren: https://www.kicad.org/ (Hier kann man keine eigenen Bilder hochladen)

[dildo4u]

Launch wird angeblich ein Desaster

V_UHVWcfeTg