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

[iamthebear]

Nach Arrow Lake sollen ja rentable units kommen. So wie ich das verstanden habe kann hier generell ein Kern je nach Auslastung in 2 kleinere Kerne aufgesplitted werden d.h. es wird dann nicht nur der L2 sondern alle Einehiten geshared (oder bei MT Load eben nicht).

Was die Cache Level angeht sehe ich folgende Trends:
Wenn SRAM nicht mehr skaliert wird der LLC vom CCD in den Base Die wandern und dabei auch gleich mit der iGPU geshared werden. AMD kann das derzeit noch nicht machen, da deren Packaging derzeit was die Energieeffizienz angeht noch hinterher hinkt (sieht man auch gut bei Navi31).
Trotzdem muss damit das funktioniert der Ringbus entlastet werden d.h. man benötigt mehr L2.

Ein größerer L2 hat jedoch höhere Latenzen. Den L1 kann man nur schwierig vergrößern also kann ich mir gut vorstellen, dass der L2 in 2 Level geteilt wird: Ein kleiner schneller für den Großteil der Zugriffe und einen langsameren, der immer noch schneller ist als der bisherige L3.

Die Frage, die ich mir stelle:
Wäre es nicht möglich 2 Cachestufen parallel zu durchsuchen? Im Fall von L1->L2 ist es auf Grund der hohen L1 Hitrate nicht sinnvoll und L2->L3 auf Grund der Ringbus Belastung. Aber wenn es 2 private Cachestufen sind wieso nicht?

[HOT]

MMn sollte man folgendes beachten:
Jim Keller will schon seit 1998 CPU-Kerne vereinen und 2 Threads (CMT) und reverse SMT einbauen. Daraus ist der ursprüngliche K8 (der gecancelt wurde), K9 (der gecancelt wurde), der ursprüngliche K10 (der gecancelt wurde) und mit CMT dann bei BD umgesetzt worden (Projekt gescheitert). Intel nimmt jetzt einen neuen Anlauf mit Arrow Lake (CMT, diemal mit vollen Kernen auf Basis der .mont-Technologie) und Cougar Cove (Reverse SMT, Intel nennt das jetzt rented Units). Das ist das mMn Royal Core-Projekt. Ressourcen sharen, sowohl für MT, als auch für IPC.

Jetzt ergeben auch die Projektionen bei Igor Sinn. Die Cores an sich haben nicht die IPC, das hätten sie nur mit rented Units, welche in Lion Cove noch nicht funktionieren, erst in Cougar Cove.
Der 3MB L2$ ist mMn geshared in einem 2-CPU-Modul.

Und Beast Lake könnte einfach eine CPU auf Basis von 16 Cougar Cove-Kernen sein, welche auch mit bis zu 8 hoch-IPC-Threads laufen kann. Wäre ein echt lustiges Projekt ;).

[iamthebear]

Laut den Leaks von MLID sollen die Kerne verglichen mit RTL kleiner werden (Richtung Zen4c).

Ich stelle mir das so vor:
.) RTL hat 8 P Cores mit SMT
.) ARL hat 8 P Cores ohne SMT aber mit deutlich mehr IPC (statt SMT werden die E Cores benutzt)
.) Cougar Cove kommt mit 8 Units zu je 2 Cores. Man hat also die Wahl zwischen 8 schnellen P Cores für Gaming (plus die E Cores für die Background Threads bei Spielen) oder bei MT Workloads eben 16 etwas langsamere P Cores plus die E Cores dazu
.) Beat Lake kommt dann mit 4 Units mit maximaler ST Performance, die in bis zu 16 Kerne aufgeteilt werden können.

[mocad_tom]

Sapphire Rapids hat schon 512 Einträge im Reorder Buffer.

Das Out-of-order-Window ist extrem groß und es wird noch größer.

L1 / L2 / L3 Cache bezeichnet man ja ebenfalls als "Cache-Pipeline".
So wie CPU-Pipeline Stages hat, so hat auch die Cache-Pipeline Stages.
Vermutlich wird der Reorder Buffer mit in diese Pipeline mit reingenommen, da es ja jetzt auch schon spekulative Speicherzugriffe und spekulative Schreiboperationen gibt.

Wird der Reorder Buffer größer muss MOESI direkt in den Reorder Buffer weil die Treffer auch wahrscheinlicher werden.

[y33H@]

Lion Cove und Cougar Cove sind Royal Core?

[HOT]

Jo sieht so aus.
Offenbar ist Intel zweigleisig gefahren bis zu einem gewissen Punkt, da das offenbar mit Risiken verbunden war:

Golden Cove -> Raptor Cove -> Redwood Cove -> Panther Cove (gecancelt)

und

.mont -> Lion Cove -> Cougar Cove

Mit Panther Cove stirbt offenbar die alte .cove-Linie, übernehmen scheint das ein 2-Kern-Modul mit Big-Cores, die auf .mont-Technologie basieren. Massiv IPC kann man offenbar durch zusammenschalten der Kerneressourcen erreichen, dann wäre ein Modul mit 2 Kernen auf einen Thread fixiert, der 1. Kern leiht sich also die Ressourcen des 2. Kerns, rented units halt. Gleichzeitig scheinen die Lion Cove auch pro Kern, trotz nicht so überbordender Größe mehr IPC freizugeben als ein Raptor Cove, das sieht man ja an den Performanceprojektionen bei Igor. Zudem könnte es sein, dass die neuen Kerne lange nicht soviel saufen. 30-40% IPC würde ich hier nicht erwarten, das dürften deutlich frühere Prognosen gewesen sein, in denen man von rented units bei Lion Cove ausging, das scheint aber für LC erst mal gestrichen zu sein.

[iamthebear]

So wie ich das verstanden haben ist "Royal Core" eine Reihe an Änderungen, wobei jede Architektur gewisse Aspekte davon bekommt.

Meteor Lake: Multi Die Design aber aber die Kerne selbst bleiben ziemlich gleich

Arrow Lake: Bekommt wohl schon diverse IPC Verbesserungen als auch einen kräftigen Boost der E Cores. Wenn die Performanceprognosen von MLID auch nur annähernd stimmen, dürften diese E Cores nicht mehr viel mit den alten lahmen Gracemont Kernen gemeinsam haben.
Arrow Lake hat jedoch noch keine rentable units. Diese waren weiterhin mit SMT geplant, dieses wurde jedoch aus Zeitgründen gestrichen, da es wohl auf Grund der hohen E Core Leistung nicht mehr wirklich notwendig war und man nicht mehr viel Zeit in eine Technologie investieren wollte, die sowieso ausläuft.

Cougar Cove: Die P Cores bekommen rentable units, E Cores großteils unverändert

Nova Lake: Noch unklar

Beast Lake: Bekommt den die extra Big Cores, E Cores großteils unverändert

[HOT]

Was mit den Darkmonts ist ist bisher total unbekannt, in welchen Produkten der z.B. zum Einsatz kommt. Ich würde eher sagen, dass Intel ab jetzt immer 3 Produkte zur Verfügung stellt in einer Generation, die dafür aber länger halten muss. Das Packaging hätten eh alle Produkte völlig unabhängig von der Kernen bekommen, das spielt hier also keinerlei Rolle. Arrow Lake dürfte nicht nur wegen der E-Cores eine bessere MT-Leistung haben, sondern auch durch die bessere Taktbarkeit im Schnitt für die Lion Cove, die dann einfach pro Kern nicht mehr so durstig sein dürften, also deutlich höherer all-Core-Takt auch unter großer Last.

ARL-S -> ARL-P -> LNL (gleichzeitig Pipecleaner für 20A)
BSL-S -> PNL-P -> NVL (gleichzeitig Pipecleaner für 18A)

oder sowas. Bei Beast Lake hab ich den Verdacht, dass man hier ein extra performantes Die basteln wird und das von Panther Lake (der vor allem mobil zum Einsatz kommen könnte) im Desktop unterstützt werden könnte, Nova Lake könnte beispielsweise auch einfach der Nachfolger von Lunar Lake sein. Beast Lake stelle ich mit aus 8 Doppel-(Cougar)Cove-Modulen vor unterstützt von 16 Darkmont (wie gehabt in 4 Modulen).

MMn war für Lion Cove gleiche Leistung für RWC angedacht + 40% ST IPC wegen rented units. Der ist aber deutlich besser rausgekommen, nur ohne die rented units.

[y33H@]

Lion Cove und Cougar Cove sind Royal Core?Ich hab den Smiley vergessen ^^

[latiose88]

@Hot Welche Achetektur ist denn bitte schön RWC bzw wie heißt das denn ausgeschrieben?

[w0mbat]

RWC = Redwood Cove = die P-Core Architektur in Meteor Lake

Schlag mich nicht, wenn ich falsch liege :ugly:

[Der_Korken]

Gefühlt jedes Mal wenn ich einen der Intel-Threads aufmache lese ich einen neuen Codenamen, den ich noch nicht kannte und in mein sowieso schon sehr flüchtiges Bild von Intels Roadmap nicht einordnen kann :freak:

Dass Intel immer noch ihre "Lake"-Namen durchzieht, obwohl die Kerne schon seit drei Generationen "Cove" heißen, verwirrt mich maximal. Ich vermissen die guten alten Zeiten, als "Sandy Bridge" und "Haswell" sowohl die Architektur als auch die Produkt-Generation bezeichnete :usad:

Kann mir jemand ein zwei, drei Sätzen erklären, was es mit den rentable units auf sich hat? Ich las erstmals davon auf irgendeiner MLID-Slide ohne Erklärung, habe dann extra das Video aufgemacht, aber auch mündlich wurde nicht erklärt was das genau sein soll. Für mich klingt das so, als ob man innerhalb eines Kerns weiterhin 2-way SMT betreibt, aber so, dass alle Ressourcen (ALUs, Buffer, Caches) statisch aufgeteilt werden. Dadurch schirmt man Prozesse nicht nur logisch, sondern auch physisch voneinander ab und erschlägt damit Sicherheitslücken, die aktuell nur durch das Abschalten von SMT komplett verhindert werden können. Der Nachteil ist, dass man a) die Ressourcen nicht mehr so gut auslastet wie wenn alles free for all wäre und b) muss das Betriebssystem aktiv entscheiden, ob ein Kern im 1T-Modus oder im 2T-Modus läuft, weil der Kern "wissen" muss, ob er einem Thread alle Ressourcen zur Verfügung stellt oder nur eine Hälfte. Aber vielleicht bin ich auch komplett auf dem Holzweg.

[ryan]

Lion Cove und Cougar Cove sind Royal Core?


Nein kommt erst später. Sollte eigentlich mit Nova Lake kommen. Ich würde Beast Lake nicht ausschließen, es würde zu den extra big cores passen.

[y33H@]

Ich wollte nur sehen was HOT erzählt ;-)

[HOT]

Ich glaub nicht, dass die später kommen, Cougar Cove werden schon Royal Core sein, sagt ja auch Tom. Lion Cove sind halt der Vorläufer.

[latiose88]

Hm an wann wird es ne komplett Überarbeitung geben oder geht das Refresh von refresh munter weiter mit ein wenig mehr takt und hier und da kleine Verbesserung nur.
Und ja ich verliere bei den ganzen lakes und so auch den Überblick. Ganz ehrlich bei amd hat man das Problem zwar auch etwas aber nicht so Akkut wie bei Intel. So sehe ich das.

[Zossel]

Für mich klingt das so, als ob man innerhalb eines Kerns weiterhin 2-way SMT betreibt, aber so, dass alle Ressourcen (ALUs, Buffer, Caches) statisch aufgeteilt werden. Dadurch schirmt man Prozesse nicht nur logisch, sondern auch physisch voneinander ab und erschlägt damit Sicherheitslücken, die aktuell nur durch das Abschalten von SMT komplett verhindert werden können.

Sidechannels durch das Timing von Caches werden damit wohl nicht vollständig verhindert.

[davidzo]

Kann mir jemand ein zwei, drei Sätzen erklären, was es mit den rentable units auf sich hat?


Das würde ich auch gerne wissen.
Ich habe ein paar Erklärungsversuche dazu im Netz gefunden. Die sind teils abstrus, basieren aber z.T. auf Intel Patentschriften. Andere sind einfach Gegensätzlich zu bisherigen leaks (+40% IPC). Nichts von alledem macht in meinen Augen Sinn.

Aber hier der Vollständigkeit halber die verschiedenen Varianten:


A) Der hybrid core scheduler
Quelle: https://appuals.com/intel-rentable-unit-patent/
Das ist im wesentlichen ein hardware thread Scheduler der P-Cores und E-Cores besser auslasten kann, so dass die Tasks schneller fertig werden.
Fragen:
1. Wieso zum teufel mach man scheduling in HW und fixt nicht den beschissenen Windows scheduler wenn der gerade kacke ist? Ist es nicht einfacher mal mit Microsoft zu reden anstatt komplexe, unfixbare hardware zu entwickeln?
2. Braucht es nicht eine gigantische latenzarme Crossbar wenn man threads hinter dem frontend aus einem Core in den anderen schieben will?
3. Was ist mit den registern caches, pointern etc. die dann alle inkonsistent werden wenn der thread nun im execution part eines anderen cores läuft? Kostet das Verschieben nicht massiv Energie?
4. War der Sinn der E-Cores nicht dass diese effizienter sind? Wenn der Rest des threads aus dem Beispiel dann doch auf den P-Cores zu ende läuft, dann kostet die Idee ja auch mehr Energie.
5. Das ist jetzt imo weder ein Ersatz für SMT, noch scheint es etwas in ST workloads zu bringen. Es scheint nur ein besserer MT Scheduler Ansatz zu sein.
6. Das ist eine Integration von E-Cores in P-Cores. Die wachsen zusammen, mit allen Vor- und Nachteilen. Intel kann dann nicht mehr flexibel die Anzahl der jeweiligen Cores für das Marktsegment bestimmen sondern müsste dafür immer den HW-scheduler anfassen.

B) Bulldozer done right
Ich glaube das ist was du schon beschrieben hast. Wenn man mal von der Scheduling-Ansicht auf die Core-Ebene schaut, dann klingt das sehr nach Bulldozer. Also ein Core mit massiven execution ressourcen und doppeltem Frontend (=rentable core). Die Execution ports sind dann bei MT in zwei Cores aufgeteilt und bei ST nur zu einem. Der Unterschied zu Bulldozer ist dass ein Core nicht nur die gesamte FPU für sich beanspruchen kann, sondern auch alle Integer ports.
1. Das Ganze braucht natürlich wieder angepasste Software um überhaupt zu funktionieren.
2. Wir haben ja bei Bulldozer gesehen wie schwierig execution sharing ist und wieviel power das kostet.
3. Wo sind die Vorteile zu SMT? Klingt für mich nach einer Menge Crossbars und mehr cachelatenzt und damit geringerer 1T IPC sogar nicht als SMT.
4. Ich sehe schon die nächsten Meltdown Security Skandale kommen wenn die CPU threads und caches ohne Wissen des OS mischt.

C) Core Fusion
Viele kleine Cores die sich zu einem großen zusammen schalten können.
Intel hat ja Soft Machines gekauft und die hatten da ein paar Patente zu.
Klingt für mich aber imo zu radikal als wenn man das einfach so machen könnte. Das wäre dann definitiv keine "Cove" oder "Lake" CPU, denn von der Grundarchitektur bleibt nichts mehr übrig.
mehr habe ich dazu aber nicht gefunden: https://www.reddit.com/r/intel/comments/15r11iy/intel_15th_gen_cpus_to_get_rentable_units_why/

D) Vermietete Ports
Man packt eine fette Crossbar an die execution engines aller Cores und hängt dort zusätzliche execution ressources dran die bei threads mit besonders hoher ILP "gemietet" werden können. Eventuell kommen diese ressourcen von Ports die gerade in anderen cores nicht gebraucht werden.
1. WTF, cache Kohärenz?
2. Latenz für die Crossbar?
3. Energie für die Crossbar?
4. Security, thread isolation?
wird hier auch diskutiert: https://www.reddit.com/r/intel/comments/15r11iy/intel_15th_gen_cpus_to_get_rentable_units_why/

[Wuge]

Sofern man die doppelt vorhandenen aber nicht für einen Thread nutzbaren bzw. im Workload gerade nicht benutzten Ressourcen in so einem Riesencore power gaten kann, wäre es schon Vorteilhaft.

Der hardware sheduler verteilt die Last nicht wirklich sondern ermittelt eine (per fimware steuerbare) ideale Lastverteilung und teil die dem OS mit. Die eigentliche Zuordnung der Threads macht immernoch das OS, nicht?

[HOT]

Hm an wann wird es ne komplett Überarbeitung geben oder geht das Refresh von refresh munter weiter mit ein wenig mehr takt und hier und da kleine Verbesserung nur.
Und ja ich verliere bei den ganzen lakes und so auch den Überblick. Ganz ehrlich bei amd hat man das Problem zwar auch etwas aber nicht so Akkut wie bei Intel. So sehe ich das.

So wie es aussieht ist Lion Cove schon was komplett neues.

[latiose88]

OK freut mich endlich kein stromfressende cpu mehr, weil Intel das so weit überarbeitet hat das Leistung wirklich ankommt. Und das dann bei moderaten Stromverbauch (hoffe ich doch), ansonsten bleibt bei mir Intel weiterhin unbeliebt.
Das es auch anderst geht und nicht nur immer stromfressende cpus war ja damals der Fall gewesen. Seid dem 12 und 13 gen und auch 14 gen wird es so sein mit immer mehr takt und immer höheren Stromverbauch dir Leistung herauszuholen. Mag zwar geklappt haben mit den weil es richtig viel takt war, aber wer will schon ein richtig stromfressende CPU wo auch die Temperatur dann nicht mehr gut ist. Klar was will man schon bei 350 Watt oder wenn es noch schlimmer geht Richtung 400 Watt schon erwarten. Das muss ja schließlich auch alles abgekühlt werden. Umsonst geht das nicht von statten. Mit der neuen archetektur wird Intel gewiss dieses Problem in Angriff nehmen, da bin ich mir ja voll sicher.

[HOT]

Ich denke volle E-Cores MT wird weiterhin bei 240W rumdümpeln, auch die AMDs bleiben ja bei der TDP. Die werden immer nutzen, was die Plattform hergibt. Aber die hohen Teillastverbräuche gehen hoffentlich runter und das Teil wird dahingehend effizient, zumindest glaube ich das. ARL-S wird mMn ein gutes, rundes Produkt.

[Nightspider]

AMD kann das derzeit noch nicht machen, da deren Packaging derzeit was die Energieeffizienz angeht noch hinterher hinkt (sieht man auch gut bei Navi31).

*MI300 hust*

Gefühlt jedes Mal wenn ich einen der Intel-Threads aufmache lese ich einen neuen Codenamen, den ich noch nicht kannte und in mein sowieso schon sehr flüchtiges Bild von Intels Roadmap nicht einordnen kann :freak:

Dass Intel immer noch ihre "Lake"-Namen durchzieht, obwohl die Kerne schon seit drei Generationen "Cove" heißen, verwirrt mich maximal.

Oh, bin ich doch nicht der Einzige, dem es so geht. ;D

Vor 10 Jahren waren die Bezeichnungen bei Intel wirklich sinnvoller und besser.

[Wuge]

OK freut mich endlich kein stromfressende cpu mehr, weil Intel das so weit überarbeitet hat das Leistung wirklich ankommt. Und das dann bei moderaten Stromverbauch (hoffe ich doch), ansonsten bleibt bei mir Intel weiterhin unbeliebt.
Das es auch anderst geht und nicht nur immer stromfressende cpus war ja damals der Fall gewesen. Seid dem 12 und 13 gen und auch 14 gen wird es so sein mit immer mehr takt und immer höheren Stromverbauch dir Leistung herauszuholen. Mag zwar geklappt haben mit den weil es richtig viel takt war, aber wer will schon ein richtig stromfressende CPU wo auch die Temperatur dann nicht mehr gut ist. Klar was will man schon bei 350 Watt oder wenn es noch schlimmer geht Richtung 400 Watt schon erwarten. Das muss ja schließlich auch alles abgekühlt werden. Umsonst geht das nicht von statten. Mit der neuen archetektur wird Intel gewiss dieses Problem in Angriff nehmen, da bin ich mir ja voll sicher.

Naja, Leistung pro Watt wird natürlich besser. Aber das was Du beschreibst liegt auch nur daran, dass die aktuellen CPUs geprügelt werden wo es schon nicht mehr effizient ist. 400 Mhz weniger und der Verbrauch ist halbiert. 400W nimmt auch keine aktuelle CPU. Im Normalbetrieb liegen die bei ihrer TDP und wie gesagt, wenn man auf 10% Takt verzichten kann auch sehr Effizient.

[y33H@]

Dass Intel immer noch ihre "Lake"-Namen durchzieht, obwohl die Kerne schon seit drei Generationen "Cove" heißen, verwirrt mich maximal. µArch und SoC sind halt zwei Paar Schuhe - bei AMD haste ja auch Zen 4 und Raphael, so wie bei Intel halt Raptor Cove und Raptor Lake ... find ich jez nicht sooo schwierig :freak:

[latiose88]

@wuge OK dann ist halt die CPU bei 250 Watt anstatt 350 Watt so wie es halt der i9 12900k halt ist. Aber auch dann ist es noch immer nicht effizienter genug aus meiner sicht. Wenn dann wenigtens auf 200 Watt, das darf man bei einer neu Ausrichtung der CPU zumindest schon erwarten. An AMD wird zwar Intel nicht beim Stromverbauch bei allcore ran kommen. Bei idle wird Intel aber weiter hin sparsamer sein als AMD das ist sicher.

[Der_Korken]

µArch und SoC sind halt zwei Paar Schuhe - bei AMD haste ja auch Zen 4 und Raphael, so wie bei Intel halt Raptor Cove und Raptor Lake ... find ich jez nicht sooo schwierig :freak:

Intel hat gefühlt dreimal so viele Codenamen. Im Moment geistern rum: Meteor Lake, Arrow Lake, Panther Lake, Lunar Lake, Nova Lake, Beast Lake, Redwood Cove, Cougar Cove, Lion Cove, Panther Cove(?) (in willkürlicher Reihenfolge). Vor Ewigkeiten stand auch mal Ocean Cove auf einer Roadmap nach Golden Cove, aber der Name ist (wie einige andere auch) wieder verschwunden. Bei AMD sind es ... Zen 5 und Granite Ridge :D. Wenn man Mobile und HEDT noch separat aufführt, wird es bei AMD natürlich auch mehr, aber im Grunde lässt sich mit "Zen 5" alles erschlagen, weil es immer die selben Kerne in verschiedenen Geschmacksrichtungen sind.

Dazu vergibt Intel für Zwischengenerationen noch viele neue Namen, wie z.B. Raptor Cove und davor Willow Cove (jeweils der Vorgänger mit anderer Cache-Größe) und Cypress Cove (reiner Backport von Sunny Cove).

[y33H@]

Intel hat nicht mehr Codenamen als AMD, es sind nur mehr zukünftige Codenamen "öffentlich" bekannt. Ocean Cove war meinem Kenntnisstand nach nie auf einer offiziellen öffentlichen Roadmap verzeichnet.

Bei Intel hast du derzeit Golden Cove sowie Raptor Cove für Client und Server, bei AMD hast du Zen 4 und Zen 4c für Client und Server für die jeweiligen heutigen Topmodelle ...

[robbitop]

µArch und SoC sind halt zwei Paar Schuhe - bei AMD haste ja auch Zen 4 und Raphael, so wie bei Intel halt Raptor Cove und Raptor Lake ... find ich jez nicht sooo schwierig :freak:

Naja bis inkl Skylake hießen die uArchs auch Lake.

[Zossel]

Dazu vergibt Intel für Zwischengenerationen noch viele neue Namen, wie z.B. Raptor Cove und davor Willow Cove (jeweils der Vorgänger mit anderer Cache-Größe) und Cypress Cove (reiner Backport von Sunny Cove).

Wahrscheinlich verwirrt sich Intel damit nur selbst.

[Wuge]

@wuge OK dann ist halt die CPU bei 250 Watt anstatt 350 Watt so wie es halt der i9 12900k halt ist. Aber auch dann ist es noch immer nicht effizienter genug aus meiner sicht. Wenn dann wenigtens auf 200 Watt, das darf man bei einer neu Ausrichtung der CPU zumindest schon erwarten. An AMD wird zwar Intel nicht beim Stromverbauch bei allcore ran kommen. Bei idle wird Intel aber weiter hin sparsamer sein als AMD das ist sicher.

Ein 13900K ist in normalen Workloads bei 100W wenn Du ihn mit 5 Ghz betreibst. Die Dinger laufen serienmäßig in ineffizienten Taktregionen. Ist aber auch okay, wenn ich ne effiziente CPU will, kaufe ich eben nich das Topmodell oder limitiere die TDP im BIOS. Gilt sowohl für Intel wie auch AMD.

[iamthebear]

Red gaming tech meinte in seinem letzten Video, dass die Taktraten Prognosen bei ARL bei nur "low to mid 4GHz" liegen. Kombiniert man das würde ARL auf dem Niveau eines RTL 6GHz landen was sich ziemlich genau mit den Daten von igor deckt.

[Rampage 2]

Red gaming tech meinte in seinem letzten Video, dass die Taktraten Prognosen bei ARL bei nur "low to mid 4GHz" liegen. Kombiniert man das würde ARL auf dem Niveau eines RTL 6GHz landen was sich ziemlich genau mit den Daten von igor deckt.

Hoffentlich nicht:(

Ich bin zwar ein entschiedener Fan von immer höherem IPC, aber "4-4.5 GHz" ist sowas von 2013! ;( (Die Taktkrücke mit dem Codenamen "Haswell")

Dabei hatte ich gehofft, dass Intel auf absehbare Zeit die "AllCore-6GHz"-Marke knackt und noch höher geht:redface:

Also bitte Beides: höhere IPC und höheren Takt=) (oder wenigstens keine Taktregression:wink:)

R2

[latiose88]

Aber mit höheren Takt würde es auch mehr Stromverbrauch bedeuten.Beides wird denke ich mal schwierig werden oder denkst du das kann man ausgleichen in dem dann trotz höheren Takt der Stromverbrauch gleich oder auch sogar leicht sinken kann?

[HOT]

Vielleicht höherer Takt dann im Refresh in 20A und später dann bei Cougar Cove.

[mocad_tom]

Angenommen du schickst dein A-Team los und sagst:

Hallo die absolut oberste Grenze von allen unseren zukünftigen Prozessen bleibt immer und immer 5.5GHz.

Und wir brauchen eine Pipeline, die soweit modernisiert wurde, dass wir die nächsten 5 Jahre gut damit fahren können.

Dann geht man her und überlegt sich:
- weniger Pipelinestufen (und damit komplexere Pipelinstufen)
- einen breiteren Kern

Dann muss man in einer Piplinestufe einen längeren FO4 aushalten.

https://www.ece.ucdavis.edu/~bbaas/116/docs/paper.harris.FO4.pdf

Innerhalb eines Chips reisen wir mit Lichtgeschwindigkeit.
Erste Chips waren "man legt spannung an Beinchen an und erhält dann Spannung an anderen Beinchen", der Ansatz war endlich und man hat Pipelining eingeführt. Also man hat eine Stufe, die macht bestimmte arbeit, die ist fertig, sie legt ihre Sachen am Übergabepunkt ab und der nächste Takt im Prozessor beginnt.

Wenn ich jetzt weiß ich werde nie 10GHz erreichen, dann muss ich mir alle 5 Jahre überlegen, wie ich meine Pipelinestufen gestalte und was ich da drin machen will.

Z.B. ist man der Anzahl der Stufen vom Prescott wieder runter.
https://www.anandtech.com/show/1230/8
Trotzdem war das eine coole Zeit, weil man mal so richtig hinter die Kulissen kucken konnte und den Leuten beim Fehlermanagement zusehen konnte.

Wo wir gerade mal dabei sind - Lisa Su war Mitarchitektin beim Cell Broadband Processor:
https://www.anandtech.com/show/1647/8

Die haben sich auch sehr viele Gedanken über Pipelining gemacht.

Das Grundkonzept von Arrow Lake ist so aufgesetzte, dass es einen hohen IPC schafft und dann mit dem nächsten Shrink wieder einen höheren Takt (das reultiert aus Lichtgeschwindigkeit und wieviel kann ich einer Pipelinestufe zumuten).

Man plant mit zukünftigen voraussagen, was der Prozess in 5 Jahren hergeben könnte.

[latiose88]

Wow ja interessant. Wird durch das Intel die 6 GHz allcore halten können bzw erreichen oder nicht dieser takt bei den cpus, das ist halt ne sehr gute frage. Ich brauche den extra takt sehr sogar.

[Leonidas]

MLID: Arrow Lake ohne HyperThreading und mit Refresh-Generation
https://www.3dcenter.org/news/geruechtekueche-arrow-lake-ohne-hyperthreading-und-mit-refresh-generation-da-panther-lake-nur-f
https://www.youtube.com/watch?v=FrS5tJ6mfkg

[ryan]

Intel Arrow Lake-S Desktop CPUs With 24 Cores Feature 125W PL1, 177W PL2 & 333W PL4 Power Limits On Unlocked SKUs
https://wccftech.com/intel-arrow-lake-s-power-limits-125w-pl1-177w-pl2-333w-pl4-24-core-unlocked-cpu/


Wäre deutlich unter der bisherigen PL2.

[reaperrr]

https://wccftech.com/intel-arrow-lake-s-power-limits-125w-pl1-177w-pl2-333w-pl4-24-core-unlocked-cpu/


Wäre deutlich unter der bisherigen PL2.
Bin gespannt, was das in der Praxis bedeutet.

Gibt da alle möglichen Szenarien:

- E-Kerne in 3nm deutlich effizienter.
- P-Kerne werden oberhalb von 180W so heiß, dass es mit normaler Luftkühlung schwierig wird.
- IPC-Verbesserungen sowohl bei P-Cores als auch E-Cores so hoch, dass Intel davon ausgeht, dass 177W PL2 reichen werden, um Zen5 zu schlagen.
- Mehr Reserve nach oben für potentielle, teurere KS-Modelle.

[ryan]

delete falscher Thread

[dildo4u]

Laut der Roadmap ist Arrow Lake HX Mobile 2025 schätze mal Desktop kommt nicht früher.


https://videocardz.com/newz/next-gen-amd-intel-and-qualcomm-mobile-cpu-roadmaps-showcase-whats-actually-new

[HOT]

Desktop wird noch in 24 kommen. Intel hat ja schon bestätigt, dass jedes Jahr eine Generation kommt, wenn man keine hat, bastelt man sich halt eine als Refresh.
LNL wird zum Jahreswechel 24/25 kommen, weil Notebook, wie jetzt MTL, vielleicht gibts auch noch nen MTL Refresh zusätzlich, ARL-H(X) wird etwas später als LNL kommen und ARL-S noch vor Jahreswechsel für Desktop. Das gleiche Spiel wiederholt sich dann Ende 25 in 20A: ARL-R-S kommt Ende 25, PTL zum Jahreswechsel und ARL-P dann Anfang 26, ARL-R-H(X) etwas später. Intel wird seine Launchzeiträume jetzt einhalten, weil man begriffen hat, dass für die Marktteilnehmer nichts wichtiger ist.

Also grob:

Raptor Cove/Redwood Cove-Generation
Okt. 23 -> RPL-R
Okt. 23 -> MTL-Vorstellung, Jan24 MTL-Lauch
Anfang 24 -> RPL-R-H(X)-Launch

Lion Cove-Generation
Q4 24 -> ARL-S (N3)
Q4 24 -> LNL (N3) Vorstellung (MTL-R?), Jan25 Launch
Anfang 25 -> ARL-H(X) (N3)

Lion Cove+ Generation
Q4 25 -> ARL-R-S (20A)
Q4 25 -> PTL (20A) und ARL-P (20A) Vorstellung, Jan 26 Launch
Anfang 26 -> ARL-R-H(X) (20A)

Zum Jahreswechsel 26/27 dann Nove Lake und Cougar Cove in 18A.

[ryan]

Laut der Roadmap ist Arrow Lake HX Mobile 2025 schätze mal Desktop kommt nicht früher.


https://videocardz.com/newz/next-gen-amd-intel-and-qualcomm-mobile-cpu-roadmaps-showcase-whats-actually-new


Die HX kommen immer später. i9-13900HX gab es in Q1 23, das Desktop Modell in Q4 22. Interessant, dass ARL-H für Ende 2024 geplant ist. Ich hätte eher mit Anfang 2025 gerechnet, wobei das trotzdem so kommen könnte.

[HOT]

Intel Roadmaps zeigen nicht den Launch, sondern den Produktionsbeginn. Das Ding kommt auch in kaufbaren Produkten erst 25.

Interessanter ist, dass der Massenmarkt auch über 25 hinweg mit RPL-R bedient wird.

[ryan]

Intel Roadmaps zeigen nicht den Launch, sondern den Produktionsbeginn. Das Ding kommt auch 25.


Die Roadmap auf videocardz ist eine launch Roadmap. Und natürlich gibt es auch Intel Roadmaps, die den launch zeigen.

[HOT]

Intel verkauft aber keine Notebooks sondern Prozessoren an Hersteller von Notebooks. Da kommt nix 24, genausowenig wie du ein MTL-Notebook noch 23 sehen wirst.

[davidzo]

Die Roadmap auf videocardz ist eine launch Roadmap. Und natürlich gibt es auch Intel Roadmaps, die den launch zeigen.

Wie kommst du darauf?
Roadmaps für Endkunden hätten wohl eher den Plattformnamen und Marketingnamen drauf. Sowas wie "Intel® Core™ i9 Prozessoren der 15. Generation" etc.
Ich glaube das ist eher eine Partner roadmap, also Verfügbarkeit für partner.
Bei Mobilplattformen liegen aber gerne mal 6 Monate zwischen shipping to customers(OEM partners) und der Verfügbarkeit für Endkunden. Intel war da früher zwar schon vorbildlich im Gegensatz zu AMD und hatte meistens einige Plattformen zum Start schon bereit, aber das hat auch nachgelassen in letzter Zeit.
Afaik hat Intel gar keine Roadmaps für Endkunden im Mobilbereich, da man keine eigene Endkundenhardware anbietet spätestens seit der Einstellung der NUC Abteilung.

[iamthebear]

Bis das gesamte Portfolio eines Notebookherstellers umgestellt ist dauert es schon einige Zeit, vor allem bei neuen Plattformen mit einigen Konzeptänderungen, die man z.B. beim Kühlerdesign beachten muss. Die machen auch nicht alle Modelle auf einmal.

Wenn ich mir die lieferbaren Modelle auf Geizhals ansehe gibt es z.B. über 4 Mal so viel so viele Tiger Lake Modelle wie Zen4.

[ryan]

Intel verkauft aber keine Notebooks sondern Prozessoren an Hersteller von Notebooks. Da kommt nix 24, genausowenig wie du ein MTL-Notebook noch 23 sehen wirst.


Die Prozessoren werden 2-4 Monate vor dem launch bereits produziert und dann eben an OEMs ausgeliefert. In Oregon wird Meteor Lake-H seit August produziert und in Irland seit September. Ich rede vom launch, der bereits für Ende 2024 geplant ist laut dieser Roadmap. Meteor Lake-H und Arrow Lake-H liegen exakt 1 Jahren auseinander in der Roadmap, ergo Ende 2024.


Wie kommst du darauf?
Roadmaps für Endkunden hätten wohl eher den Plattformnamen und Marketingnamen drauf. Sowas wie "Intel® Core™ i9 Prozessoren der 15. Generation" etc.



Weil das eine kompilierte Roadmap ist, die ist ja nicht von Intel direkt, sondern von Golden Pig Upgrade.

[iamthebear]

Das mag alles sein, dass Intel da schon fleißig produziert. Es wird vermutlich in Jänner schon der eine oder andere OEM stolz sein erstes Testgerät ausstellen aber bis man das Modell seiner jeweiligen Lieblingsserie (Latitudes, Thinkpads, Elitebooks usw) in der passenden Größe dann auch wirklich geliefert bekommt vergeht mindestens noch einmal ein halbes Jahr. Alder Lake war irgendwann Ende 2022 flächendeckend verfügbar.

[ryan]

Das mag alles sein, dass Intel da schon fleißig produziert. Es wird vermutlich in Jänner schon der eine oder andere OEM stolz sein erstes Testgerät ausstellen aber bis man das Modell seiner jeweiligen Lieblingsserie (Latitudes, Thinkpads, Elitebooks usw) in der passenden Größe dann auch wirklich geliefert bekommt vergeht mindestens noch einmal ein halbes Jahr. Alder Lake war irgendwann Ende 2022 flächendeckend verfügbar.



Das liegt aber nicht an Intel. Was ist dein Vorschlag? Den launch ein halbes Jahr nach hinten verlegen? Dann bremst du aber all diejenigen aus, die bereits Geräte liefern könnten oder wollten. Es wird immer so sein bei einem Notebook CPU launch, dass die Auswahl stetig ansteigt mit der Zeit.

Nach den Maßstäben müsste AMD im übrigen den launch 1 Jahr nach hinten verlegen und eine flächendeckende Verfügbarkeit würde es mit deinem Maßstab nie geben. Bei Intel geht der ramp verhältnismäßig schnell über die Bühne. Ich wäre mir da nicht so sicher mit deiner Annahme, es würde bis Anfang Januar nur die ersten Testgeräte geben. Massenfertigung im großen Stil läuft seit letzten Monat.



Laptops equipped with the next-generation Core processor, Core Ultra (Meteor Lake), which Intel officially unveiled at the 'Intel Innovation' event in mid-September, are expected to be released in large numbers in markets around the world, including Korea, as early as the end of this year.

However, according to officials from several PC manufacturers, these companies have already completed the design of hardware such as the motherboard and external design based on the Core Ultra processor prototype supplied by Intel. Only software and driver optimization remains for the next two months.

Rather, the biggest factor affecting release time appears to be software and driver optimization. Another manufacturer official explained, “Over the next two months, the key will be software optimization using the NPU built into the SOC tile along with drivers related to the Arc graphics chipset, which will be built for the first time in the Core Ultra.”
https://zdnet.co.kr/view/?no=20230929213515

[Leonidas]

Intel hat das eigentlich ganz gut im Griff. Im Frühjahr hat man ein breites Portfolio. Sicherlich ist noch nicht jedes Gerät ersetzt, aber die Auswahl ist dann schon da. Spätestens mit der Computex ist man vollzählig. Danach wollen die Notebook-Hersteller erstmal verkaufen - und sie wissen ja auch, das nächsten Jahreswechsel schon die nächste Gen droht.

Wer weit dahinter zurückliegt, ist leider AMD. Die stellen zur CES vor und sind vielleicht ein Jahr später dann real in der Breite präsent.

[HOT]

AMD Hat halt keine echten Releasezyklen. Man versucht da zwar sowas zu etablieren, aber dann gibts hier Verzögerungen, da Engpässe... das läuft (noch) nicht.

Im Gegensatz zu Intel stellt AMD eigentlich zur CES die APU vor und bisher hat es oft bis zum Sommer gedauert, bis das erste Produkt am Markt war, das ist viel zu lange.
Wahrscheinlich ist das auch der Grund, warum AMD soviel refresht. Man hat Produkte schnell zur Verfügung und muss die neuen APUs nicht sofort in großen, schwer kalkulierbaren Mengen zur Verfügung haben.


Edit:
https://forums.anandtech.com/threads/intel-meteor-arrow-lunar-panther-lakes-discussion-threads.2606448/page-105#post-41074139
ARL ist offenbar wirklich nur 5% schneller in ST als RPL. Stark mehr IPC aber stark weniger Takt dürfte sich hier erhärten, wie es aussieht. Igors Projektionen bewahrheiten sich also offenbar. Aber die e-Cores müssen der Knaller sein bei 15% mehr Performance bei kein SMT mehr ;).

[ryan]

Edit:
https://forums.anandtech.com/threads/intel-meteor-arrow-lunar-panther-lakes-discussion-threads.2606448/page-105#post-41074139
ARL ist offenbar wirklich nur 5% schneller in ST als RPL. Stark mehr IPC aber stark weniger Takt dürfte sich hier erhärten, wie es aussieht. Igors Projektionen bewahrheiten sich also offenbar. Aber die e-Cores müssen der Knaller sein bei 15% mehr Performance bei kein SMT mehr ;).


Bezüglich dem neuen slide:

That slide is from the March deck and was removed in July. Numbers are higher now


Geschützter Account, Link kann ich nicht geben. Die Igorslab Folie könnte neuer sein, da waren es ja etwa 10% ST und 16-20% MT in Geekbench.

[HOT]

Ein Core Ultra 9 2900 dürfte aber nach diesen ganzen Einschätzungen so 5-10% mehr Performance als ein 14900k ST haben und 15-20% MT. Das ist eben weit entfernt von den frühen Einschätzungen, man könnte das als solide Steigerung sehen. Dafür verbraucht das Teil offenbar deutlich weniger Strom, was auch ein Fortschritt ist.

[Edgecrusher86]

Ja, es wären wohl nochmal leicht 20% MT mit SMT der P-Cores gewesen - was im Umkehrschluss entsprechend Effizienz gekostet hätte. So scheint die Mehrleistung ja mit gleichzeitig 30% höherer Effizienz einher zu gehen - wenn man die PLs vergleicht.
Die Taktraten dürften wohl ähnlich ausfallen wie bei Alder und Meteor-Lake, sprich maximal etwas über 5 GHz.

Ich bin ja mal gespannt, ob es nicht auch Gaming Szenarien geben wird, wo der alte Raptor(-Refresh) dank SMT sich vielleicht auch gar mal mit etwa 10% oder mehr wird absetzen können.

[reaperrr]

Die Taktraten dürften wohl ähnlich ausfallen wie bei Alder und Meteor-Lake, sprich maximal etwas über 5 GHz.
Da wäre ich noch skeptisch.

Viel fetterer P-Kern, was Transistorzahl angeht, und soll wohl hauptsächlich in TSMC N3B gefertigt werden.
Grundsätzlich sind TSMC's Prozesse, vor allem die ersten Iterationen, nicht so stark auf maximale Performance/Taktraten optimiert wie das z.B. bei der aktuellsten Variante von Intel7 der Fall sein dürfte.

Wenn trotz 30-40% höherer IPC nur 5-10% mehr ST-Leistung erreicht werden, spricht das für Taktraten im Bereich von 4,5 GHz, da wäre es schon ein riesiger Erfolg, wenn man im finalen Silizium glatte 5 GHz SC-Turbo erreichen sollte.
Und ich rede von der Desktop-Version, MTL erreicht seine Taktraten ja in mobilen TDPs.

Es ist auch verdächtig, dass noch ein PL4 für über 300W kommen soll. Spricht nicht unbedingt dafür, dass man bei Intel fest damit rechnet, in PL2 ADL-Taktraten zu erreichen.

[HOT]

Jo würd ich auch sagen. An der Taktschraube wird man dann bei 20A beim Refresh drehen können.

[iamthebear]

Das liegt aber nicht an Intel. Was ist dein Vorschlag? Den launch ein halbes Jahr nach hinten verlegen? Dann bremst du aber all diejenigen aus, die bereits Geräte liefern könnten oder wollten. Es wird immer so sein bei einem Notebook CPU launch, dass die Auswahl stetig ansteigt mit der Zeit.

Ich habe ja nicht gesagt, dass die Strategie falsch ist. Ich bin doch froh wenn die Notebooks, die ich zum Arbeiten kaufe einigermaßen ausgereift sind und nicht so verbugged wie so manches DIY Mainboard beim Launch.

Man sollte sich nur im Klaren sein, dass außerhalb des DIY Bereichs das Launchdatum von CPUs nicht mit der breiten Verfügbarkeit an Endkunden gleich setzen darf.

Intel hat das eigentlich ganz gut im Griff. Im Frühjahr hat man ein breites Portfolio. Sicherlich ist noch nicht jedes Gerät ersetzt, aber die Auswahl ist dann schon da. Spätestens mit der Computex ist man vollzählig. Danach wollen die Notebook-Hersteller erstmal verkaufen - und sie wissen ja auch, das nächsten Jahreswechsel schon die nächste Gen droht.

Wenn man nur das Ziel hat irgendein x beliebiges MTL Gerät zu kaufen, dann mag das stimmen aber da bin ich zu anspruchsvoll dafür ;D
Ich habe im Normalfall meine Modellreihen, die über die Generationen weg ein gutes Preis/Leistung/Qualitätsverhältnis bieten. Früher waren das mal die Latitudes von Dell, aktuell bin ich nach ein paar Umwegen bei den Lenovo Thinkbooks gelandet.

Wer weit dahinter zurückliegt, ist leider AMD. Die stellen zur CES vor und sind vielleicht ein Jahr später dann real in der Breite präsent.

AMD hat immer noch ziemliche Schwierigkeiten die OEMs dazu zu überreden die eigenen Produkte zu verwenden.


https://forums.anandtech.com/threads/intel-meteor-arrow-lunar-panther-lakes-discussion-threads.2606448/page-105#post-41074139
ARL ist offenbar wirklich nur 5% schneller in ST als RPL. Stark mehr IPC aber stark weniger Takt dürfte sich hier erhärten, wie es aussieht. Igors Projektionen bewahrheiten sich also offenbar. Aber die e-Cores müssen der Knaller sein bei 15% mehr Performance bei kein SMT mehr ;).

Fassen wir mal die bisherigen Leaks zusammen:
.) MLID sagt +40% IPC aber kein SMT
.) Red Gaming Tech sagt niedrige bis mittlerer 4GHz Bereich und die E Cores sind sehr beindruckend
.) Igor und der neue Leak sagen +5% ST und etwas mehr MT

Das passt eigentlich alles sehr gut zusammen.

Allerdings denke ich, dass die MT etwas überzogen sind, denn hierfür müssten die E Cores ohne SMT schon ca. so schnell wie ADL sein. Daran habe ich meine Zweifel.

Ich denke hier gibt es 4 mögliche Erklärungen:
a) Es wurde bei beiden CPUs mit SMT off getestet
b) Es wurde mit limitierter TDP getestet und ARL verliert bei MT Last prozentuell weniger Takt. Dasselbe hat man ja bei Zen3 vs. Zen4 auch schon gesehen
c) Man hat nicht mit klassischen MT Tests wie Cinebench getestet sondern mit Applikationen, die nicht mehr als 24 Threads verwenden oder speicherlastiger waren und ARL besser skaliert wenn der Ringbus nicht so bremst.
d) Die MT Tests enthalten auch Applikationen, die neue Features wie AVX Befehle oder die neuen AI Beschleuniger nutzen. Theoretisch könnte auch die iGPU mit einfließen wenn z.B. bei Videokonferenzen ein virtueller Hintergrund eingefügt werden soll.

Jo würd ich auch sagen. An der Taktschraube wird man dann bei 20A beim Refresh drehen können.

Ein bisschen sicher aber ich denke, dass der Großteil das Taktverlustes an der Architektur hängt. Man hat Takt gegen IPC und vermutlich höhere Energieeffizienz getauscht. Das muss aber für den Notebookmarkt nicht unbedingt schlecht sein. Apple fährt hier sehr gut damit.
Ob es für den High End Desktop Gamingmarkt viel Sinn ergibt wird sich jedoch zeigen müssen aber das ist umsatzmäßig ein sehr kleiner Markt.

[ryan]

Es wurde mit 253W getestet/simuliert was auch immer. Stand doch im Slide mit dran von igorslab. Die Deaktivierung von SMT macht kein Sinn, dann kann man gleich ganze Kerne deaktivieren wenn es danach geht. SMT gehört bei Raptor Lake mit dazu, kein seriöser Tester wird das später gegen ARL-S deaktivieren. Warum müssen die E Kerne so schnell sein wie ADL, wie rechnest du?

Interessanter wäre die Rechnung, um wie viel Prozent Skymont gegenüber Gracemont zulegen müsste. Im Bereich 20-30% wäre gut möglich, das wäre fast schon eine traditionelle Steigerung für die kleinen Kerne. Crestmont soll ja schon 4-6% zulegen, obwohl das mehr ein refresh ist. Bis auf Airmont und jetzt Crestmont gab es immer riesige IPC Sprünge.

[latiose88]

na hoffen wir mal das es nicht stimmt mit den ohne SMT.
Wenn man nun 5,7 GHZ Allcore vs 4,5 ghz Vergleicht und ohne SMT ,wären aus den 40 % mehr IPC Steigerung am Ende mehrleistung von 5 % mehr. Also viel zu wenig.Damit würde sich Intel keinen Gefallen tuen.
10% weniger Allcore Leistung durch CPU Takt und 25 % weniger Allcore Leistung also Multicore Leistung durch das fehlen von SMT.
Dafür jedoch 100 Watt weniger Stromverbrauch.Ob das reichen würde um die Leute zum Kauf zu Animieren,weil sparsamer als Zen 4 sind die Intel CPUS noch immer nicht.Zumal es ja gegen Zen 5 dann Antritt.
Diese brauchen ja auch 200 Watt und haben mehr Allcore Leistung.Und wenn man etwas Opfert dann kommt man auf 142 Watt.
So gut wird also der Nachfolger nicht ran kommen,aber zumindest in die Richtige Richtung geht es sehr wohl.Da heißt es halt Geduld haben,bei Intel.
Was ich lustig finde,wo bei anderen Forums mit Intels Schublade Klemmt,wenn offen dann packt Intel das einfach mal so oben drauf.Aber das stimmt ja alles nicht,wenn man es genau nimmt.

[iamthebear]

Es wurde mit 253W getestet/simuliert was auch immer. Stand doch im Slide mit dran von igorslab.

Meine Aussage bezog sich auf den letzten Leak bzw. die ganzen Aussagen von MLID etc.
Aber stimmt: Bei igor war kein TDP Limit drin.

Die Deaktivierung von SMT macht kein Sinn, dann kann man gleich ganze Kerne deaktivieren wenn es danach geht. SMT gehört bei Raptor Lake mit dazu, kein seriöser Tester wird das später gegen ARL-S deaktivieren.

Wir wissen nicht wie alt die Prognosen sind. Vielleicht war man damals noch der Meinung, dass man SMT noch rechtzeitig zum Laufen bekommt. Dessen Streichung war glaube ich eher kurzfristig.
Ob SMT ein oder aus ist kommt auch immer auf den Anwendungsfall an bzw. ob man das Sicherheitsrisiko, das damit verbunden ist eingehen will. Im Clientbereich ist es meistens an, im Datacenterbereich mit mehreren Kunden pro physischer Maschine meistens aus. Das war schon vor Meltdown etc. teilweise so

Warum müssen die E Kerne so schnell sein wie ADL, wie rechnest du?

OK mal schnelle Milchmädchenrechnung (basierend auf Cinebench)

13900K:
1 E Core hat eine Performance von 1 (Referenz)
1 P Core hat eine Performance von ca. 1.8 (laut 12900K Computerbase Review, bei Raptor Lake hat sich am Verhältnis wenig geändert)
SMT bringt ca. 40% mehr Performance

Also gesamte MT Performance: 8 * 1.8 * 1.4 + 16 * 1 = 36.16

15900K
1 P Core ist 1.8 * 1.05 = 1.89
MT Performance: 8 * 1.89 + 16 * ECore = 36, 16 * 1.15 = 41.58

Daraus folgt:
16 * ECore = 41.84 - 8 * 1.89 = 26.72
1 ECore = 1.67 (also 67% schneller als Raptor Lake E Cores bzw. nur 7% langsamer als Raptor Lake P Cores bzw. 12% langsamer als ARL P Cores)

Das ist alles sehr unwahrscheinlich.


Das Maximum, das ich mir bei den E Cores vorstellen könnte ist eine Steigerung von 40% wenn Intel einen ähnlichen Ansatz wie AMD mit ihren Dense Cores verfolgt.

Es könnte aber auch gut sein, dass da nicht Cinebench getestet wurde sondern mehr praxisnahe Benchmarks und man sich die MT Performance durch bessere Skalierung wenn Ringbus/L3 Bandbreite nicht so sehr bremsen, man vielleicht auch schnelleren DDR5 supported. Auch gut möglich, dass da einige Spiele getestet wurden, die sowieso nur 8 performancerelevante Threads haben.

[Edgecrusher86]

Es ist auch verdächtig, dass noch ein PL4 für über 300W kommen soll. Spricht nicht unbedingt dafür, dass man bei Intel fest damit rechnet, in PL2 ADL-Taktraten zu erreichen.

Wobei dieses ja 400W aktuell ist. ;)

[ryan]

Wir wissen nicht wie alt die Prognosen sind. Vielleicht war man damals noch der Meinung, dass man SMT noch rechtzeitig zum Laufen bekommt. Dessen Streichung war glaube ich eher kurzfristig.


Die Folie mit den +15% MT ist vom März, die Juli Prognose sieht besser aus. Dass Lion Cove ohne SMT auskommt, ist bereits seit Anfang Juli bekannt gewesen. Daraus kann man schlussfolgern, dass SMT schon in der März Prognose deaktiviert gewesen sein muss, sonst müsste die Juli Prognose erheblich schlechter ausfallen was MT angeht. So kurzfristig kann das nicht gewesen sein.



Wobei dieses ja 400W aktuell ist. ;)


420W um genau zu sein. PL3 und PL4 sind optional und auf default deaktiviert muss man dazusagen.

[Andi_90]

Die Folie mit den +15% MT ist vom März, die Juli Prognose sieht besser aus. Dass Lion Cove ohne SMT auskommt, ist bereits seit Anfang Juli bekannt gewesen. Daraus kann man schlussfolgern, dass SMT schon in der März Prognose deaktiviert gewesen sein muss, sonst müsste die Juli Prognose erheblich schlechter ausfallen was MT angeht. So kurzfristig kann das nicht gewesen sein.


Hast du einen Link zu der July Slide?

[Edgecrusher86]

Achso, ich hatte letztens 400W gesehen - also sogar noch höher. Ja, das hätte man dann bestimmt als PL2 setzen müssen, wäre später ein möglicher 8C/16T + 32c noch in Intel 7 gekommen. :freak:

[ryan]

Hast du einen Link zu der July Slide?


Nein nicht direkt, der ARL-S slide von Igorslab könnte aber vom Juli sein oder jedenfalls aktueller, dort liegen die Werte 5 Prozent über den up to 5% ST und 15% MT (Geekbench SC+MC).

[Andi_90]

Nein nicht direkt, der ARL-S slide von Igorslab könnte aber vom Juli sein oder jedenfalls aktueller, dort liegen die Werte 5 Prozent über den up to 5% ST und 15% MT (Geekbench SC+MC).

Hm ja Geekbench, interresanter wäre hier für SpecInt aber naja.

Dafür das ARL komplett neuer Kern ist sind die jetzigen leaks aber naja mittelmäßig.

Wäre auch interessant wenn Lion Cove kein SMT mehr hat, was das für Granite-Ridge bedeutet. Nur 128C/128T?

[y33H@]

Granite Rapids meinst du vermutlich, der hat Redwood Cove mit SMT2.

[davidzo]

c) Man hat nicht mit klassischen MT Tests wie Cinebench getestet sondern mit Applikationen, die nicht mehr als 24 Threads verwenden oder speicherlastiger waren und ARL besser skaliert wenn der Ringbus nicht so bremst.


Dies.
Cinebench R23 skaliert sagenhaft mit SMT, aber auch keine 40%. +34,5% sind ein sehr hoher wert den nur der 12900K erreicht. Das wird beim 13900K und 14900K wohl eher bei ca. 30% liegen, denn mit steigender Threadanzahl nimmt das scaling ab. Die 16 e-Cores saugen TLP auf so dass die 8 Threads mehr nicht mehr soviel beitragen. Bergamo ist z.B. ohne SMT schneller als mit 256T und sogar als 2P 256C und auch genoa und chagall und castle-peak liegen im MP ratio deutlich unter ihrer waren Kernanzahl. Auf die gesamt-CPU bezogen bringt SMT beim 13900k weniger als 10% (24C/32T) im Anwendungsschnitt. Auf die P-Cores bezogen liegt der Schnitt eher bei +-20% in MT Anwendungen und damit deutlich unter dem Cinebench R23 Gewinn.


d) Die MT Tests enthalten auch Applikationen, die neue Features wie AVX Befehle oder die neuen AI Beschleuniger nutzen. Theoretisch könnte auch die iGPU mit einfließen wenn z.B. bei Videokonferenzen ein virtueller Hintergrund eingefügt werden soll.


Die werden sicher Bfloat16 nutzen, das ist schon seit 2020 in intel CPUs umgesetzt und langsam auch in der freien Wildbahn (AI workloads) zu sehen. Und AVX10 ist das große neue Feature mit den E-Cores. Intel sieht in Zukunft also durchaus Bedarf von AVX-512 auf dem Desktop und natürlich wird das in den Releasetests eine wichtige Rolle spielen.
GPU Workloads halte ich zu weit hergezogen, zumal die geleakten Folien ja schon explizit in "IA performance" (IA=x86) und "gpu performance" aufgeteilt sind.



Ob es für den High End Desktop Gamingmarkt viel Sinn ergibt wird sich jedoch zeigen müssen aber das ist umsatzmäßig ein sehr kleiner Markt.
Ich könnte mir vorstellen dass es durch den fetten L2 den L3 der nicht mehr geshared wird durchweg bessere Speicherlatenzen gibt die in games direkt durchschlagen. In einigen gaming-tests schneidet der 13700k reproduzierbar besser als der 13900k und ks ab. Das wird an den zwei deaktivierten Ringbus Stops liegen. Bei Zen3 und CometLake vs Rocketlake konnte man auch gut sehen dass ein schmaler Core und sogar weniger Takt nicht so ins Gewicht fällt in Spielen wie die L3 Cache Größe und die Gesamt Cache-Latenz. Und hier bekommen wir sogar beides: Einen fetten Core mit sehr viel L2 und schnellem großen L3. Das könnte in Spielen mehr bringen als ein Hochtakt-Design.

[latiose88]

Dies.
Cinebench R23 skaliert sagenhaft mit SMT, aber auch keine 40%. +34,5% sind ein sehr hoher wert den nur der 12900K erreicht. Das wird beim 13900K und 14900K wohl eher bei ca. 30% liegen, denn mit steigender Threadanzahl nimmt das scaling ab. Die 16 e-Cores saugen TLP auf so dass die 8 Threads mehr nicht mehr soviel beitragen.Auf die gesamt-CPU bezogen bringt SMT beim 13900k weniger als 10% (24C/32T) im Anwendungsschnitt. Auf die P-Cores bezogen liegt der Schnitt eher bei +-20% in MT Anwendungen und damit deutlich unter dem Cinebench R23 Gewinn.


Die werden sicher Bfloat16 nutzen, das ist schon seit 2020 in intel CPUs umgesetzt und langsam auch in der freien Wildbahn (AI workloads) zu sehen. Und AVX10 ist das große neue Feature mit den E-Cores. Intel sieht in Zukunft also durchaus Bedarf von AVX-512 auf dem Desktop und natürlich wird das in den Releasetests eine wichtige Rolle spielen.

Ich könnte mir vorstellen dass es durch den fetten L2 den L3 der nicht mehr geshared wird durchweg bessere Speicherlatenzen gibt die in games direkt durchschlagen. In einigen gaming-tests schneidet der 13700k reproduzierbar besser als der 13900k und ks ab. Das wird an den zwei deaktivierten Ringbus Stops liegen. Bei Zen3 und CometLake vs Rocketlake konnte man auch gut sehen dass ein schmaler Core und sogar weniger Takt nicht so ins Gewicht fällt in Spielen wie die L3 Cache Größe und die Gesamt Cache-Latenz. Und hier bekommen wir sogar beides: Einen fetten Core mit sehr viel L2 und schnellem großen L3. Das könnte in Spielen mehr bringen als ein Hochtakt-Design.

1. Abschnitt dazu was drauf geschrieben:

Ja was bringt das oder spielt oder Arbeitet man ständig mit Cinebench?
Und es gibt auch Anwendung die Profitieren locker mit 20-25 % von SMT.So ist das ja nicht.Also bis zu ner gewissen Kern bzw Threads Kernzahl skaliert meine Anwendung genau um so viel nach oben.Ab 20 Kernen wird SMT bzw HT zur Leistungsbremse. Werden also sprich 20 Threads ist so das Ende kann man sagen.Wobei man sagen sollte bis 24 Threads ist das wirklich so.Da ist Intel ja noch ein Stück Entfernt und weil es ja eh nur e Kerne sind,braucht meine Anwendung dennoch HT weil die E kerne so wenig Leistung für meine Anwendung abliefern.Man merkt also schon je nach dem wie man es sieht die Leistungsunterschiede.

2.Abschnitt dazu was drauf geschrieben:
Wow noch mehr AVX,profitere schon mal nicht von AVX 512,das weis ich und ob ich von AVX 2 Profitiere ,müsste ich schauen.Denke nur das es AVX 1 aber sicherlich etwas Steigerung ausmacht,die ich so bisher gespürt hatte.Recht viel mehr Erwarte ich in Zukunft allerdings nicht mehr.Heißt das der Teil bleibt einfach bei mir dann brach.Gibt es neben dem mehr an AVX auch noch was anderes wo ich wirklich davon Profitiere oder wird das neben KI das einzige sein was sich groß bei den neueren CPUS an tut.KI Profiitere ich ebenso 0 davon.Bin gespannt wie es weiter geht.Hoffe das halt die bisherigen EInheiten dann einfach immer noch breiter werden.Will ja was sehen von der Rohleistung.


Der Letzte Abschnitt,also warum immer nur in Games gedacht wird.ALs ob es nur Games auf der Welt gibt.Klar L3 mag da ja profitieren,aber es gibt auch so Anwendung wie ich so Nutze wo der extra L3 Cache keinen Einfluss mehr hat.Ich schreibe von extra L3 bei AMD.Da war der Gewinn an Leistung gleich 0 gewesen.Also die Anwendung scheint nicht mehr von mehr als 64 MB L3 zu Profitieren.Bei L1 und L2 Cache kann ich es aber nicht sagen.Intel hat da halt um einiges mehr an L2 Cache.Gebracht hat es dennoch nicht wirklich viel.Meine Anwendung scheint sich mehr für CPU Takt zu interessieren.Merke ich ja gut.Aber die große Taktsteigerung wird bald ein Ende haben.Dann wird sich zeigen,ob anders wo auch zu Mehrleistung führt.Erwarte bei Zen 5 ebenso keine große Leistungssteigerung.Wenn nun Intel da sehr wenig Allcore Takt nur noch fahren wird,sieht es nicht mehr so gut aus bei Intel.
Ich weis noch als der Takt auf einen bestimmten Level gesenkt wurde,wie stark die Leistung bei Intel abgesackt ist.Nur Intels CPUS ist CPU takt am stärksten Fokosiert.Bei AMD ist das nicht so stark zu sehen.Es gibt auch auf AMD Seite einen gewissen Verlust durch Takt Absenkung.Den meisten hat allerdings bei Intel festgestellt gehabt bei mir.


Nach dem das so ist,Takt scheint also mehr Auswirkung zu haben als der Cache. Ne Anwendung die sehr stark von CPU Takt Profitiert,Profitiert weniger vom Cache.So die befürchtung habe ich.Dann wird die Leistung also geringer Ausfallen und wer weis vielleicht sogar nen Rückgang beim Mulicore Leistung.
Das wäre schlecht wenn es mehr nen downgrade als nen Upgrade wäre.

[davidzo]

Ja was bringt das oder spielt oder Arbeitet man ständig mit Cinebench?
Und es gibt auch Anwendung die Profitieren locker mit 20-25 % von SMT.So ist das ja nicht.


Das ist ja genau der Punkt, dass andere Anwendungen weniger von SMT profitieren als CB R23.
20-25% ist auch komplett unrealistisch beim 13900K. Nur ein Drittel der 24 Kerne hat überhaupt SMT. Sicher, das sind die schnelleren Kerne, aber selbst wenn die eben pro Kern 20% durch SMT drauflegen, ist das am Ende bei der Gesamt-CPU unter 10%.


Also bis zu ner gewissen Kern bzw Threads Kernzahl skaliert meine Anwendung genau um so viel nach oben.Ab 20 Kernen wird SMT bzw HT zur Leistungsbremse. Werden also sprich 20 Threads ist so das Ende kann man sagen.Wobei man sagen sollte bis 24 Threads ist das wirklich so.Da ist Intel ja noch ein Stück Entfernt und weil es ja eh nur e Kerne sind,braucht meine Anwendung dennoch HT weil die E kerne so wenig Leistung für meine Anwendung abliefern.Man merkt also schon je nach dem wie man es sieht die Leistungsunterschiede.

Sag doch mal was ist denn deine Anwendung, wie hast du Tread level parallelism implementiert und wieso endet das dann bei 20Threads? Oder fantasiertst du nur was zusammen?
Für TLP ist es eigentlich egal ob es P-Kerne sind oder E-Kerne. Für SMT ist relevant ob der Code stark von instruction level parallelism profitiert. Nur mit mäßigem ILP und ausreichend hohem TLP bringt SMT einen guten Zugewinn.


Wow noch mehr AVX,profitere schon mal nicht von AVX 512,das weis ich und ob ich von AVX 2 Profitiere ,müsste ich schauen.Denke nur das es AVX 1 aber sicherlich etwas Steigerung ausmacht,die ich so bisher gespürt hatte.Recht viel mehr Erwarte ich in Zukunft allerdings nicht mehr.Heißt das der Teil bleibt einfach bei mir dann brach.Gibt es neben dem mehr an AVX auch noch was anderes wo ich wirklich davon Profitiere oder wird das neben KI das einzige sein was sich groß bei den neueren CPUS an tut.KI Profiitere ich ebenso 0 davon.Bin gespannt wie es weiter geht.Hoffe das halt die bisherigen EInheiten dann einfach immer noch breiter werden.Will ja was sehen von der Rohleistung.

Ich glaube dir ist nicht bewusst wie essentiell AVX2 heutzutage ist.
Haswell hat einen der größten IPC Schübe insbesondere für games gebracht und ist IPC-technisch quasi identisch zu Skylake, der langlebisten x86 gaming CPU-µArch ever. AVX1 CPUs wie Ivybridge-E sind heutzutage weit abgeschlagen, selbst mit mehr Kernen und höherem Takt als Haswell-E.
Auch bei AMD war fullrate AVX2 ein riesiger IPC Schub.Die 2x256bit FPUs statt 2x 128B von Ryzen 3000 sind fast alleine für den gaming-IPC-Zuwachs verantwortlich.

Und ja, AVX512 wird so langsam auch für lowend CPUs zur Pflicht. Sicher wird man da keine state of the art unbiased raytracer drauf laufen lassen und auch Software-Video-Encoder werden da selten drauf laufen. Aber einfache low precision Matrixmultiplikationen schnell und energieeffizienzt im Ram auszuführen gehört im AI Zeitalter einfach zum Basis featureset. Das geht vom Backgound blur, und Audio processing in einer Videokonferenz bis zu Denoising und Objekterkennung im embedded Bereich.

Nimmt man embedded SOC in Autos zum Beispiel. Dort werden immer noch alte Atom CPUs eingesetzt und auch Alderlake-N kann noch kein AVX512. Dabei geht Vehikel und Objekterkennung mit OpenVino mit AVX512 mehr als doppelt so schnell und das selbst auf der AMD Implementation mit 2x 256bit FPUs. GPUs sind da nicht nur aus Kostengründen sondern auch und wegen dem geringen VRAM nicht immer die Antwort. Manchmal ist es besser das einfach direkt im main memory zu machen. Programmierer erwarten in Zukunft einfach dass sie mit akzeptabler performance AI-enhanced Features implementieren können die auch nicht immer der Mittelpunkt der Anwendung sind. Das ist zunehmend auch im embedded- und low-power-Bereich wichtig.


Ich schreibe von extra L3 bei AMD.Da war der Gewinn an Leistung gleich 0 gewesen.Also die Anwendung scheint nicht mehr von mehr als 64 MB L3 zu Profitieren.
Und ich schreibe von besserer Cache-Latenz über allen Stufen. Das ist nicht dasselbe wie die Cache-Größe. Und Intel mit dem wesentlich breiteren Core-Design dahinter kann auch anders von einer besseren Fütterung der fetten Cores profitieren als AMD dies kann.

[Lehdro]

Anwendung wie ich so Nutze wo der extra L3 Cache keinen Einfluss mehr hat.Ich schreibe von extra L3 bei AMD.Da war der Gewinn an Leistung gleich 0 gewesen.Also die Anwendung scheint nicht mehr von mehr als 64 MB L3 zu Profitieren.
Sieh es mal so: Wenn X3D gleichauf mit dem nominell gleichem Nicht-X3D liegt, ist es ein positiver Punkt für den X3D. Denn: Der X3D taktet niedriger und hat höhere Latenzen, wenn er also trotz diesen Nachteilen gleichauf ist, bringt der Cache doch noch etwas. Nämlich zumindest genug um die Nachteile zu kompensieren.

[ryan]

Ich glaube dir ist nicht bewusst wie essentiell AVX2 heutzutage ist.
Haswell hat einen der größten IPC Schübe insbesondere für games gebracht und ist IPC-technisch quasi identisch zu Skylake, der langlebisten x86 gaming CPU-µArch ever.


Games haben viele Jahre überhaupt kein AVX unterstützt und wenn doch, hat es null Performance gebracht. Also wo soll Haswell damals durch AVX profitiert haben. Haswell ging später komplett ein gegen Skylake mit gutem DDR4 Speicher. Tatsächlich waren die gaming Steigerungen über SB/IVB überschaubar.


Dabei geht Vehikel und Objekterkennung mit OpenVino mit AVX512 mehr als doppelt so schnell und das selbst auf der AMD Implementation mit 2x 256bit FPUs.


Und wie viel kommt durch die breiteren Register und wie viel vom AVX512 Feature set? AVX512 hat keine große Zukunft für Client, weil Intel wohl ab Arrow Lake AVX10.2 support bringt. Also AVX512 mit 128/256 bit Registern, optional natürlich auch 512 bit für CPUs die es unterstützen.

[davidzo]

Games haben viele Jahre überhaupt kein AVX unterstützt und wenn doch, hat es null Performance gebracht. Also wo soll Haswell damals durch AVX profitiert haben. Haswell ging später komplett ein gegen Skylake mit gutem DDR4 Speicher. Tatsächlich waren die gaming Steigerungen über SB/IVB überschaubar.


Ja, das hat sich in der Tat erst etwas später gezeigt. Aber zu Ryzen 3000 Launch waren die Vorteile von AVX2 schon erheblich.

Ich habe noch eine alte x79 Plattform mit 1650v2 am laufen (6C/12T 12mb cache) auf 4.2Ghz allcore. Die stinkt selbst gegen 1231v3 (4c/8T 3.4/3.8Ghz) in halbwegs modernen Spielen.

Siehe hier, 4,3Ghz ohne AVX2 vs 3.4Ghz mit AVX und trotzdem 10-20% mehr FPS: https://www.youtube.com/watch?v=gNSXMD2GIRg&t=293s




Und wie viel kommt durch die breiteren Register und wie viel vom AVX512 Feature set? AVX512 hat keine große Zukunft für Client, weil Intel wohl ab Arrow Lake AVX10.2 support bringt. Also AVX512 mit 128/256 bit Registern, optional natürlich auch 512 bit für CPUs die es unterstützen.

Wie du es nennst ist doch egal. AVX10.2 ist auch nur eine neue Version von AVX512. Ich verwende das oben im text jedenfalls synonym, also mit AVX512 ist AVX10.2 gemeint und auch AMDs AVX512 Implementierung.

AVX512 ist ja auch kein festes Featureset sondern eine Sammelbezeichnung für bis dato mindestens sieben verschiedene Sets an Vektorbefehlen, die von Intel auch sehr uneinheitlich unterstützt werden. Mit AVX10.2 gibt es halt eine achte Version und einen Name-change für mehr Marketing-Power und hoffentlich eine etwas verlässlichere klare Unterstützung von Intel. Als relevant für die Masse haben sich for allem bfloat16 und VNNI herausgestellt, alles andere ist praktisch Legacy oder eben für einzelne Softwarenischen wie VAES. Intel zieht mit AVX10.2 unterstützung praktisch wieder gleich mit AMD Zen4, der die wesentlichen AVX512 Benefits schon jetzt im Consumer-Bereich anbietet.

[ryan]

Ja, das hat sich in der Tat erst etwas später gezeigt. Aber zu Ryzen 3000 Launch waren die Vorteile von AVX2 schon erheblich.


Also mir ist dazu keine Quelle bekannt, wo AVX2 in Spielen Vorteile eingebracht hat und erheblich schon gar nicht. Kannst du Quellen benennen?




Siehe hier, 4,3Ghz ohne AVX2 vs 3.4Ghz mit AVX und trotzdem 10-20% mehr FPS: https://www.youtube.com/watch?v=gNSXMD2GIRg&t=293s



Wo siehst du dort einen AVX An/Aus Vergleich? Und wieso unterschiedliche CPUs? Für einen sauberen Vergleich ohne andere Architektur Einflüsse braucht es die gleiche CPU einmal mit und einmal ohne AVX. Du vergleichst unterschiedliche Achitekturen mit unterschiedlicher Kernanzahl. Das funktioniert so nicht, wenn du den Einfluss von AVX zeigen willst. Läuft das Spiel überhaupt auf AVX?

[davidzo]

Wo siehst du dort einen AVX An/Aus Vergleich? Und wieso unterschiedliche CPUs? Für einen sauberen Vergleich ohne andere Architektur Einflüsse braucht es die gleiche CPU einmal mit und einmal ohne AVX. Du vergleichst unterschiedliche Achitekturen mit unterschiedlicher Kernanzahl. Das funktioniert so nicht, wenn du den Einfluss von AVX zeigen willst. Läuft das Spiel überhaupt auf AVX?

Den wird dir keiner liefern aus dem Grund den du schon genannt hast: Zum Launch von Haswell war AVX2 noch schlecht vertreten. Und Featuretests sechs, acht oder mittlerweile 10 Jahre nach Erscheinen bzw. Alterungstests gibt es leider viel zu selten (obwohl ich solchen Content immer mega spannend finde!). Mittlerweile steckt AVX2 aber durch DirectXMath und neue Visual Studio Varianten in vielen Gameengines ohne dass die Spielentwickler sich dessen bewusst sein müssen. Beim Shadercompiling hilft es massiv, aber auch auf die Frametimes kann es einen Einfluss haben:
https://devblogs.microsoft.com/cppblog/game-performance-and-compilation-time-improvements-in-visual-studio-2019/
Der Speedup wurde leider nur auf einem Zen1 mit nur halfrate AVX2 demonstriert. Auf einer CPU mit echter 256bit FPU kann nochmal deutlich mehr rausspringen.


Zusätzlich gibt es viele sekundäre Hinweise. Zum Haswell Launch lag die Gameperformance des 4770K wenn überhaupt nur im einstelligen Prozenbereich über dem 3770k, selbst im cpulimit,800x600. Mittlerweile ist es locker zweistellig. Die Performancedifferenz ist also seit Haswell-Launch massiv angewachsen. Und auch Zen1 mit lediglich 2-Cycle AVX2 stinkt trotz besserem Multicore support in Spielen gegenüber Skylake basierten CPUs mehr ab als noch zum Launch.
In Schnäppchen gaming hardware und Xeon-tuning Channels ist es gut bekannt dass man um pre AVX2 CPUs mittlerweile besser einen Bogen macht. gerade die min-FPS sind häufig katastrophal.

Sicher ist es auch nicht hilfreich dass viele retro gaming Emulatoren gebrauch von AVX2 machen und zum Beispiel auch UE4 (Singlethreaded) mal eben um 50% einbrechen kann wenn AVX2 nicht vorhanden ist. Intel hat Dev Beispiele von Occlusion culling in UE4 das mit AVX2 500% so schnell ist wie ohne culling und 400% schneller als standardmäßiges frustrum culling.

Und natürlich gibt es auch Spiele die einfach nicht starten ohne AVX2, z.B. uncharted.

[latiose88]

Das ist ja genau der Punkt, dass andere Anwendungen weniger von SMT profitieren als CB R23.
20-25% ist auch komplett unrealistisch beim 13900K. Nur ein Drittel der 24 Kerne hat überhaupt SMT. Sicher, das sind die schnelleren Kerne, aber selbst wenn die eben pro Kern 20% durch SMT drauflegen, ist das am Ende bei der Gesamt-CPU unter 10%.


Also bei meinem Ryzen 9 5950x macht ohne SMT gleich 15% aus.ALso wenig ist das nicht wenn das fehlt.Das senkt ganz schön die Leistung.Das ist dann fast auf Zen 1 Level dann wenn SMT abgeschaltet ist.So schlecht ist dann die CPU.Ist nicht ohne.


Sag doch mal was ist denn deine Anwendung, wie hast du Tread level parallelism implementiert und wieso endet das dann bei 20Threads? Oder fantasiertst du nur was zusammen?
Für TLP ist es eigentlich egal ob es P-Kerne sind oder E-Kerne. Für SMT ist relevant ob der Code stark von instruction level parallelism profitiert. Nur mit mäßigem ILP und ausreichend hohem TLP bringt SMT einen guten Zugewinn.


Ich weis das weil ich unterschiedliche CPUS getestet hatte und selbst einen 18 Kerner.Er war mit der Highend CPU schlecht Ausgelastet,mit Zen 2 bzw Zen 3 16 Kerner war sehr gut ausgelastet und hatte auch mehr Leistung gehabt.
Auch einen 22 Kerner einen Xeon hatte ich zwar als Vorserien Modell was ich dann wieder Verkauft hatte.Er lief ohne HT viel schneller.Das war der Moment wo ich erkannt hatte das meine Software nicht so Optimal die CPU Ausgelastet hatte.Auch die ganzen Threadripper die ich dank andere selbst meine Software testen durfte bestätigten das Ergebnis.Wenn ein 32 Kerner nur trotz SMT abschalten 75 % und mit SMT 35 % Ausgelastet wird und selbst bei der ersten Threadripper Generation bei der Highend System machte merkwürdige Verhalten.SMT aus brachte Mehrleistung.Die Aktuelle Threadripper mit 24 Kernen ist so gut Optimiert das man SMT an lassen kann ohne Leistung zu verlieren.Je nach dem ob an oder aus erhöht oder senkt sich die Auslastung der CPU. Bin halt einer der die CPU voll ausfahren wollte,es aber nicht geschafft hatte.Erst als mehr als 2 gleiche Programme Parallel gearbeitet hatten ging es richtig los.Ab 4 gleichzeitig sinkt jedoch auch bei einem 32 Kerner die Leistung nach unten.Hier scheint also entweder die CPU nicht mitzuspielen oder aber die Software macht da ein Strich durch die Rechnung.Mehr als 32 Kerne habe ich aber bisher nicht getestet gehabt.Sah ich bei den Ergebnissen aber auch nicht mehr als nötig an,weil besser wird das Ergebnis nicht.Und 4 gleichzeitig ist unrealistisch weil so viel auf einmal schaffe ich auch nicht.Bin ja kein Krake oder sowas der wo mehr als 1 Bildschirm hat.Dann würde es jedoch gehen. Da es aber keinen 22 Kerner mehr als Aktuelle CPU gibt,spielt dies jedoch keine Rolle mehr.Ich teste weiter weil suche für die Zukunft nen Nachfolger für meinen Ryzen 9 5950x.Bisher steht jedoch aufgrund weil Intel so hohen Stromverbrauch hat nicht auf meine haben wollen Liste.Kann sich jedoch wenn Intel hier deutlich sparsamer wird,jedoch wieder ändern.Mein Favorit ist bisher Zen 5.Zen 4 ist mir zu wenig.Sollte jedoch die IPC Steigerung unterhalb von Zen 4 sein,dann wird es unineressant.Zen 4 gab es 7 % mehr IPC bei meiner Anwendung.AVX1 und 2 an vs aus ergab bei mir 7 % mehrleistung.Takt ergab wenn man es so von 3,9 auf 4,8 Ghz erhöht weitere 16 % mehrleistung. Ram Takt von DDR5 4800 auf 6000 ganze 2 %.Alles bis auf das geht nicht mehr selbst testen dürfen.Mehr konnte ich aus dem Ryzen 9 7950x wo ich testen durfte leider nicht mehr herausholen.In der Hinsicht mit 142 Watt ging beim x3d einfach nicht mehr.Er hatte keine normale gehabt aber das durfte ich beim anderen Testen.Nen Extra 3d Cache brachte bei mir nix.Dafür war ohne undervolten die CPU auch schon bei 142 Watt gewesen.


Ich glaube dir ist nicht bewusst wie essentiell AVX2 heutzutage ist.
Haswell hat einen der größten IPC Schübe insbesondere für games gebracht und ist IPC-technisch quasi identisch zu Skylake, der langlebisten x86 gaming CPU-µArch ever. AVX1 CPUs wie Ivybridge-E sind heutzutage weit abgeschlagen, selbst mit mehr Kernen und höherem Takt als Haswell-E.
Auch bei AMD war fullrate AVX2 ein riesiger IPC Schub.Die 2x256bit FPUs statt 2x 128B von Ryzen 3000 sind fast alleine für den gaming-IPC-Zuwachs verantwortlich.


Mir egal ich bin kein großer Zocker.Du schreibst mit einem der mehr mit Anwendung als mit Zocken zu tuen hat.Darum spielte sowas für mich keine Rolle.Ich bin schon seid 13 Jahren kein richtiger Zocker mehr.Ich selbst habe nur Spiele ohne das AVX2 ne Rolle spielen würde.Wie es weiter geht,na mal sehen.A Way Out läuft jedenfalls immer flüssig.Sogar mit super alten CPUS läuft diese recht gut,nur das spielt bei mir keine Rolle weil ich ja eh mehr CPU Leistung als GPU Leistung habe.Es sei denn es stören einem die 120 FPS ,zu wenig ist das ja eben nicht.Und was kümmern mich dann die wenig mehr FPS wenn es wirklich so wäre.



Und ja, AVX512 wird so langsam auch für lowend CPUs zur Pflicht. Sicher wird man da keine state of the art unbiased raytracer drauf laufen lassen und auch Software-Video-Encoder werden da selten drauf laufen. Aber einfache low precision Matrixmultiplikationen schnell und energieeffizienzt im Ram auszuführen gehört im AI Zeitalter einfach zum Basis featureset. Das geht vom Backgound blur, und Audio processing in einer Videokonferenz bis zu Denoising und Objekterkennung im embedded Bereich.

Mir ist AVX 512 völlig egal und so oft Emulator zocke ich auch nicht.PS3 Emulator Profitiert von AVX 512 ja,aber dazu müsste ich den wieder haben.Games liefen aber auf dem mieserable,habe darum mir lieber ne echte PS3 wieder geholt,habe ich mehr davon.



Nimmt man embedded SOC in Autos zum Beispiel. Dort werden immer noch alte Atom CPUs eingesetzt und auch Alderlake-N kann noch kein AVX512. Dabei geht Vehikel und Objekterkennung mit OpenVino mit AVX512 mehr als doppelt so schnell und das selbst auf der AMD Implementation mit 2x 256bit FPUs. GPUs sind da nicht nur aus Kostengründen sondern auch und wegen dem geringen VRAM nicht immer die Antwort. Manchmal ist es besser das einfach direkt im main memory zu machen. Programmierer erwarten in Zukunft einfach dass sie mit akzeptabler performance AI-enhanced Features implementieren können die auch nicht immer der Mittelpunkt der Anwendung sind. Das ist zunehmend auch im embedded- und low-power-Bereich wichtig.


Ja das mag schon sein und weiter,spielt für mich keine Rolle.Bin was das angeht bei Software allerdings sehr eingeschränkt.Da wird sich was das angeht nicht mehr viel Tuen,nur durch noch mehr CPU Power hole ich die Leistung raus.Von der Software komme schon lange nix mehr dazu.Hier muss die CPU bei mir richtig rein hauen.Muss also mehr als andere bei CPU Leistung erhöhen um nach hinten rum richtig Leistung raus zu bekommen.Ich bin es gewohnt und mache darum das beste draus.



Und ich schreibe von besserer Cache-Latenz über allen Stufen. Das ist nicht dasselbe wie die Cache-Größe. Und Intel mit dem wesentlich breiteren Core-Design dahinter kann auch anders von einer besseren Fütterung der fetten Cores profitieren als AMD dies kann.

Na mal schauen ob das Stimmt,weil als beim testen vom 13900k dieser bei 4 Ghz gegen meine CPU mit 3,8 ghz angetreten ist,da merkte ich von der besseren Cache Latenz allerdings nur garnix.Darum bezeichne ich ohne hohen CPU Takt ist es bei Aktuellen Intel CPUS garnix.Da ist sogar der Ryzen 9 3950x besser als der I9 13900k mit nur 4 ghz.Also warum bei Intel die Leistung nicht auf die Straße kommt und bei AMD schon und für das das die bessere Cache Latenz hat.
Das kann nur eines bedeuten,meiner Anwendung ist bessere Cache Latenz wumpe,anders kann ich es nicht erklären.Würde die wichtig und richtig reinhauen,würde Intel deutlich nach vorne Crashen.Davon ist aber nix was ich merke.Das heißt die Anwendung ist speziell.Oder die Einstellung so eigen dank mir,das es keine Wirkung hat.Habe beim Videoumwandeln ne Custom Settings am Fahren.Die Verhält sich auch total anderst als die im Internet.
Ich selbst kann also hier Entspannt alles beobachten.

Bei mir müsste sich bei Intel mehr tuen als nur der Cache Latenz.Und für das das Intels CPU breiter sind als das von AMD,scheint auch nicht zu wirken.Vielleicht ist die CPU zu breit oder die Einstellung so ,das es die CPU nicht richtig Ausfüllen kann.Es kann ja auch ne CPU zu breit sein und es dann die mehrleistung einfach verpufft.
Vielleicht ergeht es ja Ryzen CPUS auch mal so,das kann ich nicht sagen.Aufjedenfall wird bei AMD auch alles immer breiter.

[latiose88]

Sieh es mal so: Wenn X3D gleichauf mit dem nominell gleichem Nicht-X3D liegt, ist es ein positiver Punkt für den X3D. Denn: Der X3D taktet niedriger und hat höhere Latenzen, wenn er also trotz diesen Nachteilen gleichauf ist, bringt der Cache doch noch etwas. Nämlich zumindest genug um die Nachteile zu kompensieren.
Naja das nennst du einen Vorteil.Den 7950x war mit seinen 4,8 ghz gleich schnell wie der Ryzen 9 7950x3d.Beide haben 4,8 ghz und beide haben 142 Watt Stromverbrauch.Wo ist also der Vorteil.Ich sehe nur einen Nachteil in dem fall das der 7950x3d Teuer ist.

Oder beziehst du es als Vorteil dann bei den Games.ALso ich muss da wohl was übersehen haben.Wenn ich da nen Vorteil haben sollte,dann erkläre mir das doch,ich bin da ganz Ohr.
Ich schaue halt auf den Preis den ich zu zahlen habe wenn ich sowas haben will,auf den Stromverbrauch und die Temperatur Entwicklung der CPU und auch auf den Rest der Plattform.
Ich kühle auch nur mit luftkühlung,hatte noch nie mit ner Wasserkühlung gekühlt.Die ist auch etwas günstiger als ne richtige Wasserkühlung.Ich weis wie teuer so ne gute Wasserkühlung ist.Die Fängt bei 150 € an.
ALso von daher rund 70 € dabei gespart.
Ich bin der wo es auch genau nimmt und so alles bis ins kleinste Testet,sogar noch pingeliger als eine Redaktion.Wenn es um die Sache geht die ich so mache,bin ich da schon sehr genau.Mir kann man da also nix vormachen.Ich merke sofort die Schwachstellen einer CPU.
Ich bin da knallhart und ich kenne auch keinen der sich nen I9 13900k kauft um ihn dann bei 4 ghz maximal zu fahren.Das könnte ich sein,der sowas macht.Und sich dann über die sehr geringe Multicore Leistung beschwert weil es nicht genug abliefert.

[mocad_tom]

Ich klemme es mal hier rein, sonst finde ich es nie wieder:

https://twitter.com/SquashBionic/status/1715712486597595463

Bionic Squash sagt Arrow-Lake-H nimmt für die IGPU N4P her.

Und Raichu(aber der ist auf twitter hinter einem Schloß) sagt Arrow-Lake-S wiederverwendet die IGPU von Meteor-Lake-H und dieses IGPU-Tile ist mit TSMC N5.

Hier der Raichu-Tweet, aber nur sichtbar für diejenigen, die Raichu auf twitter folgen:
https://twitter.com/OneRaichu/status/1715720641029284043

Auch auf twitter, aber ich finde gerade die Quelle nicht, Lunar Lake hat CPU und GPU auf demselben Tile und dieser ist in TSMC N3B. Die Lunar Lake GPU wird DG3 (also gedanklich eher in Richtung Battlemage gehen & XMX kommt ieder hinzu).

Ich weiß aber jetzt nicht, ob die Arrow-Lake-H IGPU in 4nm auch eher DG3 wird(die Arrow-Lake-S wird näher an DG2 Alchemist dran sein, und ohne XMX sein).

Ich glaube Arrow-Lake sind fast drei komplett eigene Schienen:

Arrow Lake S mit TSMC N3B und IGPU recycled von Meteor-Lake
Arrow Lake H mit TSMC N3B und IGPU neu
Arrow Lake U mit Intel 20A und IGPU neu

Das SOC-Tile und die Spannungsversorgung für Arrow Lake Intel 20A muss massiv anders aussehen als das SOC-Tile für Arrow Lake TSMC N3B.

Glaubt ihr Lunar Lake wird schon auf ein Glassubstrat draufgepackt?

[aceCrasher]

Sockel 1700 Kühler werden mit Sockel 1851 (Arrow Lake) kompatibel sein. (https://videocardz.com/newz/all-arctic-lga1700-coolers-are-compatible-with-intel-next-gen-arrow-lake-cpus)

[ryan]

Aktueller Status zu 20A und ARL:

We expect to achieve manufacturing readiness on Intel 20A in the first-half of 2024. Arrow Lake, our lead product on 20A, is already running Windows and demonstrating excellent functionality. Even more significant, we hit a critical milestone on Intel 18A with the 0.9 release of the PDK with imminent availability to external customers.

In simple terms, the invention phase of RibbonFET and PowerVIA is now complete, and we are racing towards production-ready, industry-leading process technology.
https://wccftech.com/intel-arm-pc-cpus-we-take-all-competition-seriously-all-products-on-track-2-million-4th-gen-xeon-shipments/

[Leonidas]

MLID bekräftig: ARL soll +30% gegenüber RPL bringen
https://www.3dcenter.org/news/news-des-21-dezember-2023

[HOT]

MLID ist mal wieder viel zu optimistisch, wie bei MTL auch schon. Übrigens liefen die ersten Samples mit Windows von MTL schon Mitte 22
https://www.pcgameshardware.de/CPU-CPU-154106/News/Intel-Meteor-Lake-Test-1394269/
Nur mal so, was das für ARL zeitlich bedeutet.
LNL in N3B hatte Januar 23 Tape Out, das ist ja durchgesickert, ARL-S in N3B dürfte etwas später gewesen sein, dazu gibts leider nichts, aber ist plausibel, dass der so Februar/März 23 Tape Out hatte, ARL 20A hat November23 Tape Out, bildet also im Grunde eine Generation später. Offen ist, in welchem Verhältnis das alles ist. Ist der ARL in N3 besser, ist 8+32 vielleicht sogar N3P und nicht 20A uvm. Ich halte den 6+8 ARL in 20A für ein Massenprodukt, der die bis dahin laufenden RPL-Notebooks und OEM-Desktops ersetzen soll, ich würd mir also keine Luftschlösser darauf aufbauen.

[Tarkin]

MLID bekräftig: ARL soll +30% gegenüber RPL bringen
https://www.3dcenter.org/news/news-des-21-dezember-2023

Der saugt sich diese Zahlen wie immer aus den Fingern (wie schon bei MTL auch)

Kepler sagt ~10%

https://twitter.com/Kepler_L2/status/1705736001925054611

Und Igors Leak vor einigen Monaten bewegt sich auf in diesem Rahmen.

MLID ist als Leaker absolut nicht ernst zu nehmen.

[HOT]

Ist halt seine Masche, erst hypen, dann sich über die lustig machen, die auf den Hype reinfallen. Die 10% deuten sich ja an, viel mehr IPC mit recht starker Taktregression ist plausibel. Da kommen dann halt die 10% bei raus. Ist ja bei Zen5 auch so, erst voll der Hype und dann kam er in die Phase - aah, sind nur 15% maximal und macht sich über die lustig die mehr wollen. Allerdings vertut er sich da zeitlich glaub ich, denn er rechnet ja mit April24 ca. Ich würd sagen, das ergibt wirtschaftlich keinen Sinn und der kommt für Desktop erst gegen Herbst.

[BlacKi]

apple soc trick? wtf?^^
https://cdn.videocardz.com/1/2024/01/LUNAR-ARROW-LAKE-2024-HERO.jpg
https://videocardz.com/newz/intel-shows-off-lunar-lake-with-memory-on-package-reaffirms-its-2024-plans-for-lunar-arrow-lake

[basix]

Wieso Apple Trick? Dass man das Package für Low Power Mobile so designed ist jetzt keine Rocket Science. Hat man aufgrund Konfigurierbarkeit / OEMs im x86 Sektor einfach noch nicht so gemacht. Wenn man die DRAMs aber eh schon fest verlötet, ist es mir als Kunden egal ob auf dem CPU-Substrat oder Notebook-Mainboard.

[y33H@]

Vor allem ist das Lunar Lake und nicht Arrow Lake ...

[CrazyIvan]

Angeblich ist das kleine Die rechts oben nur ein Dummy. Gibt es schon "educated guesses" bzgl. der Aufteilung der anderen beiden Dies? Wenn ich raten müsste, würde ich bei dem kleinen schmalen Die von einem IO-Tile analog MTL ausgehen. Der komplette Rest ist schlicht wieder monolithisch.

[y33H@]

Der Leak sagt ein Die mit CPU+GPU in N3B und ein Die für I/O in ... noch nicht geleakt ^^

https://forums.anandtech.com/threads/intel-meteor-arrow-lunar-panther-lakes-discussion-threads.2606448/page-142#post-41110064

[HOT]

Aktueller Status zu 20A und ARL:


https://wccftech.com/intel-arm-pc-cpus-we-take-all-competition-seriously-all-products-on-track-2-million-4th-gen-xeon-shipments/
Und ich wiederhole es nochmal:

https://www.pcgameshardware.de/CPU-CPU-154106/News/Intel-Meteor-Lake-Test-1394269/
aufs Datum achten. Das ist reines Blabla mit dem produktionsfertig. Wenn der jetzt Windows hochfährt gibts das Produkt Mitte 25.

Ich klemme es mal hier rein, sonst finde ich es nie wieder:

https://twitter.com/SquashBionic/status/1715712486597595463

Bionic Squash sagt Arrow-Lake-H nimmt für die IGPU N4P her.

Und Raichu(aber der ist auf twitter hinter einem Schloß) sagt Arrow-Lake-S wiederverwendet die IGPU von Meteor-Lake-H und dieses IGPU-Tile ist mit TSMC N5.

Hier der Raichu-Tweet, aber nur sichtbar für diejenigen, die Raichu auf twitter folgen:
https://twitter.com/OneRaichu/status/1715720641029284043

Auch auf twitter, aber ich finde gerade die Quelle nicht, Lunar Lake hat CPU und GPU auf demselben Tile und dieser ist in TSMC N3B. Die Lunar Lake GPU wird DG3 (also gedanklich eher in Richtung Battlemage gehen & XMX kommt ieder hinzu).

Ich weiß aber jetzt nicht, ob die Arrow-Lake-H IGPU in 4nm auch eher DG3 wird(die Arrow-Lake-S wird näher an DG2 Alchemist dran sein, und ohne XMX sein).

Ich glaube Arrow-Lake sind fast drei komplett eigene Schienen:

Arrow Lake S mit TSMC N3B und IGPU recycled von Meteor-Lake
Arrow Lake H mit TSMC N3B und IGPU neu
Arrow Lake U mit Intel 20A und IGPU neu

Das SOC-Tile und die Spannungsversorgung für Arrow Lake Intel 20A muss massiv anders aussehen als das SOC-Tile für Arrow Lake TSMC N3B.

Glaubt ihr Lunar Lake wird schon auf ein Glassubstrat draufgepackt?

Danke dafür, das passt gut zusammen. Ich geh auch davon aus, dass die 20A-Variante die Takte nicht packen werden, die die N3B-CPUs packen und eher was für den Massenmarkt wird und ich denke, das die Raptor Lake Refresh ablösen wird in günstigen OEM und günstigen Mobilmärkten. LNL scheint ja eher eine APU für die sehr stromsparenden Varianten zu sein (9W, 15W).

Premium Desktop -> ARL-S in N3B mit AL-Grafik
Premium Notebook -> ARL-H in N3B mit BM-Grafik
Günstige Notebooks -> ARL-U in 20A mit BM-Grafik
Niedrigwatt-Ultrabooks, Tablets, Convertibles usw. -> LNL mit BM-Grafik

[iamthebear]

Das hört sich durchaus plausibel an. Im Grunde sind es dieselben Kerne:

Lunar Lake ist der TSMC Node und wird deshalb gleich mit der GPU zusammen gelegt

ARL ist dann dieselbe Architektur auf Intel 20A

[ryan]

Und ich wiederhole es nochmal:

https://www.pcgameshardware.de/CPU-CPU-154106/News/Intel-Meteor-Lake-Test-1394269/
aufs Datum achten. Das ist reines Blabla mit dem produktionsfertig. Wenn der jetzt Windows hochfährt gibts das Produkt Mitte 25.




Arrow Lake ist seit mindestens August lauffähig, weil es schon Sisoft Einträge gab. Dann würde Mitte 2025 nicht hinkommen, wenn du schon MTL als Maßstab nimmst, aber gut das ist die übliche Trollerei von dir. Arrow Lake kommt zugute, dass der Soc recycelt wird und MTL als erstes tile design ist nochmal was anderes. Mit MTL etwas beweisen zu wollen, ist daneben. Deine Beiträge sind echt unterirdisch.


Das hört sich durchaus plausibel an. Im Grunde sind es dieselben Kerne:

Lunar Lake ist der TSMC Node und wird deshalb gleich mit der GPU zusammen gelegt

ARL ist dann dieselbe Architektur auf Intel 20A


ARL ist 20A und N3B je nach tile.

[HOT]

Wir werden ja sehen, wer recht hat bei dieser Sache ;).

[BlacKi]

Wieso Apple Trick?


hat das schon jemand in der masse vor dem apple m1 so gebracht? kann sein, aber das wäre mir neu.
Vor allem ist das Lunar Lake und nicht Arrow Lake ...
kommt das package erst mit lunar oder schon mit arrow?

[iamthebear]

ARL ist 20A und N3B je nach tile.

Das ARL Compute Tile wird immer 20A sein. Nur das GPU Tile möglicherweise in N3.
Alles andere glaube ich erst wenn es von Intel offiziell bestätigt wird.

Die N3 Version von Arrow Lake (Lion Cove) ist Lunar Lake.

[Leonidas]

Und ich wiederhole es nochmal:
https://www.pcgameshardware.de/CPU-CPU-154106/News/Intel-Meteor-Lake-Test-1394269/
aufs Datum achten. Das ist reines Blabla mit dem produktionsfertig. Wenn der jetzt Windows hochfährt gibts das Produkt Mitte 25.

Du hast ja grundsätzlich Recht. Aber ARL ist die Intel-Gen für 2025. Die muß Ende 2024 fertig sein, wenigstens so weit, das ein volles Portfolio zur CES launchen kann. Die Ingenieure dürfen anderes verzapfen, aber so ein Mainprodukt dürften sie nicht verseppeln (oder verspäten).

[y33H@]

Intel hat gesagt, LNL für Low Power Mobile kommt 2024 und ARL für Desktop Gaming kommt 2024 --- da wäre CES 2025 zu spät.

https://www.youtube.com/watch?v=PD9xBaQhaA4

[HOT]

Du hast ja grundsätzlich Recht. Aber ARL ist die Intel-Gen für 2025. Die muß Ende 2024 fertig sein, wenigstens so weit, das ein volles Portfolio zur CES launchen kann. Die Ingenieure dürfen anderes verzapfen, aber so ein Mainprodukt dürften sie nicht verseppeln (oder verspäten).
ARL ist für 25 und 26. ARL-R (8+32) wird für 26 der entscheidende Chip sein. Ob der 20A oder N3P wird, wird sich dann zeigen. Wenn die ARL-U erst im Laufe des Jahres 25 kommen ist das kein Beinbruch. Wichtig ist, dass S und H verfügbar sind. Wenn es einen 6+8 auch in N3E gibt, könnte man sogar einen fließenden Wechsel machen.
Nur mal zu Erinnerung: AMDs CPU in dem Bereich, in dem ARL-U wichtig wird, wird größtenteils Escher Point sein, welcher nichts weiter als Hawk Point ist, alles nach bisherigem Kenntnisstand natürlich. Alle Prognosen sind schwierig, vor allem wenn sie die Zukunft betreffen :P :D.

[mocad_tom]

ArrowLake-S im Desktop ist Compute Tile mit TSMC N3B und der jetzigen IGPU von Meteor Lake (schlechtere IGPU deshalb, weil man dort eh eine dGPU nebendran dazu steckt).


ArrowLake-U mit Intel 20A sehe ich aber 2024 noch nicht in einem kaufbaren Produkt.

Intel stiehlt sich da mit Spitzfindigkeiten aus der Affäre.

[y33H@]

Es gibt mehr als nur U und S ...

[Leonidas]

Intel wird in jedem Fall bestrebt sein, ein so vollständig wie mögliches Portfolio von ARL zur CES 2025 zu haben - nicht später. Und normalerweise sieht man den Launch der K/KF-Modelle des Desktops noch zum vorherigen Jahresende.

Intel verspätet sich normalerweise auch nicht. Wenn etwas nicht zu diesem Normal-Termin zum Jahresanfang kommt, dann wird das zumeist Ewigkeiten vorher so kommuniziert.

[mocad_tom]

Schon klar, es gibt auch Arrow Lake H, aber da sind Compute Tile+GPU Tile+SOC Tile von TSMC.

Und an einen Arrow Lake H mit Compute Tile mit Intel 20A Prozess glaube ich nicht.

Die können Arrow Lake U mit Intel 20A bringen, da ist aber das Die winzig.
Das wird ein Pipe Cleaner.

Die größeren Arrow Lake Configs z.B. 8P-Cores + 16E-Cores werden 2024 alle von TSMC kommen.

Und an Arrow Lake U mit Intel 20A in den nächsten 11 Monaten glaube ich gerade noch nicht.

[ryan]

Das eine tile mit 20A ist wohl für 6+8 ARL-S und darunter. Mobile ist komplett N3B Anfang 2025. Abgesehen von ARL-U als MTL refresh mit Intel 3.

ARL-H, ARL-HX and "ARL-U" all target CES 2025 for launch

ARL-H and ARL-HX compute tiles are N3B
Only the ARL-S SKU's with 6+8 or below config use a compute tile built on 20A node
No, ARL mobile is 2025.
Only LNL and ARL-S are 2024
https://twitter.com/squashbionic/status/1747628082691793369?s=46&t=Go9LM3iS24APoFi_ulHkGw

[HOT]

Das passt doch ganz gut, dann hält man RPL-Refresh in dem Bereich noch so lange am Markt, bis man im April oder so die 20A soweit hat. Sieht für mich aber so aus, als wäre die 20A-Variante weniger leistungsfähig als die N3Bs, das hatte ich befürchtet. Aber damit ist "bestätigt", dass es 3 N3B-Dies gibt, 8+16, 6+8 und 4+4.

Sieht für mich bisher so aus der Zeitplan:

Dezember 24 -> ARL-S 8+16 Launch
Januar 25 -> LNL Launch (nicht Vorstellung)
Februar 25 -> ARL-H(X)-Launch
Q1 25 -> ARL-U-Launch
Q2 25 -> ARL-S 20A Launch

[davidzo]

hat das schon jemand in der masse vor dem apple m1 so gebracht? kann sein, aber das wäre mir neu.

kommt das package erst mit lunar oder schon mit arrow?
Das ist nichts besonderes von Apple. AMD hat das schon vor Jahrzehnten für Mobil Grafikchips gemacht. Damals war man Marktführer bei diskreten Labtop GPUs mit den Mobility 7500, Mobility 9000 und 9700 GPUs (DX7, 8.1 und 9.0), was wohl auch am Packaging lag mit dem sich selbst fette GPUs wie die 9700 (eigentlich ne 9600pro) in z.B. 14" Thinkpads integrieren ließen.

Zu2: Ich denke Arrowlake-U wird Pinkompatibel mit MTL-U, daher wohl nein.

[ryan]

Das passt doch ganz gut, dann hält man RPL-Refresh in dem Bereich noch so lange am Markt, bis man im April oder so die 20A soweit hat. Sieht für mich aber so aus, als wäre die 20A-Variante weniger leistungsfähig als die N3Bs, das hatte ich befürchtet. Aber damit ist "bestätigt", dass es 3 N3B-Dies gibt, 8+16, 6+8 und 4+4.

Sieht für mich bisher so aus der Zeitplan:

Dezember 24 -> ARL-S 8+16 Launch
Januar 25 -> LNL Launch (nicht Vorstellung)
Februar 25 -> ARL-H(X)-Launch
Q1 25 -> ARL-U-Launch
Q2 25 -> ARL-S 20A Launch


So sieht es aus:

Oktober-November --> ARL-S 8+16
November-Dezember --> Lunar Lake-M
Januar 25 --> ARL-S 6+8 + ARL-H

[iamthebear]

Das macht doch keinen Sinn:

a) Lunar Lake ist Lion Cove in TSMC 3nm. Wenn Arrow Lake auch Lion Cove in TSMC 3nm ist warum haben diese dann 2 Codenamen zur selben Zeit?

b) Wenn TSMC 3nm höhere Taktraten schafft als Intel 20A so wäre Intel ziemlich blöd diese parallel mit derselben Architektur zu launchen. Damit bringt man das Foundrygeschäft komplett um wenn jeder den technologischen Rückstand sieht.

c) TSMC soll sowohl den Low End bzw. Ultra mobile Bereich abdecken (Lunar Lake) als auch den High End Bereich (Arrow Lake H/S).
Und Intel 20A soll dann ausgerechnet die Mitte dazwischen ausfüllen. Macht das irgendeinen Sinn?

[Andi_90]

ARL-S/H/U Compute Tile ist 20A. Rest ist TSMC analog zu MTL.
LNL ist komplett N3

[davidzo]

Das macht doch keinen Sinn:

a) Lunar Lake ist Lion Cove in TSMC 3nm. Wenn Arrow Lake auch Lion Cove in TSMC 3nm ist warum haben diese dann 2 Codenamen zur selben Zeit?

Finde ich auch merkwürdig - wieso soll es einen ARL-U DIE mit 4+4 geben wenn das exakt die Lunar config ist.
LnL scheint eine neuere GPU version (mit gleichviel EUs), neuere NPU und eine andere DIE-Aufteilung und on package memory zu besitzen. Von der TDP her geht LnL mit 8-30Watt aber auch genau in der erweiterten U-Bereich.

Für OEMs ist das schon ein ganz anderer Chip, weil die Plattform komplett neu ist. Aber was ist mit den Kunden, die kriegen praktisch die gleiche CPU-Leistung nur nochmal anders verpackt?



b) Wenn TSMC 3nm höhere Taktraten schafft als Intel 20A so wäre Intel ziemlich blöd diese parallel mit derselben Architektur zu launchen. Damit bringt man das Foundrygeschäft komplett um wenn jeder den technologischen Rückstand sieht.

Das wird niemanden kümmern, denn die potentiellen Großkunden (Nvidia z.B.) haben eh Testchips und daher ganz genaue Daten zur Density und der elektrischen performance. Jensen war jedenfalls mit seinen Intel testchips so zufrieden dass er das öffentlich mitgeteilt hat dass der Prozess für künftige nvidia Chips in Frage käme (ob er damit Mellanox meint oder automotive oder datacenter oder gaming und wirklich was unterschrieben wurde ist unklar). und Amazon (Gravitron, Inferentia) , Google (TPU


c) TSMC soll sowohl den Low End bzw. Ultra mobile Bereich abdecken (Lunar Lake) als auch den High End Bereich (Arrow Lake H/S).
Und Intel 20A soll dann ausgerechnet die Mitte dazwischen ausfüllen. Macht das irgendeinen Sinn?

Ich finde es auch merkwürdig dass in '24+'25(+'26?) praktisch 90% der Client-CPUs nicht mehr aus der Intel Foundry kommen, sondern von TSMC.

Kriegt man so die eigenen Werke wirklich ausgelastet und finanziert man nur noch Chipsets (die MTL und ARL nicht braucht) und Base-DIEs produziert? Selbst der i/o DIE bei MTL und ARL ist ja von TSMC.

Was machen die ganzen Werke die noch auf DUV und Intel7 ausgerüstet sind? Haben die alle Kurzarbeit bis die auf EUV umgerüstet sind und in 1-2 Jahren die produktion mit Intel 20A startet? Potentielle IFS Customer stehen sicher nicht Schlange, denn Automotive ist eingebrochen und für AI ist der Prozess nicht mehr gut genug.

Ich halte es daher für sehr wahrscheinlich dass Raptorlake uns noch eine gaze weile begleiten wird und ein Großteil von Intels Verkaufsvolumen ausmachen wird. Vielleicht rechnet Intel gar nicht damit dass die neuen Tiled-Chips Meteorlake und Arrowlake den ganzen Clientmarkt abdecken und hat vor raptorlake währenddessen ein weiteres mal zu refreshen, womit die Intel7 foundries weiter in betrieb bleiben können.

Immerhin hat man im Datacenter ausschließlich Intel Foundry Chips mit Sierra Forrest und Granite Rapids beide in Intel3. Es kann schon sein dass damit die Intel Werke die bereits auf EUV umgerüstet sind schon ziemlich ausgelastet sind.
Intels Strategie im Datacenter scheint weiterhin die gleiche wie bei Sapphire Rapids und Emerald rapids zu sein: Einfach mehr Silizium gegen AMDs jeweiliges Konkurrenzprodukt stellen. So kann man den Prozess-Nachteil ausgleichen, im Zweifelsfall auf Kosten der Marge. Wobei AMD bei TSMC sicher Premiumbeträge zahlt gegen die IFS noch günstiger ist. Insofern macht es Sinn dass Intel sich große DIEs leisten kann während AMD mehr auf die PPA der Chiplets schaut.


Was ich auch nicht verstehe ist dass die viel gehypte erste Royal Core Architektur von Jim Keller, also Lion Cove mit Arrowlake nur so mäßig abschneiden soll. Also schneller als Meteorlake, aber nur unwesentlich schneller als Raptorlake. Bei Lunarlake hält der Hype aber weiterhin an: "+30-35% IPC, jaa!" - Das ist doch beides Lion Cove und TSMC N3B, oder nicht? Zu wenig Hype bei ARL?

[y33H@]

LNL hat eine neue uArch für CPU+GPU+NPU und Memory-on-Package, deckt ergo andere Geräte ab als ARL-U. Intel 7 läuft ja weiter für u.a. die I/O-Dies von SFR+GNR, andere Fabs produzieren Intel 3/4 für MTL+SFR+GNR und Intel 20A/18A braucht's für ARL+CWF+PTL. Laut MLID kommt Royal erst mit Nova/Beast, sprich Lion Cove wäre genau das - Cove.

[Leonidas]

Wenn die ARL-U erst im Laufe des Jahres 25 kommen ist das kein Beinbruch. Wichtig ist, dass S und H verfügbar sind.

Damit kann ich mich arrangieren. Anstatt ARL-U hat Intel ja Lunar Lake.



Dezember 24 -> ARL-S 8+16 Launch
Januar 25 -> LNL Launch (nicht Vorstellung)
Februar 25 -> ARL-H(X)-Launch
Q1 25 -> ARL-U-Launch
Q2 25 -> ARL-S 20A Launch

Ich würde eher derart spekulieren:
Herbst '24: ARL-S K/KF
Ende '24: Lunar Lake (Ultramobile)
CES '25: ARL-S non K, ARL-Mobile

[davidzo]

LNL hat eine neue uArch für CPU

Ist das so? ja, frühere Gerüchte gingen von Panther Cove und Darkmont aus, aber die jüngeren Gerüchte deuten auf Lion Cove und Skymont. Exakt die CPU-IP die auch ARL-U verwendet.
https://videocardz.com/newz/intel-confirms-lunar-lake-will-feature-lion-cove-p-core-and-skymont-e-core-architectures


Laut MLID kommt Royal erst mit Nova/Beast, sprich Lion Cove wäre genau das - Cove.
MLID hat vieles behauptet, unter anderem das Gegenteil, also das Lion Cove der erste Royal Core ist. Es gibt nicht wenige Artikel die schon Arrowlake als erstes Royal Core / Jim Keller µArch Projekt betiteln. Btw hat MLID auch gesagt dass Nova Lake auf Panther Cove und Darkmont cores basier. Rein vom Namen her geht es also noch weiter mit Cove und Mont.

[mocad_tom]

Bionic Squash hat auf twitter das nächste detail rausgehauen.

Das Compute Tile von ARL-U wird in Intel 3 gefertigt.
Vogelwild.

Damit wird nur das 6P-Core+8E-Core Tile für ARL-S in Intel 20A gefertigt.
Alle anderen Tiles werden in anderen prozessen gefertigt.

Und danach soll dann gleich Clearwater Forest mit einem Riesen-Tile in Intel 18A hochgefahren werden.

[iamthebear]

LNL hat eine neue uArch für CPU+GPU+NPU und Memory-on-Package, deckt ergo andere Geräte ab als ARL-U. Intel 7 läuft ja weiter für u.a. die I/O-Dies von SFR+GNR, andere Fabs produzieren Intel 3/4 für MTL+SFR+GNR und Intel 20A/18A braucht's für ARL+CWF+PTL. Laut MLID kommt Royal erst mit Nova/Beast, sprich Lion Cove wäre genau das - Cove.

An welche Geräte denkst du da?

Eine APU für den Gaming Bereich ist es denke ich nicht. Dafür sind 4+4 Kerne ohne SMT dann doch etwas zu wenig bzw. so viel iGPU Performance wird man mit LPDDR auch nicht bekommen.

Für Tablets wären die 16-32GB wohl wieder etwas überdimensioniert.

Notebooks deckt ja schon ARL-U ab.

Smartphones scheiden auch aus.

Nur für kleinere Nischenanwendungen wird man kaum so eine Entwicklung starten.

Das wird niemanden kümmern, denn die potentiellen Großkunden (Nvidia z.B.) haben eh Testchips und daher ganz genaue Daten zur Density und der elektrischen performance. Jensen war jedenfalls mit seinen Intel testchips so zufrieden dass er das öffentlich mitgeteilt hat dass der Prozess für künftige nvidia Chips in Frage käme (ob er damit Mellanox meint oder automotive oder datacenter oder gaming und wirklich was unterschrieben wurde ist unklar). und Amazon (Gravitron, Inferentia) , Google (TPU

Den Endkunden wird es kümmern und damit springen dann auch die OEMs mit ab.
Dasselbe Problem hat Samsung seit dem Snapdragon 8 Gen1+. Nun wo jeder sieht wie sehr Samsung bei Takt bzw. Verbrauch hinterher hinkt will keiner mehr einen Samsung Node in seinem Smartphone.

Ich finde es auch merkwürdig dass in '24+'25(+'26?) praktisch 90% der Client-CPUs nicht mehr aus der Intel Foundry kommen, sondern von TSMC.

Kriegt man so die eigenen Werke wirklich ausgelastet und finanziert man nur noch Chipsets (die MTL und ARL nicht braucht) und Base-DIEs produziert? Selbst der i/o DIE bei MTL und ARL ist ja von TSMC.

Datacenter dürfte zu der Zeit noch großteils Intel 7 produzieren und danach zu Intel 3 schwenken.
Man hat auch noch die Möglichkeit Meteor Lake zu refreshen bzw. auf Intel 3 zu portieren und damit den gesamten Markt der Core i3, Pentium, Celerons etc. zu bedienen.


Ich würde eher derart spekulieren:
Herbst '24: ARL-S K/KF
Ende '24: Lunar Lake (Ultramobile)
CES '25: ARL-S non K, ARL-Mobile

Damit wäre der ARL Launch in etwa so wie Alder Lake. Das würde grundsätzlich Sinn machen. Aber nur falls Arrow Lake Desktop auch wirklich launched. Ich habe da immer noch meine Zweifel. Dass es ein neuer Intel Node auf Anhieb auf Desktop Taktraten schafft das ist schon verdammt lange her und bei einem ordinären (nicht auf hohe Taktraten getrimmten) TSMC N3 habe ich da auch meine Bedenken vor allem da N3 bei TSMC ja auch noch relativ frisch ist.

Was ich auch nicht verstehe ist dass die viel gehypte erste Royal Core Architektur von Jim Keller, also Lion Cove mit Arrowlake nur so mäßig abschneiden soll. Also schneller als Meteorlake, aber nur unwesentlich schneller als Raptorlake. Bei Lunarlake hält der Hype aber weiterhin an: "+30-35% IPC, jaa!" - Das ist doch beides Lion Cove und TSMC N3B, oder nicht? Zu wenig Hype bei ARL?

Man sollte ich hierbei den Lebenslauf von Jim Keller ansehen und die jeweiligen Produkte betrachten. Das geht sehr gut, da es sich normalerweise immer nur für einzelne Projekte anheuern lässt wo er den Grundstock legt

AMD Athlon64:
Gekommen: 1998
Gegangen: 1999
Release: 2003 (5 Jahre später - entspricht ca. einem Entwicklungszyklus)

AMD Zen:
Gekommen: 2012
Gegangen: 2015
Release: 2017 (was für eine Überraschung)

Intel ???:
Gekommen: 2018
Gegangen: 2020
5 Jahre später: 2023

Hier ging es nicht um irgendein Royal Core Projekt in der weiten Zukunft sondern auch Meteor Lake bzw. um das ganze Chipletzeugs unter einen Hut zu bringen.

An irgendwelchen CPUs in 2027+ kann er noch nicht viel geplant haben zu der Zeit.

Was MLID angeht:
Dieser hat teilweise echt gute Quellen aber er interpretiert deren Aussagen oft falsch damit diese in sein Weltbild passen.

Die 30-35% IPC halte für ARL halte ich für durchaus realistisch. Das ist dann aber ein Design ähnlich von Apple das auf niedrigere Spitzentaktraten ausgelegt ist.
RGT meine dazu auch ja die 40% IPC können stimmen aber es sind nur mittlere 4GHz, die dabei raus kommen. Mit 1.4x IPC und 4,5GHz wäre das Ding gerade einen Hauch schneller als Raptor Lake aber bei vermutlich deutlich geringerer Verlustleistung.

MLID hat vieles behauptet, unter anderem das Gegenteil, also das Lion Cove der erste Royal Core ist. Es gibt nicht wenige Artikel die schon Arrowlake als erstes Royal Core / Jim Keller µArch Projekt betiteln. Btw hat MLID auch gesagt dass Nova Lake auf Panther Cove und Darkmont cores basier. Rein vom Namen her geht es also noch weiter mit Cove und Mont.

Ich glaube, dass das mit dem Royal Core Projekt komplett falsch verstanden wurde. Da geht es nicht um einen Kern sondern um einen langfristigen Plan was man macht und wie man denkt den gesamten Markt damit abzudecken.

Meteor Lake ist der erste Schritt dazu nämlich die monolithische CPU auf mehrere Chiplets aufzuteilen bzw. die Anbindung der jeweiligen Teile richtig zu gestalten. Das ist an sich schon kompliziert genug und MTL geht sehr viel weiter als es AMD mit seinen CPUs aktuell tut. Das Ganze inkludiert die Ablösung des klassichen Ringbusses. Die P Cores hat man nicht wirklich angegriffen. Bei den E Cores gibt es anscheinend primär Effizienzverbesserungen.

Arrow Lake dürfte dann der nächste Schritt sein. Da gibt es dann neue P und E Cores und noch einmal einen Node Shrink. Meine Vermutung: Mehr Richtung IPC und weniger Spitzentakt. Damit wird der Kern besser auf Laptop und Server optimiert was einen Großteil des Marktes ausmacht.

Nova Lake und danach dürfte dann den konkreten Aufbau der Cores ändern, dass eben 2 Kerne zu einem kombiniert werden können.

Bionic Squash hat auf twitter das nächste detail rausgehauen.

Das Compute Tile von ARL-U wird in Intel 3 gefertigt.
Vogelwild.

Damit wird nur das 6P-Core+8E-Core Tile für ARL-S in Intel 20A gefertigt.
Alle anderen Tiles werden in anderen prozessen gefertigt.

Das würde bedeuten, dass es Lion Cove in 3 verschiedenen Nodes gibt:
Intel 20A (ARL-S)
Intel 3 (ARL-U)
TSMC N3 (Lunar Lake)

Das wäre schon ein bisschen heftig.

Abgesehen davon wäre meine Vermutung eher gewesen:
ARL-U in Intel 20A (entspricht Ice Lake)
ARL-S in Intel 3 (Backport mit ausgereifterem Design und höheren Taktraten - entspricht Rocket Lake)

[reaperrr]

Das würde bedeuten, dass es Lion Cove in 3 verschiedenen Nodes gibt:
Intel 20A (ARL-S)
Intel 3 (ARL-U)
TSMC N3 (Lunar Lake)

Das wäre schon ein bisschen heftig.

Abgesehen davon wäre meine Vermutung eher gewesen:
ARL-U in Intel 20A (entspricht Ice Lake)
ARL-S in Intel 3 (Backport mit ausgereifterem Design und höheren Taktraten - entspricht Rocket Lake)
Die naheliegendste Erklärung wäre, dass die Angstrom-Prozesse i.S. Performance und Packdichte durchaus den nächsten Schritt darstellen, Intel aber wie bei Intel 4/3 vorgeht: 20A sind erstmal nur Perf-Libraries, und erst 18A wird ein vollwertiger Prozess inkl. HighDensity- und I/O-Libraries, und 20A wird deshalb nur in begrenzter Kapazität installiert, so dass es nur für Desktop-Performance-Chips reicht und u.a. der Mobile- und Servermarkt erstmal mit Produkten in Intel 3 und N3B bedient werden muss.

[y33H@]

Exakt die CPU-IP die auch ARL-U verwendet.
https://twitter.com/SquashBionic/status/1747981927020449985

[Leonidas]

Ich habe inzwischen die leise Befürchtung, die nächste Intel-Gen wird noch ein größerer Heckmeck als die derzeitige.

[y33H@]

Was verstehst du unter Heckmeck in diesem Kontext?

[HOT]

Also nach dem Posting ist das kein ARL sondern ein MTL-Refresh in Intel3 den sind ARL nennen(?). Das wird immer schlimmer bei denen.

[y33H@]

Ist bei RPL mit C0 und H0 auch so, eigentlich ADL.

[Platos]

Ja, sieht für mich irgendwie so nach Skylake 2.0 aus, nur dieses mal mit Alderlake.

[y33H@]

Raptor Cove samt L2/L3 ist schon ein deutlicher Sprung vs Golden Cove.

[ryan]

Ist das so? ja, frühere Gerüchte gingen von Panther Cove und Darkmont aus, aber die jüngeren Gerüchte deuten auf Lion Cove und Skymont. Exakt die CPU-IP die auch ARL-U verwendet.
https://videocardz.com/newz/intel-confirms-lunar-lake-will-feature-lion-cove-p-core-and-skymont-e-core-architectures



Arrow Lake war schon immer Lion Cove+Skymont und ja das sind neue Architekturen mit neuen Extensions/Features. Als Ausnahme gilt ARL-U als Intel 3 MTL refresh.

[y33H@]

Deswegen sagte ich ja, ARL-U vs LNL-MX zielen auf unterschiedliche Geräte ab.

[ryan]

Das ist klar. Intels U-lineup ist mittlerweile die budget Serie für mobile. Lunar Lake dagegen wird in höherpreisige Geräte gehen. Für die budget Serie wäre ein echter ARL wohl zu teuer.

[y33H@]

Sieht aus als gäbe es durch die Bank einen ziemlichen Sprung nach oben, top.

[iamthebear]

So macht das Ganze deutlich mehr Sinn.

Ob Intel jedoch sehr viel Erfolg hat Lunar Lake als "Premium" zu verkaufen daran habe ich meine Zweifel.

[Leonidas]

Was verstehst du unter Heckmeck in diesem Kontext?

Ein Durcheianander an Dies, Fertigungstechnologien und Architekturen. Bezogen darauf, das ARL und LNL eine gemeinsame Verkaufs-Gen bilden.


PS:
Intel-Dokument belegt anscheinend den Verzicht auf HyperThreading bei "Arrow Lake"
https://www.3dcenter.org/news/geruechtekueche-intel-dokument-belegt-anscheinend-den-verzicht-auf-hyperthreading-bei-arrow-lak
https://www.3dcenter.org/dateien/abbildungen/Intel-Arrow-Lake-Kern-Konfiguration.png

[y33H@]

Ich finde es spannend, wie per IDM 2.0 der hoffentlich beste Node für jeweilige Produkt bzw Timing verwendet wird.

[HOT]

Gibt kein Durcheinander. Es gibt 2 Produkte, das Intel3-Die für die Massenprodukte wie ARL-U, günstige H und günstige S und ein High-End-Die für die Premiumprodukte wie ARL-"k", ARL HX/H, das ist doch offensichtlich. Und statt eines 2+8-Dies gibts LNL mit 4+4. Ist eben wie bei RPL, das RPL-Die für Hgh-End, HX, teilweise H und der Rest sind ADL. Genauso ist der Rest jetzt MTL-Refresh.
Und wie bei RPL/ADL können die leistungstechnisch nicht so irre weit auseinanderliegen.

[davidzo]

Arrow Lake war schon immer Lion Cove+Skymont und ja das sind neue Architekturen mit neuen Extensions/Features. Als Ausnahme gilt ARL-U als Intel 3 MTL refresh.
Die Rede war von Lunarlake. Da waren am Anfang der Gerüchte jeweils auch Panther und Dark im Gespräch. "WAREN"- das heißt das ist auch nicht mehr der aktuelle Stand.

Entweder diese frühen Gerüchte waren grundsätzlich falsch oder die Architekturen einfach noch nicht soweit. Gelsinger macht ja mittlerweile wie auch AMD eher ein Rolling release. Das heißt in die neue CPU kommt rein was bis dahin fertig ist und Simuliert bzw. FPGA getestet. Wenn der neue Scheduler oder die neue FPU noch unsicher sind, dann verschiebt man die lieber auf den nächsten Release.

Ich tippe auf Letzteres. Demnach stehen die Codenamen nur jeweils für eine RTL-Kompilierung zu einem vorbestimmten zeitpunkt. Welche Features da reinwandern ist flexibel und welche Fertigung man dafür nutzt auch.


Eine APU für den Gaming Bereich ist es denke ich nicht. Dafür sind 4+4 Kerne ohne SMT dann doch etwas zu wenig bzw. so viel iGPU Performance wird man mit LPDDR auch nicht bekommen.

Den Endkunden wird es kümmern und damit springen dann auch die OEMs mit ab.

Ich denke das 99% der Endkunden das nicht mitbekommt und einfach "irgendwas mit i7" kaufen. Die Anleger könnten unzufrieden sein wenn man sieht dass Intel3 nicht mithalten kann. Aber die sind noch unzufriedener wenn es keine Produkte mit Intel3 gibt entgegengesetzt zu Gelsingers Versprechen.


Aber nur falls Arrow Lake Desktop auch wirklich launched. Ich habe da immer noch meine Zweifel. Dass es ein neuer Intel Node auf Anhieb auf Desktop Taktraten schafft das ist schon verdammt lange her und bei einem ordinären (nicht auf hohe Taktraten getrimmten) TSMC N3 habe ich da auch meine Bedenken vor allem da N3 bei TSMC ja auch noch relativ frisch ist.

Da ARL-S in TSMC N3 kommt mache ich mir da gar keine Gedanken. Das ist ein second generation Node deren Vorgänger in Apple Produkten schon sehr gut performt (Gute Taktraten für ein so breites Design) und als N3B nochmal bessere yields und performance haben soll.
ARL-S wird mit 100% Sicherheit launchen, denn sonst steht Intel gegenüber Zen5 mit heruntergezogenen Hosen da. Das einzige was gestrichen ist scheint der 8+32 DIE zu sein, vermutlich zu teuer oder nicht notwendig.

Intel hat einfach keine Alternative zu ARL-S. Die gesamte Strategie ist als disaggregated ausgelegt, daher können neue CPU Arches nur als neues Tile kommen. In welchem Fertigungsverfahren ist dann relativ egal. Der Reuse von Tiles spart Zeit, während Intel dadurch auch ihre alten Prozesse aus den eigenen Fabs für weniger wichtige Tiles und den Base-DIE benutzen kann. Synthese, Simulation und Verification ist sicher um einiges schneller durch den Tile-Ansatz, analog zu AMDs Chiplet-Strategie.


Man sollte ich hierbei den Lebenslauf von Jim Keller ansehen und die jeweiligen Produkte betrachten. Das geht sehr gut, da es sich normalerweise immer nur für einzelne Projekte anheuern lässt wo er den Grundstock legt

Also Jim Keller war damals noch ein blutjunger Entwickler der Erfahrung gesammelt hat und Teil des K7 Teams von Dirk Meyer. An K8 hat er zwar das AMD64 Instruction Set und die Hyper Transport Spezifikation mit entwickelt, aber die Firma noch verlassen bevor der Core festgelegt wurde. Am integrierten Speichercontroller und Cache-System, also dem was den K8 hauptsächlich so schnell gemacht hat kann er keinen besonderen Anteil gehabt haben.
Damals waren die Zyklenzeiten tatsächlich noch viel kürzer. Das war Wildwest, da ging einiges.


Hier ging es nicht um irgendein Royal Core Projekt in der weiten Zukunft sondern auch Meteor Lake bzw. um das ganze Chiplet-zeugs unter einen Hut zu bringen.

Das bezweifle ich, Jim Keller ist kein Fertigungs-typ. Die Intel foundries zu 'besuchen' war für ihn eher Unterhaltsam und genauso spannend wie wenn wir von außen auf sowas drauf gucken. Er ist einer der Standards und Protokolle entwickelt, Projektteams inspiriert und ggf. noch recht gut in Logik-Design ist. Das ist maximal weit entfernt von Foundry business. Für heterogene Fertigung / Tile Strategie hatte man ja auch schon Raja. Da er ein Verfechter von kleinen Teams ist wird er so oder so die Teams reorganisiert haben. Ob jetzt Gelsingers und Rajas Fertigungsstrategie mit Tiles davon beeinflusst wurde oder umgekehrt ist wohl egal, denn er wird den Weg so gegangen sein wie er es auch bei AMD und Tesla für richtig gehalten hat.


Ich glaube, dass das mit dem Royal Core Projekt komplett falsch verstanden wurde. Da geht es nicht um einen Kern sondern um einen langfristigen Plan was man macht und wie man denkt den gesamten Markt damit abzudecken.

Nope, Fertigungsstrategie kommt danach. Das ist ein Architektur-Projekt und hat nichts mit der Chiplet- / Tile oder Rollout-Strategie zutun. Ich denke Royal Core ist einfach ein verschlanktes CPU-µArch-Team welches sich nur noch mit besseren Kern-IP befasst und nicht mehr mit IMC, SOC, TB etc. IP. Analog zu Zen arbeiten die an verschiedenen Ideen die dann in den Core kommen sobald diese ausreichend geprüft und für gut befunden sind.



Die naheliegendste Erklärung wäre, dass die Angstrom-Prozesse i.S. Performance und Packdichte durchaus den nächsten Schritt darstellen, Intel aber wie bei Intel 4/3 vorgeht: 20A sind erstmal nur Perf-Libraries, und erst 18A wird ein vollwertiger Prozess inkl. HighDensity- und I/O-Libraries, und 20A wird deshalb nur in begrenzter Kapazität installiert, so dass es nur für Desktop-Performance-Chips reicht und u.a. der Mobile- und Servermarkt erstmal mit Produkten in Intel 3 und N3B bedient werden muss.
Das ist irgendwie unlogisch, denn die Features von 20A klingen viel mehr nach mobile Prozess. Backside Power delivery senkt zwar den Widerstand und damit Strombedarf und Voltage, aber es gibt neue thermische challenges durch das geflippte DIE welches über den Transistoren platziert ist. Das ist genau wie bei X3D Cache: die Hotspots müssen in Grenzen gehalten werden, denn wenn einer der beiden gebondeten DIEs sich anders ausdehnt als er andere, dann delaminiert sich das. Intel spricht selber davon dass ein großteil der Entwicklung neben Bonding und yields in sogenannte "Thermal mitigation schemes" geflossen ist.
Intels Daten sprechen von lediglich +6% Fmax, aber von gleichzeitig -30% IRdroop durch PowerVia.

AMD hat dazu ein paar Simulationen zusammen mit TSMC, nicht zuletzt wegen X3D Cache der auch auf ein abgeschliffenen DIE aufsetzt. Hotspots werden biszus 20% heißer, was AMD durch throtteling mit 5% weniger Fmax unter Kontrolle hält: https://www.semianalysis.com/p/intel-genai-for-yield-tsmc-cfet-and

In demselben Artikel sind auch Daten von TSMC (vermutlich für N2P BPDN). Die haben mit fetten Copper "thermal" Vias experimentiert. Das macht aber einen Teil der Logikscaling Effekte wieder zunichte und verschlechtert die Signalqualität durch parasitäre Kondensatoreffekte.
Gelöst werden soll das Problem letzendlich durch Diamant- oder AlN "Heatspreader" zwischen den gebondeten DIEs. Wie dann die VIAs für die TSVs freigestellt werden und ob es das noch zeitig für N2P aus dem labor in die Fertigung schafft steht in den Sternen.

TSMC spricht bei N2P (mit GAA und BPDN, also äquivalent zu 20A aber laut TSMC besser) erstmal konservativ von besserer Energieeffizienz und Dichte und noch nicht von besserer Leistung.

Die Gesetze der Physik werden auch auf Intel anwendbar sein.


Ein Durcheianander an Dies, Fertigungstechnologien und Architekturen. Bezogen darauf, das ARL und LNL eine gemeinsame Verkaufs-Gen bilden.

Ich finde mit LNL in derselben generation macht das wieder mehr Sinn. LNL ist der eigentliche U-DIE von ARL, also mit Lion Cove. Da er aber nicht dieselbe disaggregated fertigungsstrategie nutzt, also die ganzen i/o tiles und bga sockel, sondern eine eigene Produktionslinie ist, bekommt er einen eigenen Codenamen.
Und das Intel wie auch schon bei den 13th und 14th Gen Mobilchips wieder alte DIEs recycled ist doch normal. Immerhin soll ARL-U ein shrink sein, das ist besser als nichts - wie beim 13500H (ADL).
Da stellt sich für mich nur die Frage ob ARL-U nun auf dem 2+8 DIE basiert oder dem 6+8. Die aktuellen Core Ultras ind er U-Serie sind ja alle nur 2+8.

Ich finde es spannend, wie per IDM 2.0 der hoffentlich beste Node für jeweilige Produkt bzw Timing verwendet wird.
Du meinst der am besten verfügbare.
Ich glaube das hat weniger mit Performancestrategie zutun als mit Timing, Kapazitäts und Kostenmanagement.


Und wie bei RPL/ADL können die leistungstechnisch nicht so irre weit auseinanderliegen.
Naja, wenn ARL-U wirklich noch mit Redwood Cove kommt, dann könnte da schon eine größere Leistungsdifferenz sein. Es sei denn Lion Cove liegt unter den Erwartungen.

[y33H@]

Apple nutzt ebenfalls N3B, das "B" (base) wurde meinem Verständnis nach nur an N3 geklemmt um es deutlicher von N3E, N3P, N3X usw abzugrenzen. Laut MLID wird ARL-S 8+32 nachgezogen, sprich 2025.

[ryan]

Die Rede war von Lunarlake. Da waren am Anfang der Gerüchte jeweils auch Panther und Dark im Gespräch. "WAREN"- das heißt das ist auch nicht mehr der aktuelle Stand.



Ähm Nein. Erstmalig wurde Lunar Lake im Jahr 2021 erwähnt: https://wccftech.com/intel-next-gen-arrow-lake-lunar-lake-nova-lake-cpus-rumored-to-succeed-meteor-lake/

Damals hatte man sich gewundert, dass dort Arrow Lake und Lunar Lake beide mit Lion Cove+Skymont genannt wurden. Mittlerweile weiß man warum.


Lunar Lake (Lion Cove / Skymont) Q4'24 - This is the product that will use TSMC 3nm as reported by Nikkei. Big performance jump expected and designed to achieve parity or beat AMD and Apple in both performance and power efficiency.

[reaperrr]

Laut MLID wird ARL-S 8+32 nachgezogen, sprich 2025.
Dass Intel diese Konfig, die man ursprünglich schon "zu den Akten gelegt" hatte, wieder reaktiviert, spricht eher nicht dafür, dass ARL-S 8+16 sooo super wird.

Klingt verdächtig danach, dass Intel selbst damit rechnet, entweder in ST (wegen zu geringer Taktraten der P-Kerne) oder MT (wegen defektem P-Kern-SMT) gegen Zen5 Probleme zu bekommen, und deshalb mindestens in MT noch was besseres zu brauchen, um zumindest in einem Teilbereich weiter die Krone beanspruchen zu können.

[ryan]

Dass Intel diese Konfig, die man ursprünglich schon "zu den Akten gelegt" hatte, wieder reaktiviert, spricht eher nicht dafür, dass ARL-S 8+16 sooo super wird.



Es spricht dafür, dass Nova Lake erst 2026 kommt. Also macht es gut Sinn so einen refresh zu bringen, wenn es eh schon geplant gewesen ist. Würde man sofort mit 8+32 kommen, wäre ein refresh umso sinnloser.

Als Grund für den 8+32 Verzicht hat Intel eine "simplify platform power delivery for MTL-S" angegeben. Allerdings war damals noch MTL-S für den Desktop geplant, der später gestrichen wurde.

[mocad_tom]

Auf twitter wird gerade recht enthusiastisch über den Arrow Lake P-Core und den Arrow Lake E-Core gesprochen.

Scheinbar wird das 8-P-Core+16-E-Core-Tile gefertigt mit dem TSMC N3B-Prozess einiges an Mehrleistung mit sich bringen.

SMT wird bei den P-Cores abgeschaltet.

Aber trotzdem scheint ein starker Sprung in Form von mehr Leistung raus zu springen.

[davidzo]

Ähm Nein. Erstmalig wurde Lunar Lake im Jahr 2021

Doch, du hast mich einfach nur falsch gequoted. :wink:

Zitat von y33H@
LNL hat eine neue uArch für CPU

Zitat von davidzo
Ist das so? ja, frühere Gerüchte gingen von Panther Cove und Darkmont aus, aber die jüngeren Gerüchte deuten auf Lion Cove und Skymont. Exakt die CPU-IP die auch ARL-U verwendet.

[ryan]

Doch, du hast mich einfach nur falsch gequoted. :wink:

Zitat von y33H@
LNL hat eine neue uArch für CPU

Zitat von davidzo
Ist das so? ja, frühere Gerüchte gingen von Panther Cove und Darkmont aus, aber die jüngeren Gerüchte deuten auf Lion Cove und Skymont. Exakt die CPU-IP die auch ARL-U verwendet.


y33H@ redet von Lion Cove und Skymont, natürlich sind die Neu.

[Andi_90]

Auf twitter wird gerade recht enthusiastisch über den Arrow Lake P-Core und den Arrow Lake E-Core gesprochen.

Scheinbar wird das 8-P-Core+16-E-Core-Tile gefertigt mit dem TSMC N3B-Prozess einiges an Mehrleistung mit sich bringen.

SMT wird bei den P-Cores abgeschaltet.

Aber trotzdem scheint ein starker Sprung in Form von mehr Leistung raus zu springen.


Wir wissen doch schon wo Arrow-Lake landet von der Performanc? Von Igor und Intel selbst..
Up to 1,05% ST und Up to 1,15MT


https://videocardz.com/newz/intels-next-gen-arrow-lake-s-cpus-target-5-single-thread-and-15-multi-thread-performance-gain-leaked-slide-suggests

[y33H@]

Glaubt doch nicht alles was im Internet steht :freak:

[memory_stick]

@ryan
War klar das davidzo mit neuer architektur neue unbekannte arch verstanden hat. Lion Cove bei ARL ist seit Ewigkeiten klar, ergo im Spekulationsforum nicht neu. Dein aktives "nicht verstehen wollen" von davidzos Sichtweise ist eher ein Ausdruck schlechten Diskusionsstils als davidzos sehr ausführliche analysen. Dort ist jeweils klar ersichtlich welche Schlüsse aufgrund welchen Daten und Sichtweisen gezogen wurden. Dies kann ich bei dr meistens nicht sagen.
Kurzer Input eines interssierten Mitlesers.

[Andi_90]

Glaubt doch nicht alles was im Internet steht :freak:


Die Slide von Intel ist echt aber alt. Woher die Daten von Igor kommen keine Ahnung.

Wenn du mehr weist dann raus damit.

[y33H@]

Ich weiß nie irgendwas, ich glaube einfach was im Internet steht :redface:

[HOT]

Im Prinizp ist das das gleiche, was MLID von AMD ausgegraben hatte. Das ist ein Performanceprojektion für die Entwicklung des Produktes. Bei AMD war das ja 10-15% mehr Performance pro Takt bei Zen5. Bei beiden ist das eben nicht direkt anwendbar auf das Endprodukt, beide Endprodukte werden besser sein als die Projektion. Das sind halt die Minimalziele.
ARL werden sicherlich schon 10%+ Prformance ggü. RPL bringen, trotz Taktregression, pro W sogar mehr (da dürfte das sogar 20%+ sein dank N3). Der MTL-Refresh mit GraniteRidge und SierraForest-Kernen wird auch ca. 5% vor MTL rauskommen (sicherlich auch mehr bei Perf/W), daher passen die ja auch zusammen, ähnlich wie bei RPL und ADL.
Der Refresh kann ja nochmal Leistung drauflegen, weil hier ja 20A und/oder N3P zum Einsatz kommen dürfte.

[ryan]

@ryan
War klar das davidzo mit neuer architektur neue unbekannte arch verstanden hat. Lion Cove bei ARL ist seit Ewigkeiten klar, ergo im Spekulationsforum nicht neu. Dein aktives "nicht verstehen wollen" von davidzos Sichtweise ist eher ein Ausdruck schlechten Diskusionsstils als davidzos sehr ausführliche analysen. Dort ist jeweils klar ersichtlich welche Schlüsse aufgrund welchen Daten und Sichtweisen gezogen wurden. Dies kann ich bei dr meistens nicht sagen.
Kurzer Input eines interssierten Mitlesers.


Er versteht so vieles falsch oder will es nicht verstehen. Wenn ihm etwas unklar ist, muss er sich ausdrücken. Er behauptet falsche Sachen, was er irgendwie nicht einsehen kann. Lunar Lake war vom allerersten Leak an Lion Cove und Skymont. Die Quelle dazu habe ich gegeben. Von ihm kommen nie Quellen, er behauptet gerne irgendwas ohne es anschließend belegen zu können. Nur HOT übertrifft das noch. Wenn das für dich ein guter Diskussionsstil ist, nur zu. Das Problem ist vor allem, dass er nicht wirklich gut Bescheid weiß, was Intel angeht. Seine einzige Informationsquelle scheint MLID zu sein. Das kann nichts werden. Dass ARL-U nur ein MTL refresh werden soll, ist im übrigen auch nicht wirklich neu. Raichu hatte das letztes Jahr schonmal erwähnt: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13352240&postcount=113

[stinki]

Also gehen wir momentan von vier Lunar Lake / Arrow Lake Dies aus?
Lunar Lake U: 4*P+4*E (TSMC N3B)
Arrow Lake S: 8*P+16*E (TSMC N3B)
Arrow Lake P: 6*P+8*E (Intel 20A)
Arrow Lake U: 2*P+8*E (Intel 3, Meteor Lake Refresh)

Oder gibt es da noch mehr?

[HOT]

0https://youtu.be/_Ykl-Knua1c

Damit ist die letzte Lücke gefüllt.

Desktop:
ARL-S N3 mit Alchemist+ (HighEnd, Performance)
Bartlett Lake S LGA1700, Intel7 (Mainstream, Performance)

Mobile:
ARL-H/X N3 (dürfte gleich zum Desktop-Die sein mit BM GPU-Die)
ARL-U ("MTL-R" in Intel3 mit Redwood+ und Gracemont+)
LNL


Außerdem soll der ARL-Refresh nur 8+16 werden.

Ich nehme mal stark an, das dürfte ein Refresh in N3P werden. Wie ja jetzt bekannt wurde, ist offenbar Nova Lake S mit Cougar Cove und Renteble Units in N2 gefertigt.
Gleichzeitig scheint 18A gute Fortschritte zu machen und bei PTL und bei Clearwater Forest (beides low-Power-Architekturen) zum Einsatz zu kommen. Beides sind offenbar Lion Cove+ und Skymont+, daher würde ich mal ganz stark darauf tippen, dass Intel auch einen 3. im Bunde einsetzen wird der U und die niedigen S-Märkte bedienen wird. Codename unbekannt bisher oder Panther Lake sind 2 Dies.

[w0mbat]

20A hat GAA und backside power. Eigentlich müsste Intel das für alle ihre high-end Produkte nutzen. Wieso jetzt gerade so viel TSMC?

[HOT]

Das ist eine wirklich gute Frage.

[SavageX]

20A hat GAA und backside power. Eigentlich müsste Intel das für alle ihre high-end Produkte nutzen. Wieso jetzt gerade so viel TSMC?

Was jetzt veröffentlicht wird, wurde Jahre vorher so festgelegt. Da hat möglicherweise Intel ein Risiko in der eigenen Fertigung umgehen wollen (Yield und/oder Kapazität).

[w0mbat]

Klar, aber ich finde die Situation so absurd. Jetzt, wo (laut Intel) endlich eine vergleichbare bzw. bessere in-house Fertigung zur Verfügung steht, setzt man auf TSMC, während man in den Jahren davo ewig auf 14nm bzw. 10nm gesessen ist.

Entweder hatte Intel kein Vertrauen in ihre zukünftigen Fertigungsprozesse, oder sie sind nicht so gut wie behauptet wird.

[HOT]

Der TSMC-Chef war ja davon überzeugt, dass N3P besser ist als 18A. Klar, Gelsinger sagt das Gegenteil aber Taten zeigen mehr als Worte, natürlich nur, wenn das alles auch stimmt.

SavageX hat natürlich auch recht, die Entwicklung braucht ein paar Jahre, wenn man 3-4 Jahre vorher den Prozess festlegt, ist das kaum noch zu ändern. Allerdings würde das nicht Nova Lake in N2 erklären. Sowas macht man nur, wenn man davon mehr erwartet als von 18A. Intel kann das ja auch total egal sein. Wenn der Prozess bei Perf/W konkurrenzfähig ist reicht das - für mobil, die kleinen Desktop-Varianten, Server usw. Aber für die Top-Dogs braucht man natürlich die 5-6GHz.

[mocad_tom]

Der Fertigungsprozess Intel 18A ist gut aber teuer.

Man scheint wohl auf längere Belichtungszeiten zu setzen.

Dadurch hat man weniger Waferstarts.

Dies, die an das Rectile Limit rangehen und sich für teuer Geld verkaufen lassen sind gut für diesen Prozess.

Server-Prozessoren (Diamond Rapids, Clearwater Forest), AI-Beschleuniger etc. etc.

Am 21. Februar kommt Sam Altman auf das IFS Direct Connect 2024-Event
https://twitter.com/PGelsinger/status/1752346283036287204

Sam Altman wollte ja für Open AI einen Foundry Partner für ihre selbst designten AI-Beschleuniger suchen.

Und Jen-Hsun Huang von nvidia hat ja auch schonmal kurz anklingen lassen, dass er Intel 18A interessant findet.


Und ja klar darf man dann da die Augenbrauen hochziehen und die Nase rümpfen.

Es wird ein "Spezialitäten-Prozess" und kein Wald-und-Wiesen-Prozess wo man auch mal eben schnell Smartphone-Chips durchjagen kann.

[y33H@]

ARM IP @ 18A nicht für Smartphone SoCs? ^^

[HOT]

Ausgerechnet Smartphone SoCs werden mMn mit 18A hervorragend laufen.

[ryan]

Klar, aber ich finde die Situation so absurd. Jetzt, wo (laut Intel) endlich eine vergleichbare bzw. bessere in-house Fertigung zur Verfügung steht, setzt man auf TSMC, während man in den Jahren davo ewig auf 14nm bzw. 10nm gesessen ist.

Entweder hatte Intel kein Vertrauen in ihre zukünftigen Fertigungsprozesse, oder sie sind nicht so gut wie behauptet wird.


14nm und 10nm Chips waren inkompatibel für TSMC, das wurde doch erst nach dem 10nm Desaster entkoppelt. Aus der Planungszeit stammen Lion Cove und Skymont, das sind die ersten neuen Kerne nach der 10nm Ära.



The tight coupling between architecture and process nodes also made it nearly impossible to port those designs over to older process nodes, or to shift its designs to nodes from other foundries.

First, Intel committed itself to decoupling its architectures from the process, thus making its architectures portable between nodes. This new approach allows the chipmaker to use newer architectures on older nodes, thus speeding deployment in the face of unanticipated delays. It also allows Intel to select the best node for the intended purpose, be it either an internally-developed node, or a node from an external vendor.

These changes do result in sacrificing some level of deep architectural tuning for each process node, which in turn results in less performance-enhancing customizations. However, the net effect is a faster, more flexible design process that allows the company to sidestep challenges with its process tech.
https://www.tomshardware.com/news/intels-path-forward-10nm-superfin-technology-advanced-packaging-roadmap



Für Intel 4 und 20A sind nur kleine Volumen geplant. Bezüglich Nova Lake kann auch die GPU gemeint sein, wenn das überhaupt stimmt mit den 2nm.

[fondness]

Arrow Lake kommt scheinbar mit 24C/24T für den Desktop. Ohne Hyperthreading und AVX-512.
https://wccftech.com/intel-arrow-lake-s-desktop-cpu-features-24-cores-24-threads-no-avx-512-support/

Sehr spannend, das fehlen von HT spricht für eine grundlegend neue Architektur. Nachdem ich mir nicht vorstellen kann, dass man für Server auf HT verzichtet, würde das auch für eine Trennung von Server und Desktop-Architektur sprechen.

[HOT]

Clearwater Forest setzt offenbar auf Skymont und Diamond Rapids auf Lion Cove, da wird nix getrennt. Lion Cove und Skymont sind die Kerne, die 25 und 26 zum Einsatz kommen werden, überall.
Bei Arrow Lake und Lunar Lake in N3 (Bis auf Arrow Lake U, welcher ein MTL-Refresh ist), in Panther Lake, Clearwater Forest und Diamond Rapids in 18A.

[woodsdog]

Arrow Lake kommt scheinbar mit 24C/24T für den Desktop. Ohne Hyperthreading und AVX-512.
https://wccftech.com/intel-arrow-lake-s-desktop-cpu-features-24-cores-24-threads-no-avx-512-support/

Sehr spannend, das fehlen von HT spricht für eine grundlegend neue Architektur. Nachdem ich mir nicht vorstellen kann, dass man für Server auf HT verzichtet, würde das auch für eine Trennung von Server und Desktop-Architektur sprechen.

Wie kommst du auf den Schuh? Ernstgemeinte Frage.

akams razor sagt eher
A. HT ist bei AL irgendwie kaputt
B. HT ist bei AL in der Iteration aus Produktstrategischen Gründen ausgeschaltet, z.B. um den Refresh damit zu bringen weil heute schon klar ist das irgendwas Nachfolgendes später kommt. Hatten wir ja zur genüge bei i5/i7 SKUs in der Vergangenheit.

[HOT]

Wenn er SMT hätte, wäre SMT aktiv.

[woodsdog]

Wenn er SMT hätte, wäre SMT aktiv.

Du meinst so wie bei ALLEN SKUs die kein HT Aktiv haben? zich i3s, i5s, Pentiums?

Verstehe. Ja.

[Der_Korken]

akams razor sagt eher
A. HT ist bei AL irgendwie kaputt
B. HT ist bei AL in der Iteration aus Produktstrategischen Gründen ausgeschaltet, z.B. um den Refresh damit zu bringen weil heute schon klar ist das irgendwas Nachfolgendes später kommt. Hatten wir ja zur genüge bei i5/i7 SKUs in der Vergangenheit.

A: Und nachdem SMT seit 15 Jahren problemlos in allen CPU-Gens funktioniert hat, geht es ausgerechnet bei der Gen kaputt, wo seit längerem über große Architekturänderungen spekuliert wird, aber tatsächlich ist es gar kein Sprung und das kaputte SMT nur Zufall?
B: Wenn Arrow Lake selbst ohne SMT deutlich als der Vorgänger ist, dann muss sich am Kern viel verändert haben. Es sei denn, du hältst es für wahrscheinlicher, dass Intel sich ohne Not blamieren will und eine langsamere CPU als den Vorgänger verkauft.

[woodsdog]

A: Und nachdem SMT seit 15 Jahren problemlos in allen CPU-Gens funktioniert hat, geht es ausgerechnet bei der Gen kaputt, wo seit längerem über große Architekturänderungen spekuliert wird, aber tatsächlich ist es gar kein Sprung und das kaputte SMT nur Zufall?
B: Wenn Arrow Lake selbst ohne SMT deutlich als der Vorgänger ist, dann muss sich am Kern viel verändert haben. Es sei denn, du hältst es für wahrscheinlicher, dass Intel sich ohne Not blamieren will und eine langsamere CPU als den Vorgänger verkauft.

Ich schließe das nicht aus, halte es aber für unwarscheinlicher - deswegen die Rasierklinge - dass man ein über Jahrzehnte erprobtes und BILLIGES Feature für das was es kostet aber bringt einfach nicht mehr nutzt. Alle (-Apple?) fetten Kerne nutzen SMT um Einheiten besser auszulasten. Vielleicht hat der Fehlerteufel so hard zugeschlagen das SMT ausgeschaltet werden musste - keine Ahnung. Es ist ne Möglichkeit.

Worüber spekuliert wird ist mir völlig egal, man hörte seit JAHREN das AMD/Intel auf SMT-2 Wechseln könnten blabla, alles nie passiert, hier fehlt mir also irgendwie so ein wenig das Argument.

Ich finds auf jeden Fall spannend.

[Platos]

Es kommen ja später rentable units, also who cares? Einfach Arrow Lake auslassen, wenn man sowas wie HT will.

[fondness]

A: Und nachdem SMT seit 15 Jahren problemlos in allen CPU-Gens funktioniert hat, geht es ausgerechnet bei der Gen kaputt, wo seit längerem über große Architekturänderungen spekuliert wird, aber tatsächlich ist es gar kein Sprung und das kaputte SMT nur Zufall?
B: Wenn Arrow Lake selbst ohne SMT deutlich als der Vorgänger ist, dann muss sich am Kern viel verändert haben. Es sei denn, du hältst es für wahrscheinlicher, dass Intel sich ohne Not blamieren will und eine langsamere CPU als den Vorgänger verkauft.

Naja, gerade eine größere Änderung wäre schon ein Argument, dass SMT "kaputt" sein könnte. Allerdings halte ich das auch nicht für besonders wahrscheinlich.

[Pirx]

Vllt können ohne HT Maßnahmen gegen Seitenkanalattacken abgeschaltet werden, was Performance bringt?

[basix]

Interessante Hypothese. Typischerweise haben neue Cores aber HW-Mitigations dabei, womit Performance-Nachteile eher gering ausfallen.

[ryan]

Arrow Lake kommt scheinbar mit 24C/24T für den Desktop. Ohne Hyperthreading und AVX-512.
https://wccftech.com/intel-arrow-lake-s-desktop-cpu-features-24-cores-24-threads-no-avx-512-support/

Sehr spannend, das fehlen von HT spricht für eine grundlegend neue Architektur. Nachdem ich mir nicht vorstellen kann, dass man für Server auf HT verzichtet, würde das auch für eine Trennung von Server und Desktop-Architektur sprechen.


Das fehlende/deaktivierte SMT ist doch aber schon lange bekannt. Nur das Warum ist nicht bekannt. Also ob sie das nur deaktiviert haben oder von Anfang an so beim Design beabsichtigt gewesen ist.


Clearwater Forest setzt offenbar auf Skymont und Diamond Rapids auf Lion Cove, da wird nix getrennt. Lion Cove und Skymont sind die Kerne, die 25 und 26 zum Einsatz kommen werden, überall.
Bei Arrow Lake und Lunar Lake in N3 (Bis auf Arrow Lake U, welcher ein MTL-Refresh ist), in Panther Lake, Clearwater Forest und Diamond Rapids in 18A.


Clearwater Fores nutzt Darkmont Kerne: https://www.computerbase.de/2024-01/intel-xeon-mit-e-cores-clearwater-forest-setzt-auf-neue-darkmont-kerne/

Panther Lake setzt auch auf Darkmont Kerne....

[Der_Korken]

Vllt können ohne HT Maßnahmen gegen Seitenkanalattacken abgeschaltet werden, was Performance bringt?

Es gab in den Speku-Threads schon diverse Spekulationen, ob SMT bei den Big Cores nicht irgendwann obsolet werden könnte, weil die MT-Leistung über die kleinen Kerne kommt und die großen Kerne nur noch gebraucht werden, um schlecht paralleliserbare Workloads zu beschleunigen. Auch Sicherheit war ein Thema, da das weglassen von SMT seitens Apple ja durchaus Fragen aufwirft.

Ich schließe das nicht aus, halte es aber für unwarscheinlicher - deswegen die Rasierklinge - dass man ein über Jahrzehnte erprobtes und BILLIGES Feature für das was es kostet aber bringt einfach nicht mehr nutzt.

Jetzt bin ich mir nicht mehr sicher, ob ich deinen ersten Post richtig verstanden habe. fondness hat spekuliert, dass das Fehlen von SMT ein weiteres Indiz für einen neuen Kern wäre, gerade weil SMT ein so erprobtes Feature ist und jetzt überraschend fehlt. Daraufhin hast du ihm mit Occam's Razor widersprochen, aber was genau wäre denn der für dich wahrscheinlichere Fall? Dass SMT nur wegen Intels Dummheit fehlt und der Kern gar nicht neu ist?

Worüber spekuliert wird ist mir völlig egal, man hörte seit JAHREN das AMD/Intel auf SMT-2 Wechseln könnten blabla, alles nie passiert, hier fehlt mir also irgendwie so ein wenig das Argument.

SMT-4 war schon immer fragwürdig, denn solange der Performance-Gewinn durch SMT-2 weit weg von den theoretischen 100% ist, wird es nur sehr wenig Auslastungspotenzial für zwei weitere Threads geben. Ich bezweifle, dass wir sowas jemals in Consumer-Kernen sehen werden.

[basix]

SMT-4 ist primär bei Network/HDD Bound Geschichten interessant. Sonst nicht.

[Zossel]

Es wird ein "Spezialitäten-Prozess" und kein Wald-und-Wiesen-Prozess wo man auch mal eben schnell Smartphone-Chips durchjagen kann.

Dabei würde nichts besser die Rentabilität der Fabs besser steigern (Volumen) als Telefone.

[Zossel]

Interessante Hypothese. Typischerweise haben neue Cores aber HW-Mitigations dabei, womit Performance-Nachteile eher gering ausfallen.

Das allererste Spectre brauchte kein SMT.

[Zossel]

SMT-4 ist primär bei Network/HDD Bound Geschichten interessant. Sonst nicht.

Soso.

[HOT]

[...]

Clearwater Fores nutzt Darkmont Kerne: https://www.computerbase.de/2024-01/intel-xeon-mit-e-cores-clearwater-forest-setzt-auf-neue-darkmont-kerne/

Panther Lake setzt auch auf Darkmont Kerne....
Ich nagel dich drauf fest, hab schon ne ganze Liste hier :D. Hab aber auch schon Leaks mit Skymont gesehen und Skymont ergibt deutlich mehr Sinn.

[y33H@]

Ich hab auch ne Liste :redface:

[basix]

Soso.

Starker Beitrag, weiter so :up:

[reaperrr]

Alle (-Apple?) fetten Kerne nutzen SMT um Einheiten besser auszulasten. Vielleicht hat der Fehlerteufel so hard zugeschlagen das SMT ausgeschaltet werden musste - keine Ahnung. Es ist ne Möglichkeit.
Das ist die Aussage der Gerüchteküchen (ob MLID oder RGT weiß ich nicht mehr), dass SMT in dem getesteten Stepping nicht fehlerfrei lief und sich scheinbar auch nicht "mal eben so" fixen ließe.
Und Intel statt Überarbeitung des Designs und Verschiebung des Launches deshalb lieber SMT deaktiviert, zumal die hohe IPC-Steigerung der P-Kerne + die verbesserten E-Kerne wohl reichen, um in MT trotzdem ordentlich zuzulegen.

[Platos]

Na wenn die IPC wirklich so steigen würde (wer's glaubt wird seelig), wäre das ja nicht so schlimm, wenn/falls dann später mit den rentable units wieder so eine Art "Ersatz" kommt.

Aber wehr glaubt denn immer noch diese übertriebenen IPC/Perfomance Vorhersagen? Die letzten Jahre gabs immer wieder welche und die mit hohen Zahlen waren eig. immer übertrieben.

[reaperrr]

Na wenn die IPC wirklich so steigen würde (wer's glaubt wird seelig), wäre das ja nicht so schlimm, wenn/falls dann später mit den rentable units wieder so eine Art "Ersatz" kommt.

Aber wehr glaubt denn immer noch diese übertriebenen IPC/Perfomance Vorhersagen? Die letzten Jahre gabs immer wieder welche und die mit hohen Zahlen waren eig. immer übertrieben.
Die von Zen1 waren nicht übertrieben :)

Klar, nichts davon muss eintreffen.
Aber es deutet halt schon viel darauf hin, dass die Kerne von ARL nicht einfach nur ein weiteres Upgrade der Core-Architektur sind, sondern ein weitgehend von Grund auf neues Design, das im Vergleich zu Core (im Grunde ja alles noch direkte Nachfahren von Nehalem) halt stärker auf IPC statt hohen Takt setzt.

Man muss auch dazusagen, dass Core in Sachen IPC/Takt je Transistormenge gegen Zen ziemlich schwach abschneidet. AMD erreicht konkurrenzfähige IPC und Taktraten mit wesentlich weniger Transistoren. Ab Ice Lake waren bei Intel alle größeren Steigerungen bei Takt oder IPC mit massig Transistoren erkauft.

Bei Core gibt es auch noch architektonische Altlasten, die Zen so nicht hat, wie z.B. dass bei Core INT und FP/AVX teils auf den gleichen Ports hängen, und es keine klar getrennten INT- und FP-Ports gibt.
Die zusätzlichen Pipeline-Stufen und Massetransistoren, die es braucht um trotz größerer Transistormenge in vertretbarem TDP-Rahmen hohe Taktraten zu erreichen wie bei den Core-Architekturen, sind selbst auch nicht umsonst.

Generell klingt es schon glaubwürdig, dass nach 14 Jahren Nehalem-Weiterentwicklungen auch mal wieder was ganz neues kommt, das einen etwas anderen Ansatz hinsichtlich IPC/Takt verfolgt.

[ashantus]

Zum fehlenden Hyperthreading bei Arrowlake habe ich eine eigene Hypothese, ohne Gerücht/Quelle.

Die neu eingebrachte AI in der NPU:
1) die AI könnte ein Problem haben zwischen echten Kernen und Hyperthreading zu unterscheiden. bzw. könnte der Programmieraufwand viel zu kompliziert werden.
Auch zu bedenken ist, daß es Kerne geben würde die HT können aber auch Kerne ohne HT.
Wie soll eine AI selbständig lernen, daß ein P-Core doppelt vorhanden ist, aber ein E-Core nur einmal vorhanden ist? Wie bringt man einer AI bei, diesen Widerspruch zu lernen und zu verarbeiten? Da könnten einige Probleme aufgetaucht sein.
2) die AI selbst bringt so einen Boost, daß Hyperthreading schlicht überflüssig wird.
3) Der Designaufwand der Kerne könnte ohne HT leicht minimiert werden, so daß man weniger Die-Fläche braucht, als auch stromeffizientere Kerne hat. Welche eben wiederum im Zusammenspiel mit der NPU das fehlende HT ausgleichen.

[y33H@]

Was hat die NPU mit SMT zu tun?

[Andi_90]

SMT hat nichts mit der NPU zu tun.
Aber es ist ziemlich logisch, dass Intel einen Weg einschlagen musst.

Die Intel "Big" Core sind im ggü. den Zen Cores von Fläche und Energiebedarf zu groß. Da man das Multi-Threading Thema perfekt über die Little Cores gelöst hast. Ist die automatische die nächste Frage wie mache ich meine Big Cores schneller ohne noch größer von der Fläche zu werden und den Energiebedarf gering zu halten.

Deswegen SMT weg (Fläche + Energie). Man wird sich halt angeschaut haben was für Single-Core mehr bringt SMT oder bessere "Single-Core" Leistung --> letzters hat halt gewonnen.

[basix]

Die Arrow Lakes Cores werden mit 99.99% SMT eingebaut haben. Aus einem einfachen Grund: Es macht Sinn, weil Perf/mm ansteigt. Die selben Cores werden für Server kommen, wo man deutlich mehr von SMT profitiert. Hier parallel zwei abgewandelte Core Designs zu fahren ist nicht sinnvoll.

SMT ist abgeschaltet weil, wie das woodsdog usw. schon dargelegt haben, 1) etwas nicht funktioniert oder 2), man mehr Bumms für den Refresh haben will.

Ich tendiere eindeutig zu 1), weil das Abschalten verringert die Konkurrenzfähigkeit gegen einen wohl starken Zen 5.
Intel präferiert hier Time-to-Market. Unter dem Strich hat Intel vermutlich mehr davon, weil Arrow Lake verglichen mit Raptor Lake wohl konkurrenzfähiger zu Zen 5 sein wird. Da ist mal egal, ob SMT funktioniert oder nicht. Verglichen mit RPL gut gesteigerte ST Performance, stark verbesserte Energieffizienz, nur marginal mehr MT. Das wird ein Kunde eher wollen als maximale MT Performance, dafür 6 Monate später released.

[Andi_90]

Die Arrow Lakes Cores werden mit 99.99% SMT eingebaut haben. Aus einem einfachen Grund: Es macht Sinn, weil Perf/mm ansteigt. Die selben Cores werden für Server kommen, wo man deutlich mehr von SMT profitiert. Hier parallel zwei abgewandelte Core Designs zu fahren ist nicht sinnvoll.

SMT ist abgeschaltet weil, wie das woodsdog usw. schon dargelegt haben, 1) etwas nicht funktioniert oder 2), man mehr Bumms für den Refresh haben will.

Ich tendiere eindeutig zu 1), weil das Abschalten verringert die Konkurrenzfähigkeit gegen einen wohl starken Zen 5.


Du glaubst doch nicht ernsthaft das Intel physikalisch einbaut aber abschaltet wegen funktioniert nicht? Auch die Nachfolger haben kein klassisches SMT mehr.

[basix]

Wenn es nicht funktioniert, was sind deine Optionen? Schaue dir AVX512 bei Arrow Lake und Raptor Lake an. Ist drin, kann aber nicht genutzt werden.

Du kannst es jetzt fixen, nur verzögert sich der Produkt-Release. Opportunitätskosten allenfalls viel höher, als wenn man SMT mal einfach weglässt und für den Arrow Lake Refresh fixt.

[HOT]

Es geht hier nicht um Funktion sondern um eine Designentscheidung. Ich möchte daran erinnern, dass Apple auch kein SMT hat und die .mont-Kerne auch nicht. Wenn es nicht zum Design passt, lässt man es halt weg.

[basix]

Wir können jetzt darüber spekulieren. Aber ich glaube nicht, dass Intel SMT hier weglässt. Es gibt zu viele gute Gründe, wieso SMT Sinn macht. Kein SMT macht den Core designtechnisch zwar simpler, aber man lässt Perf/mm2 und Perf/W liegen. Aber gut, warten wir den Release ab.

[w0mbat]

Gerüchte, dass ARL bzw. Lion Cove kein HT hat gibt es schon lange, so lange, dass Intel genug Zeit für einen respin gehabt hätte. Ich gehe also auch eher von "by design" aus, vor allem, weil die Nachfolger auch alle kein HT mehr haben werden.

[robbitop]

SMT kostet 5% Transistoren und bringt ein Vielfaches davon. Zumindest bis dato war es eigentlich immer ein Nobrainer.
Und zu sagen XYZ macht es auch nicht ist kein Argument. Sowas kann häufig auch nicht technische Gründe haben.

Ggf. will Intel zu diesen Rentable Units was sich dann ggf. vom Design mit SMT beißt. Ich hab noch nicht ganz verstanden was Rentable Units ist und wie man backend ressources sinnvoll sharen können soll über mehrere Kerne so dass Datenverkehr (und damit Energie verballern) nicht nach oben schießt und damit auch Latenzen.

[w0mbat]

Für mich sind Rentable Units quasi CMT (Bulldozer).

[robbitop]

Für mich sind Rentable Units quasi CMT (Bulldozer).
Wenn das so ist, fragt sich aber wo da der Vorteil sein soll.

Wenn ich viel IPC haben will (viel ILP Extraktion, breit, fetter rob, fette caches usw) habe ich relativ dicke Kerne. Und je dicker die Kerne sind, desto mehr lohnt sich SMT weil ja auch entsprechende Resources im Backend vorhanden sein sollten.

Transistorbudgetnormiert ginge das mit CMT dann ja nur mit schmaleren mini backends. Ob man dann pro Thread noch an die dicken Kerne rankommt?

[fondness]

Es geht hier nicht um Funktion sondern um eine Designentscheidung. Ich möchte daran erinnern, dass Apple auch kein SMT hat und die .mont-Kerne auch nicht. Wenn es nicht zum Design passt, lässt man es halt weg.

Apple baut allerdings auch keine Server-CPUs. Gerader da ist SMT ein sehr großer Vorteil. Ich kann mir nicht vorstellen, dass man für Server darauf verzichtet, denn bei Servern ist parallelisierung in der Regel kein Problem und es ist mit Sicherheit wesentlich aufwändiger, ~35% mehr Takt oder IPC raus zu holen als 35% Mehrleistung durch SMT mitzunehmen.

Wenn für Server der selbe Core geplant ist, würde ich stark von einem Bug ausgehen, den man dann für die Server-Iteration fixed.

[HOT]

Das ist total egal. Wenn es nicht zum Design passt macht man es nicht. Wie schwer ist das zu verstehen. Warum Intel das so macht ist ja ne ganz andere Frage, aber das ist jetzt nun mal so.

[MiamiNice]

Für mich sind Rentable Units quasi CMT (Bulldozer).


Wenn ich mich recht entsinne, war es bei CMT so, dass es zwei Kerne in einem Modul gab. Wenn der eine Kern im Modul ausgelastet ist bzw. wartet, konnte der zweite übernehmen. Ähnlich zu SMT, nur das hier der 2. "Kern" komplett vorhanden ist.
Wenn ich die Post zu Intels neue Technik richtig verstanden habe und die Timeline mit einbeziehe, z.b. den Kauf von SoftMachines und an was die geschraubt haben, dazu den ein oder anderen Post seitens Intel der letzten Jahre, komme ich zu dem Schluß, dass Intel nun den großen Wurf gelandet hat. Ich denke, dass Rentable Units, wie der Name schon sagt, dynamisch zuschaltbare Kerne sind, die die ST Leistung eines Kerns erhöhen. Ich weiß nicht wie Intel das gemacht hat, aber es scheint als könne Intel nun Threads splitten und parallel abarbeiten.
Wenn das der Fall ist, wird das den kompletten Markt umdrehen.

[HOT]

CMT ist das mal nicht, vielleicht geht das ein bisschen in die Richtung. Aber das sind ja dann zwar Doppel-CPU-Module innerhalb des Prozessors, die sich Teile des Frontendes teilen, aber es bleiben ja nach wie vor separate Kerne. Bei BD war das ein Frontend für 2 Backends, das macht Intel nicht.

[fondness]

Das ist total egal. Wenn es nicht zum Design passt macht man es nicht. Wie schwer ist das zu verstehen.

Na wenn du das sagst muss es ja so sein :)


Warum Intel das so macht ist ja ne ganz andere Frage, aber das ist jetzt nun mal so.

Das war aber genau die Frage um die es ging. :)

[davidzo]

Apple baut allerdings auch keine Server-CPUs. Gerader da ist SMT ein sehr großer Vorteil. Ich kann mir nicht vorstellen, dass man für Server darauf verzichtet, denn bei Servern ist parallelisierung in der Regel kein Problem und es ist mit Sicherheit wesentlich aufwändiger, ~35% mehr Takt oder IPC raus zu holen als 35% Mehrleistung durch SMT mitzunehmen.

Wenn für Server der selbe Core geplant ist, würde ich stark von einem Bug ausgehen, den man dann für die Server-Iteration fixed.

Definiere Server. SMB ist ein schrumpfender Markt und wird eher mit features und über den preis gewinnen als mit Leistung. Deswegen ist Intel dort noch so stark.

Die wirklichen "Server" heutzutage sind doch die Hyperscaler Installationen. Und da ist SMT unerwünscht, ja ARM sieht sich sogar im Vorteil durch ihr natives SMT-loses Design der Neoverse Cores (Cloud native und so). Da geht es gar nicht nur um Sicherheit, sondern wenn du vCPUs vermietest, brauchst du "predictable performance", das heißt dich kratzen eigentlich auch so Dinge wie Turbo nicht wirklich. Für SLAs willst du enien guten Baseclock, der in jeder Situation gehalten wird. Deswegen war der Intel AVX-takt in der Serverwelt auch so ein Drama, weil es da manchmal unter Baseclock ging und plötzlich andere Code-teile langsamer liefen. Schneller als Baseclock willst du auch nicht, da du dann dem Kunden Performance schenkst und die soll er ja gefälligst dazu buchen.

Bleibt HPC und mainframe. Das sind auch Server, aber in ersterem Segment wird kein Geld verdient und letzteres ist mittlerweile homöopatisch klein geworden.

[Gipsel]

Wenn ich viel IPC haben will (viel ILP Extraktion, breit, fetter rob, fette caches usw) habe ich relativ dicke Kerne. Und je dicker die Kerne sind, desto mehr lohnt sich SMT weil ja auch entsprechende Resources im Backend vorhanden sein sollten.

Transistorbudgetnormiert ginge das mit CMT dann ja nur mit schmaleren mini backends. Ob man dann pro Thread noch an die dicken Kerne rankommt?Nun, Du kannst quasi (ähnlich wie bei Bulldozer) zwei (oder auch vier) Kerne zusammen in ein Modul packen, aber erstmal ist jeder Kern vollständig in dem Sinne, daß ihm exklusiv alle Resourcen zur Verfügung stehen, um einen Thread auszuführen. Zusätzlich gibt es noch einen Pool an Einheiten (die an den Registerfiles beider Kerne im Modul hängen), die dynamisch entweder vom einen oder anderen Kern mitbenutzt werden können. Persönlich halte ich es für schwierig, daß man das performant und energieeffizient hinbekommt. Ohne große Kompromisse bei der Taktrate, wird die Benutzung der geteilten Resourcen vermutlich zusätzliche Latenz bedeuten und zusätzliche Datentransfers (Energie) kosten. Und sicherheitstechnisch gewinnt man gegenüber SMT wohl auch nicht viel (weil über die geteilten Einheiten immer noch Zugriff auf den Prozessorzustand beider Kerne/Threads möglich ist).
Kurz: Auch wenn das erstmal wie ein plausibles Szenario aussieht, zweifel ich, daß das wirklich erfolgreich wird.

Hier spielt auch dies hier mit herein:
Wenn ich die Post zu Intels neue Technik richtig verstanden habe und die Timeline mit einbeziehe, z.b. den Kauf von SoftMachines und an was die geschraubt haben, dazu den ein oder anderen Post seitens Intel der letzten Jahre, komme ich zu dem Schluß, dass Intel nun den großen Wurf gelandet hat. Ich denke, dass Rentable Units, wie der Name schon sagt, dynamisch zuschaltbare Kerne sind, die die ST Leistung eines Kerns erhöhen. Ich weiß nicht wie Intel das gemacht hat, aber es scheint als könne Intel nun Threads splitten und parallel abarbeiten.
Wenn das der Fall ist, wird das den kompletten Markt umdrehen.Es ist schon möglich, daß intel versucht hat, etwas in die Richtung von VISC von Soft Machines zu entwickeln. Die Bezeichnung von "Rentable Units" läßt mich aber für diesen Fall vermuten, daß intel das Konzept auf ein besser handhabbares Maß eingedampft hat. Also kein Software-Layer, der alle Kerne der CPU an einem Thread arbeiten läßt, sondern ein Hardware Layer irgendwo hinter den Decodern (am µOp-Cache wäre vermutlich ein natürlicher Ort, weil das in Ansätzen da auch schon gemacht wird/wurde [siehe Trace-Cache]) der versucht die Codestruktur zu analysieren und nicht latenzsensitive Sachen zu erkennen und dann für die Ausführung durch so einen Pool von geteilten Einheiten innerhalb eines Moduls an Kernen zu markieren (und es gibt eine Art "side band issue" an diese Einheiten). Im Prinzip wäre der Effekt, des Reorder-Fenster deutlich zu vergrößern, ohne die ROBs unendlich aufzublähen.
Generell bin ich skeptisch, was solche Konzepte wie VISC angeht. Die Luftschlösser, die da häufig gebaut werden um Investoren anzulocken (jetzt nicht spezifisch für Soft Machines, das ist ganz allgemein), haben sich in der Vergangenheit seltenst als real herausgestellt. Wenn man das wirklich implementieren will, wird das sehr schnell sehr komplex und die theoretisch ausgemalten Vorteile schrumpfen oft sehr stark bis zu dem Punkt, daß sich das oft kaum mehr lohnt. Insofern wäre ein Konzept, was das mehr in Einklang mit dem traditionellen Design von High-Performance-Cores bringt, eine Möglichkeit das in den Bereich des Machbaren zu rücken.

[MiamiNice]

Schön dass Du das technisch erklären kannst, ich kann das nicht :up:

Wäre noch ein anderer Ansatz möglich, was die "Rentable Units" sind? Ich mein, auf dem Papier ist das ziemlich klar, gerade mit dem ein oder anderen Post von diversen Intel Ingenieuren.

Selbst wenn Intel die Technik „eingedampft“ hat auf ein umsetzbares Maß, werden diese Einheiten wohl oder übel, die IPC (massiv?) erhöhen, sonst würde es imo keinen Sinn ergeben, diese anzubieten. Ich gehe davon aus, dass dies der erste Schritt ist, zu quasi „unendlicher“ ST Rechenpower. Lassen wir das ganze zwei, drei Generationen reifen, sehen wir wahrscheinlich many Core CPUs, die ihre Leistung für einen Thread bündeln können werden.

Ist das massiver Schwachsinn oder doch im Bereich des Möglichen? Meine Frage hat mehr oder minder einen finanziellen Hintergrund, da ich recht viele Intel Aktien halte.

[Andi_90]

SMT kostet 5% Transistoren und bringt ein Vielfaches davon. Zumindest bis dato war es eigentlich immer ein Nobrainer.
Und zu sagen XYZ macht es auch nicht ist kein Argument. Sowas kann häufig auch nicht technische Gründe haben.

Ggf. will Intel zu diesen Rentable Units was sich dann ggf. vom Design mit SMT beißt. Ich hab noch nicht ganz verstanden was Rentable Units ist und wie man backend ressources sinnvoll sharen können soll über mehrere Kerne so dass Datenverkehr (und damit Energie verballern) nicht nach oben schießt und damit auch Latenzen.


Das stimmt so nicht ganz. SMT bringt bei manchen Anwendungen gerade im MT einigies an perf. Aber Intel hat hier ihre Little-Cores um MT Perf mit möglichst wenig transistoren hinzubekommen.

Teste doch mal Cinebench mit SMT on/off im 1C. Hast du keinerlei benefit. Genau so im Gameing mit SMT on/off

[Gipsel]

Das stimmt so nicht ganz. SMT bringt bei manchen Anwendungen gerade im MT einigies an perf. Aber Intel hat hier ihre Little-Cores um MT Perf mit möglichst wenig transistoren hinzubekommen.SMT im großen Kern kostet deutlich weniger Transistoren als ein kleiner Kern. Und man rechtfertigt auch ein wenig noch Zusatztransistoren für geringe Fortschritte der single-Thread-Leistung (weil es dann per SMT die MT-Leistung überproportional steigen läßt).
Teste doch mal Cinebench mit SMT on/off im 1C. Hast du keinerlei benefit. Genau so im Gameing mit SMT on/offNa CineBench 1T benutzt halt nur einen Thread, da kann SMT ja auch nichts bringen :lol:. Daß die Leistung quasi identisch ist, zeigt nur, daß SMT bei Nichtnutzung keine ST-Leistung kostet. Man müßte 1T mit 2T auf einem Kern vergleichen (oder gleich nT einmal mit aktivem und einmal ohne SMT) und da würdest Du sehen, daß es ganz erheblich was bringt. ;)
Und bei Games hängt es einfach vom Spiel ab. Es gibt inzwischen schon einige Spiele, die ohne SMT ordentlich in die Knie gehen. Das trifft umso mehr auf CPUs mit niedriger Kernanzahl zu.

[Zossel]

Wäre noch ein anderer Ansatz möglich, was die "Rentable Units" sind? Ich mein, auf dem Papier ist das ziemlich klar, gerade mit dem ein oder anderen Post von diversen Intel Ingenieuren.
Lass uns nicht dumm sterben.
Meine Frage hat mehr oder minder einen finanziellen Hintergrund, da ich recht viele Intel Aktien halte.
Und, wie laufen deine Transmeta Aktien?

[MiamiNice]

Lass uns nicht dumm sterben.


Letztes Jahr gab es einen Post auf Twitter, der lebte nur wenige Minuten, der genau das beschrieben hat, was ich hier heute gepostet habe. Es hieß was von "Core Fusion, units will work together to reach higher IPC". Ist bissel was her, genauer Wortlaut ist mir nicht mehr bekannt. Bei mir ist das hängen geblieben, weil ich mal einen Sci-Fi Film gesehen habe, indem dies die Story gewesen ist. In dem Film wurden 4 CPUs miteinander verbunden, die dann gemeinsam das Problem lösen konnten.

[Gipsel]

Letztes Jahr gab es einen Post auf Twitter, der lebte nur wenige Minuten, der genau das beschrieben hat, was ich hier heute gepostet habe. Es hieß was von "Core Fusion, units will work together to reach higher IPC". Ist bissel was her, genauer Wortlaut ist mir nicht mehr bekannt.Solche Gerüchte gibt es schon lange, und nicht nur zu intel (18 Jahre alter Link) (https://bit-tech.net/news/tech/amd_reverse_hyperthreading/1/) :wink:. Man wird sehen müssen, wie viel da dran ist.

[MiamiNice]

Das stimmt sicherlich. Allerdings hat AMD vor 18 jahren nicht gerade zufällig eine Firma gekauft, die genau an diesen Dingen geforscht hat. Intel allerdings schon. Und mittlerweile ist genug Zeit vergangen (8 Jahre) um diese Technik ggf. in die eigenen Produkte zu integrieren.

Ich bin sehr gespannt.

Aber nochmal zurück. Siehst Du eine Möglichkeit, bzw. ist es für Dich im Bereich des Möglichen, dass ein Thread auf mehrere Cores verteilt werden kann in Zukunft? Oder gibt es da generelle Probleme die das unmöglich machen?

€:

Auf Reddit gibt es btw. das hier zu lesen:

Rentable units then is those just a way to move execution context from one thread to another thread without the knowledge of the OS?
Likely using performance counters and lookahead used for OOE.
The P-core has a higher lookahead, not so much the e-core.
The way it's likely faster is that it avoids waiting for the OS to re-schedule the work to another core, so there's like no context switch happening.
The problem is how much more complex it is from hyper-threading and that it solves a very different set of problems.
It tries to solve a completely different problem of the OS not having enough information to make the right decision about which core to schedule a job for.

[ryan]

Ich nagel dich drauf fest, hab schon ne ganze Liste hier :D. Hab aber auch schon Leaks mit Skymont gesehen und Skymont ergibt deutlich mehr Sinn.


Das ist eine Quelle von Intel, gefällt dir nicht was?


Server product based on the Atom Darkmont core.

#define INTEL_FAM6_ATOM_CRESTMONT_X 0xAF /* Sierra Forest */
#define INTEL_FAM6_ATOM_CRESTMONT 0xB6 /* Grand Ridge */

+#define INTEL_FAM6_ATOM_DARKMONT_X 0xDD /* Clearwater Forest */
https://lore.kernel.org/all/20240117191844.56180-1-tony.luck@intel.com/T/




Wo ergibt Skymont mehr Sinn? Es ergibt deutlich mehr Sinn, dass die 18A Chips eine neue Mont Bezeichnung bekommen. Da bräuchte es keine Quelle von Intel. Du liegst wie so oft daneben.

[Gipsel]

Das stimmt sicherlich. Allerdings hat AMD vor 18 jahren nicht gerade zufällig eine Firma gekauft, die genau an diesen Dingen geforscht hat. Intel allerdings schon.Es gab damals aber Research Paper und sogar Patente dazu, wenn ich mich richtig erinnere. Aber egal.
Übrigens, wenn solche Firmen nicht gekauft werden, gehen sie üblicherweise pleite, weil es nicht funktioniert, was sie versprochen haben und/oder werden zum Patent-Troll. :rolleyes:
Aber nochmal zurück. Siehst Du eine Möglichkeit, bzw. ist es für Dich im Bereich des Möglichen, dass ein Thread auf mehrere Cores verteilt werden kann in Zukunft? Oder gibt es da generelle Probleme die das unmöglich machen?
€:
Auf Reddit gibt es btw. das hier zu lesen:Möglich ist es sicherlich. Die entscheidende Frage wird sein, ob es wirklich (deutlich) mehr Performance bringt als ein konservativeres Vorgehen oder nur eine Menge Probleme, die den Aufwand nicht rechtfertigen.
Und in Bezug auf das reddit-Zitat, da geht meinem Verständnis eher um Thread-Scheduling durch das OS, nicht um die eigentliche Architektur und wie man damit Performance-Vorteile hinbekommt. Damit es besser handhabbar wird, würde ich vermuten, das funktioniert unterhalb der Ebene des OS (das sieht das verschieben von Teilaufgaben an andere Einheiten nicht, das OS sieht nur sagen wir mal 8 Kerne und das war's so ziemlich). Und ich glaube ehrlich gesagt auch nicht an einen quasi Hypervisor Firmware-/Software-Layer wie bei Transmeta, der den Job übernimmt. Ich vermute wie gesagt eine etwas konservativere Herangehensweise (z.B. Analyse der µOps im µOp-Cache und Umordnung mittels einer in Hardware gegossenen sideband engine [das alleine könnte das OoOE-Fenster bereits ansehnlich vergrößern ohne weitergehende Änderungen am restlichen Kern] und optional flaggen der µOps für Ausführung in den ausgeborgten Einheiten [entweder der anderer Kerne oder eines freien Pools]).

Aber ich bin natürlich auch kein Chip-Designer/-Architekt. Aber die Erfahrung lehrt, daß solche "neuartigen" Konzepte schon öfter mal versprochen wurden und üblicherweise ist nichts draus geworden. Gesunde Skepsis ist also angebracht.

[HOT]

Das ist eine Quelle von Intel, gefällt dir nicht was?


Server product based on the Atom Darkmont core.

#define INTEL_FAM6_ATOM_CRESTMONT_X 0xAF /* Sierra Forest */
#define INTEL_FAM6_ATOM_CRESTMONT 0xB6 /* Grand Ridge */

+#define INTEL_FAM6_ATOM_DARKMONT_X 0xDD /* Clearwater Forest */
https://lore.kernel.org/all/20240117191844.56180-1-tony.luck@intel.com/T/

Wo ergibt Skymont mehr Sinn? Es ergibt deutlich mehr Sinn, dass die 18A Chips eine neue Mont Bezeichnung bekommen. Da bräuchte es keine Quelle von Intel. Du liegst wie so oft daneben.

Mal im ernst: Hör auf das alles immer so extrem ernst zu nehmen. Natürlich lieg ich daneben, du aber eben noch öfter mit der rosaroten Intel-Brille ;). Das schreit ja gradezu danach das etwas spassig zu machen. Die Kunst bei der ganzen Geschichte ist den Wust an Codenamen und Minimalinfohappen, wovon nicht wenige einfach falsch, absichtlich falsch oder einfach fehlgedeutet sind ist die richtigen Schlüsse zu ziehen, das kann in diesem Umfeld niemand, sogar Leuite wie Tom von MLID liegen bei ihren Schlüssen (nicht bei den Leaks) oft total daneben. Aber alles, was über Intel geleakt wird und vor allem, alles, was Intel an Infos rauslässt direkt für bare Münze zu nehmen, muss Intel sich erst wieder verdienen.

Dann ist Darkmont (guter Fund i.Ü.) aber sicherlich wieder eher ein Minimalupgrade zu Skymont, wie Crestmont zu Gracemont, weil es die gleiche Generation ist, wie Meteor Lake zu Alder Lake (wobei Intel hier ja alle an der Nase gerumgeführt hat, kein Wunder, dass Leute und mittlerweile auch Investoren und Geschäftspartner äußerst skeptisch sind).
Komplett neue Architekturen wird dann erst wieder ab Nova Lake geben.

[MiamiNice]

Da hätte ich noch eine Folgefrage, sorry. Die Chips sind mittlerweile relativ groß und schnell getaktet, resultierend daraus, ist man auf weiter Flur der Meinung, Silizium wäre am Ende. Es werden diverse „Nachfolger“ gehandelt, aber meines Wissens hat sich bisher nichts Handfestes und / oder umsetzbares ergeben. Das Problem ist nicht neu, schon der Umschwung auf Multi Kern CPUs hatte imho diesen Hintergrund. Jetzt haben wir drölfzig Cores in fast jedem PC, allerdings ist das groß der Software Landschaft nicht mitgewachsen. Gerade Consumer Software zieht eher weniger Nutzen aus der Masse an Cores.

Wenn es nun einen Weg gibt, die IPC doch weiter auf Silizium zu steigern, ist es nicht egal ob es nun deutlich oder weniger deutlich schneller ist? Ein wenig weiter gedacht, weg von Units, hin zu Cores, die sich zusammen schalten können, wäre dies nicht der ideale Verwendungszweck für all die unnützen Cores, die wir zahlen aber nicht nutzen?

[HOT]

Daher scheint der 8+32 ARL-Refresh wieder nur ein 8+16 Refresh zu werden, wie MLID neulich geleakt hat. Mehr Kerne wird nicht mehr viel bringen und verkaufen sich auch nicht wesentlich besser, das wäre ein reines Benchmarkwettrüsten, das hat schon bei HEDT nicht funktioniert, es gibt einfach zu wenig Käufer dafür.
Auch AMD wird mMn keine AM5-CPU mit mehr als 16 Kernen bringen (obwohl sie es mit den 16c-Chiplets sogar simpel realisieren könnten), das lohnt einfach nicht.
Und in der Transistorgeometrie ist noch viel zu machen, da hatten sowohl Intel als auch TSMC schon umfangreiche Folien zu. Die großen Fullnode-Sprünge, die sich auch bei einer Verkleinerung des SRAM und Analogschaltungen niederschlugen wirds halt so nicht mehr geben. Dafür geht man ja in die 3. Dimension.

[Platos]

@ Rentable Units:

Ist es denn nicht möglich, dass Intel quasi die Big und Little-Cores "fusioniert" bzw. "dynamisch" macht?

Also mal so ein hypothetisches Beispiel: Ein bisheriger Big-Core besteht aus 4 "Untereinheiten" (quasi die Little-Cores). Die Idee ist jetzt, dass diese 4 Untereinheiten eben als 4 Cores 4 Threads bearbeiten können, aber eben auch gemeinsam an einem (evlt. auch je 2 an je einem Thread).

Das wäre quasi Big-Little in dynamischer Weise, was ein grosses Problem vom Big-Little Konzept behebt (dass man bei manchen Aufgaben lieber nur (oder mehr) schnelle Kerne hätte, bei anderen hätte man dann aber vlt. lieber die kleinen, weil vlt. Energieeffizienter und somit mehr MT Perfomance pro Watt).

[HOT]

Sowas wäre wohl einfach zu schwierig. Bisher sind das ja separate Cluster, immer 4 Littles zusammengefasst, die sich einen Cache teilen.
So wie sich das anhörte sind das jeweils Cluster aus 2 Lion/Cougar Cove-Kernen, die sich Teile des Frontends teilen, damit Teile des Backends beider Kerne für einen Thread genutzt werden können.

[Zossel]

Wenn es nun einen Weg gibt, die IPC doch weiter auf Silizium zu steigern, ist es nicht egal ob es nun deutlich oder weniger deutlich schneller ist? Ein wenig weiter gedacht, weg von Units, hin zu Cores, die sich zusammen schalten können, wäre dies nicht der ideale Verwendungszweck für all die unnützen Cores, die wir zahlen aber nicht nutzen?

Die Abhängigkeiten bleiben als Problem, und komplexer Klimbim neigt dazu langsam zu werden.

[MiamiNice]

@Hot:
Würde das mit unterschiedlichen Taktraten laufen bei den Lion/Cougar Cove-Kernen? Ich könnte mir vorstellen, dass alle Kerne gleich takten müssen, aus Latenz oder anderen Gründen. Die kleinen Kerne sind nicht bekannt für ihre Taktfreudigkeit.
Wenn der Speedup, durch die Rentable Units, nicht generell, sondern nur bei bestimmten Workloads greifen würde und das Design eher nicht so hoch taktet wie z.b. RPL, könnte das der Grund für Bartlett Lake sein?

[Zossel]

Auf Reddit gibt es btw. das hier zu lesen:


Rentable units then is those just a way to move execution context from one thread to another thread without the knowledge of the OS?
Likely using performance counters and lookahead used for OOE.
The P-core has a higher lookahead, not so much the e-core.
The way it's likely faster is that it avoids waiting for the OS to re-schedule the work to another core, so there's like no context switch happening.
The problem is how much more complex it is from hyper-threading and that it solves a very different set of problems.
It tries to solve a completely different problem of the OS not having enough information to make the right decision about which core to schedule a job for.

Klingt wie ein Thread Director der keine Unterstützung vom OS braucht. Könnte aber blöd werden wenn das Zeug ständig Caches umladen muss.
Und den ganzen OOO-State wegwerfen ist bestimmt auch alles andere als billig.

[HOT]

@Hot:
Würde das mit unterschiedlichen Taktraten laufen bei den Lion/Cougar Cove-Kernen? Ich könnte mir vorstellen, dass alle Kerne gleich takten müssen, aus Latenz oder anderen Gründen. Die kleinen Kerne sind nicht bekannt für ihre Taktfreudigkeit.
Wenn der Speedup, durch die Rentable Units, nicht generell, sondern nur bei bestimmten Workloads greifen würde und das Design eher nicht so hoch taktet wie z.b. RPL, könnte das der Grund für Bartlett Lake sein?
Das sind einige der Probleme, weswegen diese Lösung eine heftige Herausforderung ist. Vielleicht funktionieren rented Cores auch völlig anders, wer weiß.

[mocad_tom]

Beim L1 Cache sind heutzutage viele Prozessoren aufgebaut nach der Harvard-Architektur.

L1D und L1I sind voneinander getrennt.

Bei Lion Cove wird das Out-Of-Order-Window und die Shadow Register schon wieder größer.

Auch diese Neuumschreibung bei AVX10.1 und AVX10.2 könnte hier mit durchschimmern und könnte genau für diese Rentable Units "vorwärtsgedacht" sein.

https://www.golem.de/news/neue-befehle-mehr-register-intel-ueberarbeitet-x86-architektur-avx-512-fuer-alle-cpus-2307-176142-2.html

Je mehr vektorisiert ein Code-Abschnitt ist, desto mehr kann ich eine Instruction-Pipeline schlafenlegen und die Execution Units dieser Pipeline einer anderen Pipeline leihen.

Hier hat der twitter-Account Longhorn etwas ausgegraben:
https://twitter.com/never_released/status/1754241979133604246

Es scheint in Richtung von "Instruction Set Hygiene" zu gehen.
Mische ich alten SSE2-Code mit neuerem VEX-Code, so kann es passieren, dass Code langsamer läuft.

Und hier gerade erst von Felixclc gepostet:
https://twitter.com/FelixCLC_/status/1754520856061993360


Raichu hat ein paar Sachen zu Lion Cove und Skymont fallen lassen.
Prakar Verma ist Intel-Verrückt, aber die beiden Screenshots von Raichu machen halt neugierig auf mehr:
https://twitter.com/Prakhar6200/status/1752617890690617753

[Orko]

Klingt wie ein Thread Director der keine Unterstützung vom OS braucht.

Klingt für mich auch so. Sehr spannendes Thema.

Könnte aber blöd werden wenn das Zeug ständig Caches umladen muss.
Und den ganzen OOO-State wegwerfen ist bestimmt auch alles andere als billig.

Finde ich nicht. Die CPU kann nicht nur schneller sondern sicher auch besser beurteilen als das OS, wie gerade die Ressourcensituation der ganzen Kerne ist (Auslastung, Temperatur, Relevanz und Größe der Cache Daten, ...), und wie teuer (Leistung und Zeit) das Umladen auf einen anderen Kern wäre. Auch insbesondere Abstand der Kerne, also über wieviele Hops die betroffenen Informationen drüber müssten.

Wie z.B. das Kern Boost Verhalten sehe ich auch die Thread/Kernzuordnung besser in der CPU als im OS aufgehoben.

Der OOO State muss ggf nicht weggeworfen sondern eher transferiert werden. Von E auf P Kern einfach direkt. Von P auf E Kern müsste der P Kern erst das OOO Window soweit leerlaufen lassen bis es in den E Kern passt. Also insoweit das OOO Window (Nicht-) Abhängigkeiten der µ-Ops beschreibt. Die Queues der Scheduler müssten jedoch neu befüllt werden, da P und E Kerne andere Exekution-Ports haben. Annahme dabei meinerseits dass die µ-Ops so designt sind dass P und E Kern dieselben verwenden, bzw dass Unterschiede schnell durch einen Translator entsprechend angepasst / ersetzt werden können.

Aus Topologischer Sicht wäre es dann sinvoll, E und P Kerne nicht in sich zu clustern, sondern (bezogen auf das Bussystem) eher gleichzuverteilen. Oder Cluster aus 1xP und nxE Kernen schaffen, die sich ggf sogar Cache-Level teilen.

[Orko]

Je mehr vektorisiert ein Code-Abschnitt ist, desto mehr kann ich eine Instruction-Pipeline schlafenlegen und die Execution Units dieser Pipeline einer anderen Pipeline leihen.


Mit den bisherigen Kernen wird das nicht gehen, da die Ports / Execution Units eines anderen Kerns topologisch zu weit entfernt sind. Es müssten die Kerne die sich Ports / Execution Units teilen geclustert werden.

Z.B.
- ein P Kern der sich in 2 E Kerne aufteilen lässt
- ein Cluster aus einem P Kern flankiert von einem E Kern
- ein Cluster aus einem P Kern flankiert von zwei E Kernen
- (Bolldozer CMT) zwei P Kerne die sich bestimmte Ressourcen (damals: FP heute ggf AVX) teilen

[iamthebear]

SMT kostet 5% Transistoren und bringt ein Vielfaches davon. Zumindest bis dato war es eigentlich immer ein Nobrainer.
Und zu sagen XYZ macht es auch nicht ist kein Argument. Sowas kann häufig auch nicht technische Gründe haben.

Die Gerüchte deuten darauf hin, dass vor allem doie e Cores deutlich an Oerformance zulegen werden.
Das bedeutet wiederrum, dass für maximale Performance es Sinn macht zuerst die E Cores zu nutzen und dann erst den 2. Thread der P Cores.
Bei einem 8+16 ARL würden dann nur mehr Anwendungen von SMT profitieren die mehr als 24 Threads nutzen können.
Angeblich ging es dabei auch gar nicht um die 5% Transistoren sondern um die zusätzliche Komplexität was einen soäteren Release bedeuten würde.

Ggf. will Intel zu diesen Rentable Units was sich dann ggf. vom Design mit SMT beißt. Ich hab noch nicht ganz verstanden was Rentable Units ist und wie man backend ressources sinnvoll sharen können soll über mehrere Kerne so dass Datenverkehr (und damit Energie verballern) nicht nach oben schießt und damit auch Latenzen.

Also ich habe das so verstanden:
Aktuell gibt es 8 große P Cores, die bei MT Last sich mit SMT in 2 virtuelle Kerne aufsplitten.
Bei Rentable Units ist es umgekehrt, dass es 16 kleinere P Cores gibt wobei sich die Execution Units wahlweise dem einen oder anderen Kern zuordnen lassen (ein Kern mietet sich die Einheiten). Wenn ein Kern nichts tut können die Einheiten vom anderen Kern genutzt werden.
Der Bulldozer Vergleich ist hier vielleicht gar nicht so falsch.

Apple baut allerdings auch keine Server-CPUs. Gerader da ist SMT ein sehr großer Vorteil. Ich kann mir nicht vorstellen, dass man für Server darauf verzichtet, denn bei Servern ist parallelisierung in der Regel kein Problem und es ist mit Sicherheit wesentlich aufwändiger, ~35% mehr Takt oder IPC raus zu holen als 35% Mehrleistung durch SMT mitzunehmen.

Wenn für Server der selbe Core geplant ist, würde ich stark von einem Bug ausgehen, den man dann für die Server-Iteration fixed.

Für das ganze KI Zeugs vielleicht aber sonst ist SMT in der Regel ausgeschaltet. Bei Cloudsystem wo nach CPU Stunde abgerechnet wird und virtuelle Maschinen verschiedener Kunden auf einem System laufen ist keiner darüber glücklich. Mit 2 Threads auf einer physischen Kern beeiflussen sich diese zwangsläufig immer irgendwie. So absichern kann man das gar nicht

[Zossel]

Nix genaues weiß man nicht.
Wenn der Hahn kräht auf dem Mist, ändert sich das Wetter oder es bleibt wie es ist.

[HOT]

Jo :D.

Skymont könnte der eigentliche Star bei ARL werden, hier wird sicherlich sehr viel mehr Performance rauskommen als bisher aber im Gegensatz zu Lion Cove ohne Taktregression.

[ryan]

Arrow Lake-S angeblich verfügbar im November, launch eventuell schon im Oktober. Non-k und Mobile nächstes Jahr, vermutlich in Q1 irgendwann wie schon bei Alder Lake und Raptor Lake. Bestätigt ist nichts, aber macht Sinn.


Arrow k availablity nov ( launch may be in oct)
Arrow non k and mobile next year
https://twitter.com/e_sunny4/status/1755158962050326920

[HOT]

Würde zu den Launches der letzten Jahre gut passen. Mir fällt auch kein Grund an, warum sich das noch verzögern sollte.

[iamthebear]

Ich denke auch, dass Arrow Lake pünktlich launched. Ob es jedoch die erforderlichen Taktraten schafft und die erhoffte IPC hat da bin ich noch etwas skeptisch.
Selbst wenn die E Cores deutlich besser sind hilft das aber den meisten Kunden nur bedingt weiter: Fürs Gaming ist die Performance P Cores ausschlaggebend. Bei den meisten Alltagsaufgaben zählt auch nur der schnellste Thread und für das Ganze Multimediazeugs bringt es zwar etwas aber dafür kostet das Fehlen von SMT wieder einiges.

[Wuge]

10% mehr ST und 20% mehr MT reicht ja. 6 Monate später neues Stepping, Refresh mit 5-6% mehr Takt und weiter gehts ;)

[HOT]

Wenn der Refresh wieder 8+16 wird ist komplett neues Silizium eh unwahrscheinlich. Neue Rev., ich weiss jetzt leider nicht, in wie weit N3P zu N3B kompatibel ist, da kann man sicherlich noch einige 100 MHz rausholen dann.

[y33H@]

N3B und N3E/N3P haben unterschiedliche Design Rules.

[HOT]

War ja zu befürchten. Dann gibts vielleicht doch ein komplett neues Die, mal gucken.

[Tralalak]

InstLatX64
@InstLatX64
There is already a similar #ArrowLake-S variant (CPUID C0660, 20-threads (8P+12E?) 2.3GHz, w/o #AVX512, probably w/o HTT) among the #Intel test machines: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v1/bat-arls-3/boot0.txt

source: https://twitter.com/InstLatX64/status/1755513940535017478

[Gipsel]

I thought it was clear, that intel will reintroduce 512bit vector capabilities in consumer products only later on. First we get the 256bit versions of AVX10.
According to their AVX10 whitepaper, they may even try to do something stupid like supporting AVX10.2/512 only on P-cores while the E-cores have to stay with AVX10.2/256. They probably need some time to figure out how they can squeeze support for such a contraption into the common operating systems. I think it is plain stupid not to support 512bit vector lengths on E cores to enable the exact same feature set on P- and E-cores (they should be able to execute 512bit instructions on narrower hardware like AMD did with Zen4).

[w0mbat]

Mit 20A kommen doch GAA + BSPD gleichzeitig, müsste also ein ziemlicher Sprung für Intel und Arrow Lake sein. Da verstehe ich die Nutzung von N3 noch weniger, weil das entweder viel schlechter ist, oder Intels Prozess steht dumm da, wenn er mit "next-gen" Technologie nicht besser ist.

[dildo4u]

Es geht nicht nur um Performance sondern ob genug Kapazität da ist.
Die neueste Fertigung ist nicht sofort in jeder Fab verfügbar das dauert Jahre.
AMD hat ja schon angefangen Brand neue Low End GPU Modelle in 6nm zu fertigen um Engpässe zu umgehen.

[reaperrr]

Mit 20A kommen doch GAA + BSPD gleichzeitig, müsste also ein ziemlicher Sprung für Intel und Arrow Lake sein. Da verstehe ich die Nutzung von N3 noch weniger, weil das entweder viel schlechter ist, oder Intels Prozess steht dumm da, wenn er mit "next-gen" Technologie nicht besser ist.
Was glaubst du, warum Samsung trotz frühzeitigem Einsatz von GAA (jedenfalls auf dem Papier) für 3GAE trotzdem kaum Kundschaft an Land zieht?

Intels erster FinFET-Prozess (22nm) war auch nicht viel besser als deren ausoptimierter 32nm-Prozess.

TSMC hat durch die vielen Kunden und Umsätze inzwischen ganz andere Test- und R&D-Kapazitäten als die Konkurrenz, an die elektrische Performance von N3E (und N3P) muss auch 20A erstmal rankommen.
18A wird nicht grundlos so schnell hinterherkommen.

TSMC gab sich was die Konkurrenz-Thematik angeht jedenfalls zuletzt sehr selbstbewusst, und die haben über private Kundenaussagen und Technik-Evaluierungen wahrscheinlich bessere Einblicke als wir und die meisten Technik-Journalisten.

Heißt nicht, dass 20A schlecht wird oder dass es nicht besser als Intel 3 wird, nur ob die neuen Techniken allein die Vorteile von TSMC beim Testen und Ausreifen von N3E/P überkompensieren können, ist noch lange nicht raus.

[w0mbat]

18A wird nicht grundlos so schnell hinterherkommen.
18A ist ja auch nur 20A mit mehr libs und für die foundry Kunden.

[ryan]

18A ist ja auch nur 20A mit mehr libs und für die foundry Kunden.


Damit kommt man auf 10% Verbesserung? Ich glaube nicht, dass wir im Detail über die Änderungen informiert wurden sind.

Traditionell lief ein refresh nach einem full node shrink deutlich besser, was die Leistung oberhalb angeht. Das war bei 14nm und bei 10nm so.


Der Vergleich 20A mit N3B wird interessant bei ARL-S. Die non-K kommen allerdings wieder später raus. Dieses Jahr wird man wohl nur N3B Chips bekommen.

[mocad_tom]

In Clearwater Forest (die Compute Tiles sind in 18A) sind aber keine Memory-Controller in den Compute-Tiles.

Ich vermute, dass da einfach nur eine etwas bessere SRAM-Bibliothek drin sein wird.

Ansonsten wird das aber ziemlich vergleichbar mit 20A sein.
Es würde mich wunder, wenn vom Arrow Lake Compute Tile (in 20A) zum Clearwater Forest Compute Tile so viel an Performance dazu kommt.

6P-Cores und 8E-Cores bei Arrow Lake
24E-Cores bei Clearwater Forest

Das wird nicht mal größer

[ryan]

In Clearwater Forest (die Compute Tiles sind in 18A) sind aber keine Memory-Controller in den Compute-Tiles.

Ich vermute, dass da einfach nur eine etwas bessere SRAM-Bibliothek drin sein wird.

Ansonsten wird das aber ziemlich vergleichbar mit 20A sein.
Es würde mich wunder, wenn vom Arrow Lake Compute Tile (in 20A) zum Clearwater Forest Compute Tile so viel an Performance dazu kommt.

6P-Cores und 8E-Cores bei Arrow Lake
24E-Cores bei Clearwater Forest

Das wird nicht mal größer


Ich verstehe dein Beitrag nicht. Die 10% beziehen sich auf die von Intel angegeben +10% bei der perf/w zwischen 20A und 18A. Das ist kein Chipvergleich.

Der Vergleich Arrow Lake und Clearwater Forest ist mir auch nicht klar, weil völlig andere Segmente mit einer sehr unterschiedlichen CPU Kernanzahl und einer neuen E-core Generation. Da wäre es noch sinnvoller Panther Lake als Vergleich zu nehmen, das ist wenigstens ein Chip für Consumer mit einer Kernanzahl, die viel näher an 6+8 dran ist.

Auch ganz interessant:

https://twitter.com/aschilling/status/1762518915643531444/photo/2


Was fällt auf? Sehr begrenzte Wafer Kapazität von Intels EUV Fertigung bis 2025-2026.

Es sollte keinen überraschen, dass Lunar Lake komplett von TSMC gefertigt wird und Arrow Lake bis auf das eine 6+8 CPU tile auch von TSMC. Über die Performance von 20A kann man daraus keine Rückschlüsse ziehen, wohl aber über die Kapazität.

[Leonidas]

Arrow Lake Infos von Golden Pig Upgrade:
https://www.3dcenter.org/news/news-des-4-maerz-2024

[ashantus]

. Es werden diverse „Nachfolger“ gehandelt, aber meines Wissens hat sich bisher nichts Handfestes und / oder umsetzbares ergeben.

Der Nachfolger von Silizium sind die Quantencomputer.

[MiamiNice]

Der Nachfolger von Silizium sind die Quantencomputer.

Der Nachfolger eines Werkstoffes ist also ein komplettes Produkt. Da bin ich gespannt :)

[Exxtreme]

Der Nachfolger von Silizium sind die Quantencomputer.

Wahrscheinlich nicht. Quantencomputer sind viel zu langsam. Ausser man will massivst parallelisieren. Und da fallen Computerspiele schonmal raus.

[Zossel]

Traditionell lief ein refresh nach einem full node shrink deutlich besser, was die Leistung oberhalb angeht. Das war bei 14nm und bei 10nm so.

Ein "Fullnodesprung" wäre x/√2.

[Platos]

Wahrscheinlich nicht. Quantencomputer sind viel zu langsam. Ausser man will massivst parallelisieren. Und da fallen Computerspiele schonmal raus.

Was ist denn mit Photonen-logik-Prozessoren?


Also ich meine nicht Quantencomputer mit verschränkten Photonen.

[Exxtreme]

Was ist denn mit Photonen-logik-Prozessoren?



Theoretisch sollten sie besser sein. Ob das praktisch auch stimmt, keine Ahnung. Wird wohl auch schwer etwas hinzubekommen was auf einem technisch ähnlichen Level ist wie die Produktion bei TSMC.

[Exxtreme]

Was ist denn mit Photonen-logik-Prozessoren?



Theoretisch sollten sie besser sein. Ob das praktisch auch stimmt, keine Ahnung. Wird wohl auch schwer aus dem Stand heraus etwas hinzubekommen was auf einem technisch ähnlichen Level ist wie die Produktion bei TSMC.

[mocad_tom]

Auf den Arrow Lake mit 6P-Cores + 8 E-Cores in Intel 20A wird sich die Konkurrenz stürzen und zerlegen.

Ich hoffe wir sehen ihn noch dieses Jahr.

Man sieht ja auch bei diesem Waferstarts-Chart, Intel will den Intel 3 Prozess eigentlich nur für die Base-Dies für Intel 18A hernehmen.

Klar werden da auch ein paar Granite Rapids und Sierra Forest gefertigt - aber richtig Volumen auf Intel 3 kommt erst drauf, während Intel 18A im Gleichtakt mit hochzieht.

https://twitter.com/aschilling/status/1762518915643531444/photo/2

Wenn man sich die Kurve so anschaut, dann wird schon klar warum Intel so viele Waferstarts bei TSMC bestellen musste.
Es kommt jetzt eine Delle mit Waferstarts in den eigenen Fabs.