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

[ryan]

https://abload.de/img/roadmaprqjm4.png
Intel
(https://www.intel.com/content/dam/www/central-libraries/us/en/documents/2022-intel-investor-meeting-process-tech.pdf)
https://abload.de/img/lga-1851-1920x1031cnkj3.jpg
Benchlife (https://benchlife.info/arrow-lake-s-and-meteor-lake-s-will-take-lga-1851-after-raptor-lake-s/)

Alte Roadmap (https://twitter.com/AdoredTV/status/1496217229922291715) von ARL-P 6+8+3:

https://abload.de/img/fmohnpmwuaav_wrtkk33.jpg (https://abload.de/image.php?img=fmohnpmwuaav_wrtkk33.jpg)


GPU Info vom Testtreiber (https://twitter.com/_rogame/status/1471560689886052354):

xe_hpg_core\embargo\hw_info_arl.cpp
Intel Rasty Renderer - ARL_6x4x16 / Xe LPG Plus


Möglicherweise 8+32 Tile fürs Highend.

Will feature an updated compute tile with 8/32 config for the high end enthusiast products.
https://videocardz.com/newz/intel-arrow-lunar-and-nova-lake-codenames-appear-in-a-leak-as-meteor-lake-successors


More detail is that.
In the MSDT platform, Meteor lake maybe is the mid and low-end product, and Arrow lake act as the high-end product.
About Lunar lake, it is the codename of one low-voltage product.
https://twitter.com/OneRaichu/status/1533759998186393600


For desktop,
High end, ARL-S,
mainstream, MTL-S.
https://twitter.com/kopite7kimi/status/1533783931044376576

[Leonidas]

3DC News-Index zu Intel "Arrow Lake"
https://www.3dcenter.org/news/intel-arrow-lake

[ryan]

Intel will be starting a new uarch line, starting in ARL, called the molecule line of cores, it will be a replacement for the current "Core" line, will likely keep the "cove" naming scheme as core for consumer facing uses
https://twitter.com/wowpople/status/1544453314414317572
https://twitter.com/_wildc/status/1544768179825774602/photo/1

[HOT]

Na dann bin ich mal gespannt, was daraus wird :popcorn:

[Pirx]

"ultra low power performance"?:lol:

ach und nicht mehr "glued together", sondern "disaggregated":lol:

[HOT]

Man versucht halt das "Ultra low Performance" zu verstecken :cool:

[robbitop]

Naja das eine geht mit dem anderen Hand in Hand. Die aktuellen E-Cores sind von ihrer Auslegung IMO viel zu nah an den P-Cores ausgelegt, so dass die Skalierung bzw Spreizung der Leistungsaufnahme sehr begrenzt ist. Schaut man sich das an, wie es bei ARM oder Apple läuft, so sind die kleinen Cores wirklich deutlich langsamer als die großen. Dafür aber überproportional sparsamer. Einfach aufgrund der groß genugen Spreizung der Auslegungspunkte. So funktioniert die Skalierung der Leistungsaufnahme über eine viel größere Spreizung. Wie ein Getriebe an einem Verbrennungsmotor. Und genau wie bei einem Getriebe kann man die Spreizung weiter erhöhen, in dem man mehr Auslegungspunkte wählt (hier Core Typen).
Die super kleinen Kerne sind dann wahrscheinlich nur sinnvoll für background tasks (und könnten auch energieeffizientes Standby mit Autoupdates und notifications im x86 Bereich ermöglichen). Die mittleren Kerne müssen schon ein wenig Grundleistung liefern, damit sie in Sidetasks von echten Anwendungen dann nicht doch zum Bottleneck werden. Wahrscheinlich ist das ein Grund warum die E-Cores bis dato nicht ganz so weit entfernt von den P-Cores ausgelegt waren. Ich kann mir aber gut vorstellen, dass man die Umsetzung der E-Cores sicherlich aber auch noch besser hinbekommen kann.

[ChaosTM]

"Our leadership Roadmap" - Hybris again.
Würde mich ja freuen, wenn sie die kommenden Nodes alle zeitgerecht hinkriegen, nur mir fehlt leider der Glaube.

[ryan]

Naja das eine geht mit dem anderen Hand in Hand. Die aktuellen E-Cores sind von ihrer Auslegung IMO viel zu nah an den P-Cores ausgelegt, so dass die Skalierung bzw Spreizung der Leistungsaufnahme sehr begrenzt ist. Schaut man sich das an, wie es bei ARM oder Apple läuft, so sind die kleinen Cores wirklich deutlich langsamer als die großen. Dafür aber überproportional sparsamer. Einfach aufgrund der groß genugen Spreizung der Auslegungspunkte. So funktioniert die Skalierung der Leistungsaufnahme über eine viel größere Spreizung. Wie ein Getriebe an einem Verbrennungsmotor. Und genau wie bei einem Getriebe kann man die Spreizung weiter erhöhen, in dem man mehr Auslegungspunkte wählt (hier Core Typen).
Die super kleinen Kerne sind dann wahrscheinlich nur sinnvoll für background tasks (und könnten auch energieeffizientes Standby mit Autoupdates und notifications im x86 Bereich ermöglichen). Die mittleren Kerne müssen schon ein wenig Grundleistung liefern, damit sie in Sidetasks von echten Anwendungen dann nicht doch zum Bottleneck werden. Wahrscheinlich ist das ein Grund warum die E-Cores bis dato nicht ganz so weit entfernt von den P-Cores ausgelegt waren. Ich kann mir aber gut vorstellen, dass man die Umsetzung der E-Cores sicherlich aber auch noch besser hinbekommen kann.



Das Problem ist vor allem die Spannung, es gibt nur eine voltage rail für beide Kerne. Selbst wenn die E-Kerne viel niedriger takten würden als derzeit, wäre der Effekt überschaubar. Dazu kommt der hohe Uncore Verbrauch bei Alder Lake, der Idle Verbrauch bei Alder Lake-H/P liegt höher als bei Tigerlake. Bei Meteor Lake soll der Fokus auf Effizienz liegen, gut möglich das sie die groben Schwachpunkte mit der Generation beseitigen.

Lunar Lake ist low power mobile only, davon geht man aus. Also mehr sowas wie ein Lakefield Nachfolger und wahrscheinlich nichts für den Desktop. Ultra low power performance macht Sinn in dem Kontext. Die P+E Architektur ist ja auch gleich zu Arrow Lake.

Bei Arrow Lake gehen die Gerüchte wieder weg von Intel 20A und hin zu TSMC N3B. Vorteil wäre, das dann Arrow Lake bei der Fertigung wohl in H1 2024 möglich wäre anstatt erst in H2 2024. Abwegig ist das nicht, weil ARL-P in der alten Roadmap ja auch komplett TSMC 3nm gewesen ist.

Die Performance Sprünge nach Meteor Lake sollen größer und größer werden. Wird spannend die nächsten Jahre.


From what I can tell. Among our plans for continued processor improvements in the coming generations, we're working hard on the Next Big Thing, things you'll see in the future. Meanwhile in the coming years you will see Raptor Lake and Meteor Lake and then you will see bigger and bigger jumps.
Chief Architect Performance Core (https://hwzone-co-il.translate.goog/main-computers/%D7%9C%D7%94%D7%92%D7%95%D7%AA-%D7%90%D7%AA-%D7%94%D7%93%D7%91%D7%A8-%D7%94%D7%92%D7%93%D7%95%D7%9C-%D7%94%D7%91%D7%90-%D7%A8%D7%90%D7%99%D7%95%D7%9F-%D7%A2%D7%9D-%D7%94%D7%90%D7%97%D7%A8%D7%90/?_x_tr_sl=iw&_x_tr_tl=en&_x_tr_hl=de&_x_tr_pto=wapp)

[Pascal2508]

Die Performance Sprünge nach Meteor Lake sollen größer und größer werden. Wird spannend die nächsten Jahre.

Chief Architect Performance Core (https://hwzone-co-il.translate.goog/main-computers/%D7%9C%D7%94%D7%92%D7%95%D7%AA-%D7%90%D7%AA-%D7%94%D7%93%D7%91%D7%A8-%D7%94%D7%92%D7%93%D7%95%D7%9C-%D7%94%D7%91%D7%90-%D7%A8%D7%90%D7%99%D7%95%D7%9F-%D7%A2%D7%9D-%D7%94%D7%90%D7%97%D7%A8%D7%90/?_x_tr_sl=iw&_x_tr_tl=en&_x_tr_hl=de&_x_tr_pto=wapp)
Arrow Lake To Bring 30% IPC Improvement Over Meteor Lake With Lion Cove Cores (https://wccftech.com/intel-royal-core-era-arrow-lake-lunar-lake-nova-lake-lion-cove-panther-cove-cpu-architecture-tackle-amd-zen-5/)

Würde hervorragend zu den bisherigen Gerüchten passen.

[Linmoum]

Lunar Lake ist aber auch erst 2025, dazwischen liegt noch ARL.

IPC-Steigerungen sind irgendwann aber auch das einzige, was noch bleiben wird. Da kommen nicht plötzlich 7GHz aus dem Nichts, mit denen man die (SC)-Performance noch zusätzlich steigern kann. Würde mich nicht wundern, wenn jetzt erstmal bei 5.5-6GHz auf absehbare Zeit Schluss ist.

[ChaosTM]

Naja, man wird wohl noch mehr in die Breite gehen müssen, nur schlägt da wieder das Gesetz des abnehmenden Grenzertrags zu.
Außer man erzielt auf der Softwareseite gröbere Durchbrüche. Da könnte noch einiges gehen.

20-30% IPC Fortschritte sind auch nicht ewig machbar.
Moore`s Law wird sich immer weiter verlangsamen (müssen).

[ryan]

Lunar Lake To Bring 30% IPC Improvement Over Meteor Lake With Lion Cove Cores (https://wccftech.com/intel-royal-core-era-arrow-lake-lunar-lake-nova-lake-lion-cove-panther-cove-cpu-architecture-tackle-amd-zen-5/)

Würde hervorragend zu den bisherigen Gerüchten passen.


Zu welchen Gerüchten? Die Gerüchte besagen, dass Lunar Lake nur ein low power Produkt wird, zum Beispiel hier: https://twitter.com/OneRaichu/status/1533759998186393600

Die Erwähnung von Ultra low power in der Intel Folie ist sicher kein Zufall.

Der reddit Leak (https://videocardz.com/newz/intel-arrow-lunar-and-nova-lake-codenames-appear-in-a-leak-as-meteor-lake-successors) ist dir bekannt btw? Arrow Lake und Lunar Lake setzen auf die gleiche P+E Architektur.

MLID erzählt ein wenig dünnes. Das mit dem Royal Core Projekt stimmt, kommt aber wohl erst mit Nova Lake. Nichtsdestotrotz kann Arrow Lake ein fetter Tock werden, das erwarte ich ja auch und passt zu der Aussage vom Chefarchitekt.

[basix]

Naja, man wird wohl noch mehr in die Breite gehen müssen, nur schlägt da wieder das Gesetz des abnehmenden Grenzertrags zu.
Außer man erzielt auf der Softwareseite gröbere Durchbrüche. Da könnte noch einiges gehen.

20-30% IPC Fortschritte sind auch nicht ewig machbar.
Moore`s Law wird sich immer weiter verlangsamen (müssen).

Genau deswegen werden die zukünftigen Chips Accelerators für entsprechende Tasks beherbergen. Siehe Multimedia Engines, AES-Encryption und Co. sowie die Apple M1/M2 Derivate. Dort geht die Reise hin.

[ChaosTM]

Ja, dort geht die Reise hin, aber kaum unter x64/86.

[basix]

Wieso nicht?

[ChaosTM]

Zu viele Altlasten, die man mit schleppen muss.

Das eigentlich schon 3+ Jahre alte Fugaku ARM Design war 2+ Jahre lang der effizienteste Supercomputer, bis Epic kam..

[Pascal2508]

Zu viele Altlasten, die man mit schleppen muss.

Das eigentlich schon 3+ Jahre alte Fugaku ARM Design war 2+ Jahre lang der effizienteste Supercomputer, bis Epic kam..
Warum wohl? Der HBM-Speicher sitzt direkt mit auf dem Package, ähnliches macht Apple mit seinen M-Prozessoren auch ^^
Ist nun mal deutlich effizienter, aber auch teurer in der Herstellung.

[ryan]

[Rumor]
Arrow lake-S TSMC N3 series process.
Arrow lake-P INTC 20A series process.
https://twitter.com/OneRaichu/status/1583277425944690688


Ein Vorteil hätte es, TSMC 3nm wäre eher verfügbar als Intel 20A. Mit ersten 20A CPUs ist nicht vor H2 2024 zu rechnen. TSMC 3nm sollte in H1 2024 kein Problem sein.

[iamthebear]

Und Intel designed denselben Compute Kern mit all der vermurksten Sonderlogik sowohl für einen eigenen Prozess als auch für einen Fremdprozess?
Ich glaube da friert zuerst die Hölle zu bevor Intel einen Compute Die außer Haus fertigen lässt.

Abgesehen davon ist es nicht unbedingt schlau denselben Chip sowohl in eigener als auch in fremder Fertigung anzubieten. Ist TSMCs Die besser so ist Intels Foundrybusiness tot. Ist Intels Die besser so verkauft sich die TSMC Variante nicht, da Intel offensichtlich keine TSMC Dies bauen kann.

Was möglich ist:
ARL-S: Intel 3 mit Compute + kleine iGPU in einem
ARL-P: Intel 20A + N3 iGPU, da 20A keine vollständigen Libraries hat.
Und IO/SOC Die kommen von TSMC

[ryan]

Und Intel designed denselben Compute Kern mit all der vermurksten Sonderlogik sowohl für einen eigenen Prozess als auch für einen Fremdprozess?


Warum denn nicht? Intel hatte doch nach dem Icelake 10nm Debakel angekündigt, dass sie zukünftig ihre CPU Designs nicht mehr abhängig auf einen Prozess machen wollen. Und diese Flexibilität ist bei zukünftigen Chiplet Designs nur logisch. Auch haben wir in der Roadmap schon gesehen, dass Lion Cove in ADL-P für TSMC 3nm geplant gewesen ist, das heißt Intel hat von Anfang an sowieso TSCM 3nm mit im Plan gehabt beim Compute Kern Design. Neu ist das nicht.



Abgesehen davon ist es nicht unbedingt schlau denselben Chip sowohl in eigener als auch in fremder Fertigung anzubieten.


Warum sollte das nicht schlau sein? Das kann sogar sehr schlau sein.



Ist TSMCs Die besser so ist Intels Foundrybusiness tot. Ist Intels Die besser so verkauft sich die TSMC Variante nicht, da Intel offensichtlich keine TSMC Dies bauen kann.


20A kommt später, möglicherweise viel später. Mit TSMC 3nm können sie ARL-S früher bringen als das mit Intel 20A möglich gewesen wäre. Ob TSMC 3nm besser ist, ist überhaupt nicht gesagt.




Was möglich ist:
ARL-S: Intel 3 mit Compute + kleine iGPU in einem
ARL-P: Intel 20A + N3 iGPU, da 20A keine vollständigen Libraries hat.
Und IO/SOC Die kommen von TSMC


Intel 3 ist ein server only node. Bis jetzt gibt es keinerlei Hinweise das dem nicht so wäre.

[dildo4u]

Natürlich ist es Klug eine ausweich Strategie zu haben, TSMC hat jetzt Erfahrung mit X86 Modelle über 200 Watt.
Einfach überlegen wie viel Kohle Apple und AMD in die Fertigung stecken, Intel wäre Blöd wenn sie sich das nicht zu nutzen machen.

[Thomas Gräf]

Würde es TSMC wünschen das Intel bei denen bucht, aber eher aus weltpolitischen Gründen.
Aber auch aus technischer Sicht kann man TSMC nicht mehr wegdenken.

[Edgecrusher86]

WCCFTech: Intel Desktop Meteor Lake-S CPUs To Feature Up To 22 Cores, Arrow Lake-S Up To 24 Cores, Quad Xe iGPU Cores & 125W TDPs (https://wccftech.com/intel-14th-gen-meteor-lake-s-22-cores-15th-gen-arrow-lake-s-24-cores-desktop-lga-1851-platform/)

[HOT]

Interessant. Also ist ARL wieder nur ein Die, wie bei RKL und RPL. Endlich ist auch dieser BS mit den 32 E-Cores Geschichte.
Bin mal gespannt, wie ein MTL mit 6+16 abschneidet.

[iamthebear]

Ich bin mal gespannt, ob MTL und ARL im Desktop überhaupt so released werden. Für mich riecht das eher nach Broadwell 2.0, wo man nur Mobile launched und als Alibi ein paar Desktopmodelle mitliefert.

[Nightspider]

Es steht und fällt halt wie immer bei Intel mit dem Prozess.

Bei Sapphire Rapids gibts ja aktuell wieder die Gerüchte, das die Yields aktuell noch extrem mies sind mit 50-60%.

Wer weiß wie gut der Intel 4 Prozess gerade oder in einem Jahr läuft.

[konkretor]

Bei solchen 50 bis 60 % yield rate immer eine Quelle angeben.

https://www.computerbase.de/2022-11/intel-xeon-sapphire-rapids-steht-im-stau-teil-3/
Das Thema passt eigentlich hier gar nicht rein.

Wie gut es aufgeht das Design nicht an einen Prozess festzunageln muss sich noch zeigen. Dadurch verliert man unterumständen gewisse Vorteile die man hatte weil man es genau an den Prozess angepasst hat.

[ryan]

WCCFTech: Intel Desktop Meteor Lake-S CPUs To Feature Up To 22 Cores, Arrow Lake-S Up To 24 Cores, Quad Xe iGPU Cores & 125W TDPs (https://wccftech.com/intel-14th-gen-meteor-lake-s-22-cores-15th-gen-arrow-lake-s-24-cores-desktop-lga-1851-platform/)



Es würde zu den Gerüchten passen, wonach MTL-S das lowend bis midrange abdecken soll und ARL-S für das highend kommt. Mit 6P Kerne könnte MTL-S die i5 von ADL/RPT ablösen (also maximal i5-13600K) und noch +4-8E Kerne drauflegen. 16E Kerne wären überraschend viel für das i5 lineup, würde aber natürlich die MT performance stark pushen. MTL-S ist 2024 Generation, also darf man schon was erwarten.

Die i7 und i9 Raptor Lake mit 8P Kerne werden wiederum von ARL-S abgelöst. ARL-S legt keine E-Kerne drauf (angenommen es stimmt), dafür sind die P+E Architekturen neuer. 4 Xe cores sind 64 EUs, also quasi eine GT1. Die GT2 von MTL-P hat 128 EUs.

[Platos]

Ich bin mal gespannt, ob MTL und ARL im Desktop überhaupt so released werden. Für mich riecht das eher nach Broadwell 2.0, wo man nur Mobile launched und als Alibi ein paar Desktopmodelle mitliefert.

Sieht für mich Analog nach Ice Lake/Tigerlake aus usw. an. Also Desktop weiterhin lange alter Prozess und mobile 10nm. Nur jetzt eben mit Tiles und nicht Tiles.

Desktop wieder am Brute-Forcen.

Aber dass Arrowlake keine 32 E-Cores kriegt, war ja irgendwie abzusehen.

[HOT]

Es würde zu den Gerüchten passen, wonach MTL-S das lowend bis midrange abdecken soll und ARL-S für das highend kommt. Mit 6P Kerne könnte MTL-S die i5 von ADL/RPT ablösen (also maximal i5-13600K) und noch +4-8E Kerne drauflegen. 16E Kerne wären überraschend viel für das i5 lineup, würde aber natürlich die MT performance stark pushen. MTL-S ist 2024 Generation, also darf man schon was erwarten.

Die i7 und i9 Raptor Lake mit 8P Kerne werden wiederum von ARL-S abgelöst. ARL-S legt keine E-Kerne drauf (angenommen es stimmt), dafür sind die P+E Architekturen neuer. 4 Xe cores sind 64 EUs, also quasi eine GT1. Die GT2 von MTL-P hat 128 EUs.

Ist Unsinn, das sind 2 Generationen, MTL 14k und ARL 15k. Nur LNL soll ne mobile Erdgänzung sein.

[Edgecrusher86]

LNL kommt nicht für den Desktop? NL erst? :confused:

[ryan]

Ist Unsinn, das sind 2 Generationen, MTL 14k und ARL 15k. Nur LNL soll ne mobile Erdgänzung sein.


Wie kommst du darauf? Es spricht deutlich mehr dafür als dagegen. Und LNL hat damit überhaupt nichts zu tun, das ist eine mobile low power Variante.

[HOT]

https://www.pcworld.com/article/834401/intels-lunar-lake-will-be-a-specialized-low-power-pc-chip.html
LNL ist quasi ein Lakefield-Nachfolger.

https://www.tweaktown.com/news/84674/intel-confirms-next-gen-15th-core-arrow-lake-cpus-for-2024/index.html
die zweite Folie. ARL ist gen 15.

[ryan]

[url]https://www.tweaktown.com/news/84674/intel-confirms-next-gen-15th-core-arrow-lake-cpus-for-2024/index.html
die zweite Folie. ARL ist gen 15.


Dort steht nicht von MTL-S und dort steht auch nichts von einer 15th generation.

[HOT]

Dort steht nicht von MTL-S und dort steht auch nichts von einer 15th generation.

Das impliziert die Folie. Außerdem, wie stellst du dir das vor? Soll Intel jetzt 2 Generationen ohne neuen S auskommen? Klar ist ARL 15. Gen.

Ende 2023 -> MTL-S
Ende 2024 -> ARL-S

Wie soll das denn sonst gehen?




Gibt übrigens neuere Gerüchte, dass 20A mal wieder hinter den Erwartungen zurückbleibt und die angepeilten Taktraten nicht schafft:
https://appuals.com/intel-ditching-own-20a-process/

ARL-P ist natürlich Unsinn, den gibts nicht, dafür gibts ja LNL.

Es gab mal ein Gerücht, dass MTL-S nur aus 2 Chiplets bestehen soll, hat das noch einer auf dem Schirm? Ich hab irgendwie den Verdacht, dass da bei TPU mal wieder Mobil und Desktop in einen Topf geschmissen wurde.

[davidzo]

Es gab mal ein Gerücht, dass MTL-S nur aus 2 Chiplets bestehen soll, hat das noch einer auf dem Schirm? Ich hab irgendwie den Verdacht, dass da bei TPU mal wieder Mobil und Desktop in einen Topf geschmissen wurde.

Von dem 2-Chip Gerücht habe ich aber auch noch nichts gehört.
Es sind bisher vielmehr mindestens 3 mobile packages bekannt die alle auf 4+1 Tiles setzen. Gesehen haben wir bisher zwei verschiedene compute DIEs mit 2+8 und 6+8. Von 6+16 ist bisher noch nichts zu sehen.
Das 6+8 Compute Die ist vergleichbar groß wie das 8C Zen4 compute Die.

Afaik gibt es ja aber schon länger das Gerücht dass MTL-S vielleicht nur eine high power Mobilversion ist und erst mit ARL wieder etwas für den richtigen Desktop kommt.
Wäre aber komisch, denn -S heißt eigentlich Desktop, siehe ADL-S und RTL-S und high power mobile wäre die -H Serie wie bei TGL-H. Bei ADL gab es aber relativ spät dann auch eine sogenannte S-bga Version (8+8+32). Vielleicht wird das sowas.
5-125W wiederum spricht für eine mobile only bzw. maximal mainstream Desktop CPU.

Von einer kleineren GT1 oder GT0 IGP Variante, die bei Desktop sinnvoll wäre als die große Mobil GPU mit zu schleppen ist auch noch nichts zu sehen. Bisher nur den GT2 (23mm2) und GT3 (ca. 40mm2)Die gesehen. Der größere der beiden GPU-DIEs wird wohl die 192EU Variante sein und durch TSMCs cutting-edge N3B sicher nicht billig sein.

Vielleicht verbirgt der riesige TSMC N6 SOC-DIE neben Quicksync Media Engine auch GPU-Teile wie die Display Engine und eine deaktivierbare minimal-IGP? Dann würde eine 2+1 Tile Version für den Desktop Sinn machen.
Der i/o Teil enthält dann wohl nur noch thunderbolt und ggf. mobilen minimal-i/O Komponenten wie usb, Sound und CO den man im Desktop eher im Chipset integriert.

[ryan]

Das impliziert die Folie. Außerdem, wie stellst du dir das vor? Soll Intel jetzt 2 Generationen ohne neuen S auskommen? Klar ist ARL 15. Gen.

Ende 2023 -> MTL-S
Ende 2024 -> ARL-S

Wie soll das denn sonst gehen?


Nur zum besseren Verständnis: Du erwartest MTL-S im Jahr 2023?


Die Folie impliziert erstmal nur, dass es irgendeine Version von MTL im 2023 geben wird oder soll. Wenn zum Beispiel MTL-M 2+8 im Dezember erscheint, hat die Folie seinen Zweck erfüllt. Solche Folien gehen vom ersten Modell aus mit dem die Architekur eingeführt wird. Realistisch ist, dass MTL-M/MTL-P irgendwann im zweiten Halbjahr 2023 erscheint und MTL-S ein halbes Jahr danach kommt.




Gibt übrigens neuere Gerüchte, dass 20A mal wieder hinter den Erwartungen zurückbleibt und die angepeilten Taktraten nicht schafft:
https://appuals.com/intel-ditching-own-20a-process/


Laut deinem Link kommt ARL-S in TSMC 3nm.



ARL-P ist natürlich Unsinn, den gibts nicht, dafür gibts ja LNL.


Wieso sollte es ARL-P nicht geben? Das macht überhaupt kein Sinn. ARL-P ist nicht nur low power. Das ehemalige H-Segment ist inbegriffen. Lunar Lake ist ein Ultra-Low-Power-Design, das ist ganz sicher nicht ARL-P Segment, sondern allerhöchstens ARL-U.

[davidzo]

Laut deinem Link kommt ARL-S in TSMC 3nm.


ARL-S vielleicht, ist aber ein sehr neues Gerücht. Erstmal kommen sowieso ARL-P, H. Die Folien zur ARL zeigen ja bisher nur mobile Designs mit mittlerem package, insofern würde ich das als gesetzt sehen dass ARL auch als mobile kommt. Vielleicht nicht als U-Variante wenn LNL kurz danach kommt.

Laut Intels Hot Chips Präsentation die keine 2 monate alt ist kommt ARL-S in Intel 20A + external. Dazu das Bild vom Mobile package auf derselben Folie.

Da wir bei MTL schon Leaks dazu haben die besagen dass die Top-GPU mit 192EU in TSMC N3B kommt, würde ich davon ausgehen dass sich die TSMC N3 Hinweise wieder auf die GPU beziehen. Vielleicht hat das ein Leaker falsch verstanden und glaubt nun dass Intel beim CPUteil gewechselt ist. Wenn dann wäre es schon wirklich sehr spät im Entwicklungszyklus für einen so grundlegenden Wechsel.

[Badesalz]

Gibt übrigens neuere Gerüchte, dass 20A mal wieder hinter den Erwartungen zurückbleibt und die angepeilten Taktraten nicht schafft:
https://appuals.com/intel-ditching-own-20a-process/Das kommt jetzt noch dazu, daß sie auch mit Chiplets ("Tiles") Probs haben und sich alles um 1 Jahr verschiebt? :|
Wie viele der Topleute sind eigentlich irgendwohin weggegangen als das Theater mit 10nm losging?

Zu viele Altlasten, die man mit schleppen muss.ich hab schon einige Male auf 3DC rumgefragt welche "Altlasten" das in den letzten 5 Jahren noch sein sollen, aber das konnte mir so wirklich keiner benennen. Bis heute nicht.
Ist A20-Gate noch aktuell? :D

Das eigentlich schon 3+ Jahre alte Fugaku ARM Design war 2+ Jahre lang der effizienteste Supercomputer, bis Epic kam..Epyc ;)
Wenn man sich das genauer anschaut dann wird der Fugaku einerseits mittlerweile geradezu deklassiert (Perf/Watt), andererseits scheint das aber eher an der MI250X zu liegen als nur an dem "AMD Optimized 3rd Generation EPYC 64C 2GHz" mit dem sie überall die Aldebarans bedienen.

[BlacKi]

Nur zum besseren Verständnis: Du erwartest MTL-S im Jahr 2023? imho zu lange ohne erneuten zwischenschieber.


das sind mindestens 1 1/4 jahre gen to gen. ich glaub nicht dran. selbst raptor war ja nicht geplant und end 23 für mtl ist schon ein delay.

[ryan]

ARL-S vielleicht, ist aber ein sehr neues Gerücht. Erstmal kommen sowieso ARL-P, H. Die Folien zur ARL zeigen ja bisher nur mobile Designs mit mittlerem package, insofern würde ich das als gesetzt sehen dass ARL auch als mobile kommt. Vielleicht nicht als U-Variante wenn LNL kurz danach kommt.


Warum kommen ARL-P/H vorher? Ich denke es ist dann wieder umgedreht, siehe ADL-S. Wenn es stimmt mit Desktop TSMC 3nm und Notebook Intel 20A deutet das sehr stark darauf hin. TSMC 3nm ist eher dran.



Laut Intels Hot Chips Präsentation die keine 2 monate alt ist kommt ARL-S in Intel 20A + external. Dazu das Bild vom Mobile package auf derselben Folie.

Sie haben explizit von ARL-S gesprochen? Dann gib mal den Link.



Da wir bei MTL schon Leaks dazu haben die besagen dass die Top-GPU mit 192EU in TSMC N3B kommt, würde ich davon ausgehen dass sich die TSMC N3 Hinweise wieder auf die GPU beziehen.


MTL GT2 hat 128 EUs und kommt in TSMC 5nm. Von einer 192EU oder GT3 Variante ist nichts zu sehen. In den geleakten slides von igorslab gab es auch nur 128EUs. Und Raichu meint das Compute tile bei ARL-S, das bezieht sich nicht auf die GPU.


imho zu lange ohne erneuten zwischenschieber.


das sind mindestens 1 1/4 jahre gen to gen. ich glaub nicht dran. selbst raptor war ja nicht geplant und end 23 für mtl ist schon ein delay.


Zen 5 kommt auch erst in 2024 und schau mal wie lange es von Zen 3 zu Zen 4 gedauert hat. Die 12 Monate sind kein Gesetz.

[ryan]

After today, I will move my focus from Raptor lake to Arrow lake.
In my opinion, Meteor lake is a matter of expediency and just a little change and remakes by intel 4. Lion Cove and Skymont are more interesting.
They will use better processes, more width, and more powerful.

LNC compared to GLC.
Wide: From 6 up to 8
ROB size: From 512 to 700+
https://twitter.com/OneRaichu/status/1588767528360501248


Laut Raichu geht Lion Cove von 6 auf 8 decoder.

[HOT]

Nur zum besseren Verständnis: Du erwartest MTL-S im Jahr 2023?


Die Folie impliziert erstmal nur, dass es irgendeine Version von MTL im 2023 geben wird oder soll. Wenn zum Beispiel MTL-M 2+8 im Dezember erscheint, hat die Folie seinen Zweck erfüllt. Solche Folien gehen vom ersten Modell aus mit dem die Architekur eingeführt wird. Realistisch ist, dass MTL-M/MTL-P irgendwann im zweiten Halbjahr 2023 erscheint und MTL-S ein halbes Jahr danach kommt.
[...]
Best Case. Will heißen, Intel plante selbst sicherlich mit MTL-S Ende 23 (MTL-P sollte ja schon Mitte 23 soweit sein) und ARL-S Ende 24, steht ja auch noch auf den Folien. Das wird natürlich so nicht kommen, aufgrund der Tile-Probleme. Ein realistischerer Starttermin für MTL-S ist wohl Frühjahr 2024 und ARL in 25, es ist eben einfach BS anzunehmen, dass ARL sowas wie die High-End-Variante von MTL ist. Das ergibt einfach keinen Sinn. Warum sollte man dem einen neuen Namen geben? Und 20A ist einfach noch seehr weit weg in der Praxis. Nein, das ist der übliche Generations-Refresh, wie Rocket Lake zu Comet Lake oder Raptor Lake zu Alder Lake.
Intel plante 2023 mit Intel4. Daraus wird ja jetzt nur bedingt was, wie es aussieht, kommt zudem auch noch Granite Rapids in Intel 7 erst in 24, die Verschiebung ist offiziell. Du hast also nach bisherigem Stand:

Ende 23 -> MTL-P (I4)
Frühjahr 24 -> MTL-S (I4)
Mitte 24 -> GR (evtl.ER) (I7)

Wenn alles nach plan laufen würde, folgt daraus dann für die Nachfolge:

Ende 24 -> MTL-P Refresh oder ARL-P oder sowas
Frühjahr 25 -> ARL-S und LNL-P(?) (20A)
Mitte 25 -> DR (I3)

26FF -> NVL

Intels Plan von 2021 ist ja schon ganz gehörig durcheinandergeraten.
eigentlich sollte MTL-P im Frühjahr 2023 kommen, SR Ende 21, GR Mitte 23 usw. Theorie und Praxis.

[ryan]

Best Case. Will heißen, Intel plante selbst sicherlich mit MTL-S Ende 23 (MTL-P sollte ja schon Mitte 23 soweit sein) und ARL-S Ende 24, steht ja auch noch auf den Folien. Das wird natürlich so nicht kommen, aufgrund der Tile-Probleme. Ein realistischerer Starttermin für MTL-S ist wohl Frühjahr 2024 und ARL in 25, es ist eben einfach BS anzunehmen, dass ARL sowas wie die High-End-Variante von MTL ist. Das ergibt einfach keinen Sinn. Warum sollte man dem einen neuen Namen geben?


Hältst du es denn für realistisch, dass Intel eine neue Plattform mit CPUs vorstellt, die langsamer ist als die alte Plattform? Und wie realistisch wäre es in dem Fall, wenn dann wirklich 1 Jahr dazwischen liegen würde bis die neue Platform die alten Raptor Lake CPUs überbieten kann? Wo bliebe der Anreiz für eine neue, teure Plattform, dazu wahrscheinlich DDR5 only? Das musst du dir durch den Kopf gehen lassen. Vielmehr würde es Sinn ergeben und ins Schema passen, wenn Intel Die CPUs mischt. Bringen sie ARL-S nur als higher end Variante, können sie sich 3nm/20A Kapazitäten sparen. Intel 4 alleine hätte auch nicht das benötigte Volumen. Eine zweigleisige Strategie macht sehr viel Sinn. Broadwell DT kam damals 2 Monate vor Skylake raus. So ein Szenario ist nicht unrealistisch.

[HOT]

Wer sagt denn, dass das langsamer wird? MTL bekommt sowohl neue Cove als auch neue Mont-Kerne. Da wird schon ordentlich Mehrleistung bei rumkommen, da mach ich mir wenig Sorgen.
ARL wird dann der nächste große Sprung.
Broadwell ist einfach nicht vergleichbar. Broadwell sollte im Frühjahr 2014 kommen. Ivy -> 2012 22nm, Haswell -> 2013 22nm und dann Broadwell -> 2014 14nm, Skylake -> 2015 14nm und danach eigentlich Cannon Lake -> 2016 10nm, Ice Lake 2018 10nm. Tick Tock eben.

MTL ist nicht so stark verspätet und Intel hat die Strategie geändert. Der Jahrestakt sollte wieder hergestellt werden, dafür aber nicht jedes Mal ne komplette Generation, sondern neue Fertigung (14nm) -> Generation (Comet Lake) -> Refresh-Die (Rocket Lake), nächste Fertigung (Intel7) -> Generation (ADL) -> Refresh-Die (RPL). Da man aber aufholen wollte, sollte ARL in einem Zwischenprozess vom Band laufen, 20A. Danach bei Nove Lake wäre es dann wieder ne neue Fertigung (18A) -> Generation (Nove Lake) -> und dann wird wieder ein Refresh-Die geplant worden sein. Leider ist der Jahrestakt wieder enorm ins stottern geraten. Ich nehme an, dass man ARL sowohl in N3(E?) als auch in 20A entwickelt hat, also N3 als Backup Plan. Eines von beidem wird wohl Bestand haben um nicht noch weiter in die Verzögerung zu geraten.

[ryan]

Wer sagt denn, dass das langsamer wird? MTL bekommt sowohl neue Cove als auch neue Mont-Kerne.


Weil es 2 big cores weniger gibt und weil MTL eine tick release Generation ist und damit die IPC Verbesserungen eher überschaubar ausfallen. Zusätzlich taktet der 13900K sehr hoch, dass muss Intel 4 erstmal auf Anhieb erreichen. Das ist kein Selbstläufer. Selbst wenn die Kernanzahl gleich bleiben würde, wäre das nicht leicht mit einer IPC Verbesserung im Bereich einer Intel typischen Tick Generation.

[davidzo]

Warum kommen ARL-P/H vorher? Ich denke es ist dann wieder umgedreht, siehe ADL-S. Wenn es stimmt mit Desktop TSMC 3nm und Notebook Intel 20A deutet das sehr stark darauf hin. TSMC 3nm ist eher dran.

Alles was wir bisher gesehen haben sind mobile packages. Die geleakte ARL-P Folie spricht allerdings auch von "priority over ARL-S".

Vanilla N3 wird eh nicht verwendet, sondern viel eher N3E, P oder X. Vanilla N3 ist bis 2024 eh eingestampft. Und die Nachfolger sind Ende 2023 bzw. 2024 erst ready womit CPU-Produkte frühestens 12 Monate später zu erwarten sind. Jeder in der Industrie weiß dass die erste Generation von TSMC N3 zwar "on time" war, aber die Yields nicht für Volume taugen weshalb Apple auch erstmal verzichtet. N3E ist eine Entwicklung von N5 und hat yields im Auge. Für einen Desktop-prozessor wäre eher N3P (2024) oder N3X (24-25) die Wahl um auch auf gute Taktraten zu kommen.




Sie haben explizit von ARL-S gesprochen? Dann gib mal den Link.

Nicht explizit, aber von Client und es ist mit das neueste offizielle was wir zu ARL haben. Ich bin zwar dein Googlesklave :wink: aber hier. Im Gegenzug dafür schickst du mir bitte das 2-Tile Gerücht zu MTL-S von dem du sprachst!

Folie 36 - https://www.servethehome.com/intel-disaggregates-client-chips-with-meteor-lake-hc34/

Btw, was ich erstaunlich finde ist dass der Base-DIE neben capacitors auch "Memory" enthalten können soll. Das wäre in der Tat eine Neuigkeit über die noch nicht spekuliert wurde Afaik.





MTL GT2 hat 128 EUs und kommt in TSMC 5nm. Von einer 192EU oder GT3 Variante ist nichts zu sehen. In den geleakten slides von igorslab gab es auch nur 128EUs.


Macht Sinn dass im Desktop nur die kleine IGP kommt, ich denke aber 64EU macht mehr Sinn. Es gibt auf jeden Fall zwei GPU Tiles die auch unterschiedliche Interposer haben. Igorslab zeigt nur das kleinere der beiden Tiles, würde mich also nicht wundern wenn sich die Folien darauf beziehen.
Intel zeigt immer wieder auch Fotos von Packages mit einer rund doppelt so großen GPU, was sich auch mit den Floorplan Abbildungen HC34 Folien deckt. Es gibt definitiv zwei GPU DIEs.

Intel hat schon 2021 öffentlich von 96-192EUs für MTL gesprochen, insofern würde ich das mal auch als Authentisch annehmen. Auch Semianalysis glaubt an 192EU: https://www.semianalysis.com/p/meteor-lake-die-shot-and-architecture?utm_source=substack&utm_campaign=post_embed&utm_medium=web
Eine spekulierte Auflösung wäre dass in der Tat 192EUs vorhanden sind, 128 im Graphics DIE und eine Basic GPU mit 64EUs im Soc DIE wo auch die media endocer liegen. Dann hätten wir beide recht, technically wäre die performance dann aber die einer 128EU GPU. Auch würde dann ein seperates kleineres DIE für die GPU keinen Sinn machen, denn wieviele EUs soll das haben, 96?

192EU könnte auch einfach eine MTL-halo Version sein die sich womöglich verzögert.



Und Raichu meint das Compute tile bei ARL-S, das bezieht sich nicht auf die GPU.


Raichu tagged das selber als rumor, hätte er ne echte Quelle würde er das sicher anders behandeln. Allerdings gab es schon viel früher Rumor dass der CPU-Teil von ARL mobile in TSMC N3 kommt, was sich im Laufe von 2022 geändert hat.
Dass man dafür jetzt den Desktopteil zu N3 ändert wäre aber wie gesagt eine reichlich späte Entscheidung die nicht gerade dafür spricht dass ARL-S früher kommt. So spät im Entwicklungszyklus bedeutet so eine tiefgreifende Änderung eigentlich immer eine Verspätung.
Zudem steht auf der wahrscheinlich echten "Arrowlake P683" Folie was von Priorität des mobile halo Designs für Ende 2023 vor ARL-S:

- ARL halo "drive to" schedule PRQ targeting W33'23 targeting Apple Compete 14"
- ARL halo priority over ARL S
Allerdings steht da eben auch dass der CPU-Teil der mobile Halo Version in N3 kommt. Gleicher CPU-Teil wie für die Desktopversion? Dass hieße dann aber wieder nur 6+8 für ARL-S, also keine fette Desktop CPU.




Wer sagt denn, dass das langsamer wird? MTL bekommt sowohl neue Cove als auch neue Mont-Kerne. Da wird schon ordentlich Mehrleistung bei rumkommen, da mach ich mir wenig Sorgen.
ARL wird dann der nächste große Sprung.

Wie ryan sagte ist MTL eine tick Generation, bringt also in erster Linie einen neuen Node und erstmal disagregated Toles (=Chiplet). Das reicht schon an Neuheiten.
Aber darüber hinaus gibt es handfeste Dieshot Analysen von Semiaccurate die Redwood Cove mit Golden Cove vergleichen und keinen wesentlichen Zuwachs sehen. Sicher wird es Veränderungen geben, aber die großen IPC Zuwächse kommen erst mit Lion Cove, dem ersten "Royal Core".
Und auch Crestmont ist kein großes Upgrade, AVX-512 wird wohl wieder nicht dabei sein.

Ich erwarte wenn überhaupt nur einstellige IPC Zuwächse bei den Cores. Der 1T core performancegewinn wird vermutlich durch die gemunkelten Taktregressionen der neuen Intel4 Fertigung größtenteils wieder aufgefressen werden. In MT kann der niedrigere Verbrauch von N4 zuschlagen und höhere Taktraten zulassen.
Mehr IPC Zuwachs würde ich nicht von den Cores erwarten, sondern eher vom Cache Subsystem. Dadurch dass die IGP nicht mehr am L3 hängt sondern einen eigenen Cache bekommt, sind bessere latenzen gesetzt und weniger Bandbreiten-pressure. Das 6+8 Design hat wieder so wenige Ringbus stops wie zuletzt Comet lake, was sich in gut 50% besseren L3 Latencies äußern dürfte.
Der L3 ist eh die größte Baustelle bei Raptorlake, hohe Latenzen, gute Bandbreite und mittelmäßige Größe wenn man bedenkt wieviele Cores + IGP der versorgen muss. In Summe nicht mal kompetitiv zu Zen3, geschweige denn zen4.

[ryan]

Alles was wir bisher gesehen haben sind mobile packages. Die geleakte ARL-P Folie spricht allerdings auch von "priority over ARL-S".


Daraus kann man gut schlussfolgern, dass mobile MTL vor MTL-S erscheint und wahrscheinlich deutlich. Ich hatte ja schon geschrieben, dass ich MTL-S eher so ein halbes Jahr nach den Notebook Modellen erwarte. Das ist schon länger offensichtlich. Das erste gezeigte Wafer entsprach einem kleinem MTL-M mit 2+8 Kernen, auch die Software Arbeiten auf github waren lange Zeit MTL-M/P vorbehalten, er seit kurzem ist MTL-S dazugekommen.



Nicht explizit, aber von Client und es ist mit das neueste offizielle was wir zu ARL haben. Ich bin zwar dein Googlesklave :wink: aber hier. Im Gegenzug dafür schickst du mir bitte das 2-Tile Gerücht zu MTL-S von dem du sprachst!

Also haben sie nicht explizit von MTL-S gesprochen, was du impliziert hast. Und danach kann man eh nicht gehen. Das GPU tile kommt letztendlich in TSMC 5nm, obwohl Intel in der Roadmap bei MTL/ARL nur Intel 4/TSMC 3nm/Intel 20A gelistet hatte.



Macht Sinn dass im Desktop nur die kleine IGP kommt, ich denke aber 64EU macht mehr Sinn. Es gibt auf jeden Fall zwei GPU Tiles die auch unterschiedliche Interposer haben. Igorslab zeigt nur das kleinere der beiden Tiles, würde mich also nicht wundern wenn sich die Folien darauf beziehen.


Ja natürlich, es gibt GT1 und GT2 wenn man nach den github Einträgen geht. Desktop bekommt GT1, weswegen hier nur 64EUs infrage kommen, was sich mit dem Twitter Leak deckt. Für die GT2 kommen nur 128EUs infrage, was sich mit dem igorslab Leak deckt. Bei 192EUs müsste man eine GT3 erwarten.



Dass man dafür jetzt den Desktopteil zu N3 ändert wäre aber wie gesagt eine reichlich späte Entscheidung die nicht gerade dafür spricht dass ARL-S früher kommt.


Das kannst du nicht beurteilen, weil du nicht wissen kannst, wann die Entscheidung tatsächlich getroffen wurde. Der Tag an dem das zum ersten mal geleakt wird, muss nicht der Tag sein, an dem Intel die Entscheidung darüber getroffen hat.



Allerdings steht da eben auch dass der CPU-Teil der mobile Halo Version in N3 kommt. Gleicher CPU-Teil wie für die Desktopversion? Dass hieße dann aber wieder nur 6+8 für ARL-S, also keine fette Desktop CPU.


Mobile und Desktop haben nicht den gleichen Teil, u.a. die Kernanzahl unterscheidet sich. ADL-P und RPT-P sind maximal 6+8, ADL-S 8+8 und RPT-S 8+16. Es kann gut sein, dass ARL-P bei 6+8 bleiben wird, gut möglich. Muss aber nicht wenn sie von 3nm auf 20A wechseln. Genauso könnten 8+32 bei ARL-S geplant gewesen sein, der Twitter Leak sprach nur noch von 8+16. Von einem mobile Halo kann man nicht auf die Kernanzahl beim Desktop schließen, das ist Quatsch.

[ryan]

Angeblich kein SMT bei Lion Cove, betrifft Arrow Lake und Lunar Lake.


Maybe,
LNC dont support SMT....

they removed hyper-threading in the supported technologies list....

maybe only disabled on ARL/LNL
https://twitter.com/xinoassassin1/status/1676218887157997570

Exist50 (https://forums.anandtech.com/threads/intel-meteor-lake-arrow-lake-lunar-lake-discussion-threads.2606448/page-85#post-41033114) bestätigt das, kann also gut sein.

[Platos]

Sicher dass es sich hier um die P-Cores handelt und nicht um die E-Cores ?

P.s: Twitter bitte nur einbetten und nicht verlinken. Oder eben ein Bild machen.

[Edgecrusher86]

Wobei die E-Cores ja noch nie SMT konnten.

ARL-S
P-Cores: Lion Cove
E-Cores: Skymont

Eventuell macht dann ja ein Jahr später ein "KS" (Refresh) mit 8C + 32c ja doch Sinn für dann 40T total.
Es würde schon ein wenig komisch aussehen, wenn der "Ultra 9" bei ARL erst einmal nur mit 24T käme (8C/8T + 16c/16T) - nun ja, mal schauen.

[HOT]

Denke auch, dass das SMT für Lion Cove erhalten bleiben wird.
Übrigens behauptet Red, dass der 8+32 erst als ARL-Refresh erscheinen wird und es ab Launch nur 8+16 geben wiird.
Das würde ja etwas zur Fertigungssituation passen, Intel wird sicherlich 2 Dies in N3 fertigen (8+16 und 6+8) und alles weitere selber fertigen wollen.

[y33H@]

Die E-Cores aka Atom konnten ewig SMT2 als sie noch in-Order waren, erst bei Silvermont kam der Wechsel auf OoO.

[Zossel]

8+32

Welche Zielgruppe soll so eine CPU kaufen?

[amdfanuwe]

Na, als Konkurrenz zu AMDs 8 3DX + 16 c = 48 Threads

[HOT]

Angeblich ist für ARL 20A endgültig aus dem Spiel, damit wäre der Prozess endgültig tot. Wäre für nur ein Produkt ja eh unsinnig gewesen.

https://wccftech.com/intel-arrow-lake-cpus-rumored-to-drop-20a-node-utilizing-tsmc-3nm-instead/

Ich nehme an, es wird einen ARL 8+16 und 6+8 in N3B geben und einen 8+32 dann als Refresh in N3E. Damit kann man 25 und 26 überbrücken, bis man Cougar Lake (?) dann in 18A soweit hat (Panther Lake wurde ja eh gecancelt, Nova Lake und weitere gibts mMn nicht mehr. Cougar Cove soll der Nachfolgekern für Lion Cove werden, da wirds mMn auch eine Cougar Lake-Generation geben).

[KarlKastor]

Wenn überhaupt was von TSMC kommt, dann in N3E. Arrow Lake kommt eh erst H2 2024, also gibt es rein gar keinen Grund auf N3B zu setzen.

[y33H@]

Das WTF Ding strotzt nur so vor vermeintlichen Fakten ...

[HOT]

Wenn überhaupt was von TSMC kommt, dann in N3E. Arrow Lake kommt eh erst H2 2024, also gibt es rein gar keinen Grund auf N3B zu setzen.
Bedenke die Entwicklungszeit.

[KarlKastor]

Habe ich.

[mocad_tom]

Das Compute Tile für Arrow Lake für Laptops kommt mit Intel 20A.

Das Compute Tile für Arrow Lake für Desktops kommt mit TSMC N3E.

[HOT]

Sieht ja jetzt nicht mehr so aus. 20A sieht komplett tot aus. Hört man gar nichts mehr von, sind keine Produkte durchgesickert, in 20A war man offenbar bis Q2 noch im Teststadium.

Stattdessen hat Intel ja eine PowerVIA-Variante von Intel4 gebastelt:
https://www.computerbase.de/2023-06/intel-4-mit-powervia-testchip-mit-meteor-lake-e-kernen-und-neuer-stromversorgung/
Die werden das Serienreif machen und damit irgendwas fertigen. Für MTL, SF und GR wäre es dafür zu spät, die sind ja bereits in Silizium unterwegs, das würde also für deren Nachfolger relevant werden.

[y33H@]

Nein.

[HOT]

Wir werden ja sehen ;).

[dildo4u]

Es gibt doch Gerüchte das Zen 5 große Kerne nur TSMC 4nm nutzen Intel 4 plus Power Via könnte Konkurrenzfähig sein.
3nm scheint für Zen 5 C Server reserviert.

[latiose88]

ist halt die frage wird es 4nm als N4 oder N4P geben.Das macht den großen Unterschied wie gut Zen 5 so sein wird.Bei Intel wird es spannend wie gut das Intel 4 so von den Shrink her sein wird.Da Intel ja beim hohen CPU Takt bleiben will,wird es wohl durch den Shrink nur geringfügig Mehrleistung dabei entstehen.

[davidzo]

Sieht ja jetzt nicht mehr so aus. 20A sieht komplett tot aus. Hört man gar nichts mehr von, sind keine Produkte durchgesickert, in 20A war man offenbar bis Q2 noch im Teststadium.

Stattdessen hat Intel ja eine PowerVIA-Variante von Intel4 gebastelt:
https://www.computerbase.de/2023-06/intel-4-mit-powervia-testchip-mit-meteor-lake-e-kernen-und-neuer-stromversorgung/
Die werden das Serienreif machen und damit irgendwas fertigen. Für MTL, SF und GR wäre es dafür zu spät, die sind ja bereits in Silizium unterwegs, das würde also für deren Nachfolger relevant werden.

Ja, 20A scheint für ARL nicht mehr rechtzeitig zu kommen, bzw. für die meisten DIEs eh nicht interessant gewesen zu sein. Kann schon sein dass man jetzt lieber Lunarlake o.Ä. auf 20A bringt statt 18A, vorrausgesetzt man kann den Die-to-Die Pitch noch anpassen.

Der Intel4 PowerVia Prozess zeigt ja dass Backside Power delivery für den Anfang primär für mobile geeignet scheint. Wie der Thermal Response Graf von dem Testchip zeigt hat Intel das thermische Verhalten noch kaum unter Kontrolle. Teilweise ist die Wärmeableitung gleich gut oder besser als Intel4, teilweise fast doppelt so schlecht. Wenn Intel glaubt dass würde man yieldtechnisch noch groß verbessern können für 20A, dann hätte man die Häufung schlechter DIEs in dem Grafen einfach rausgebinnt und nur die guten genommen für den vergleich.
Thermal Response in line with power density increase expected from frequency scaling
- Das klingt jetzt nicht nach einer guten Botschaft sondern eher nach eine Rechtfertigung "Es ist immerhin nicht viel schlechter als erwartet".

Und das obwohl 30% der Chip Area für Thermal DOE genutzt wurde und es sich hier um E-Cores handelt, die eh keine Hohe energiedichte haben und diverse neue "Thermal Mitigation Schemes" getestet wurden. 20A soll ja nochmal deutlich mehr density haben als intel4, da würden die thermal mitigations also echt gebraucht. Die Wärmeableitung ist also ein problem, das weiß Intel und auch alle anderen. Wieso sonst sollte TSMC ihren eigenen backside power delivery prozess zuerst nur an mobile Kunden vermarkten? Das ist ein Low leakage Prozess für geringe Taktraten und geringen verbrauch, kein high performance Desktop Prozess.

Die 3Ghz Zieltaktrate sind ja auch sehr niedrig selbst für einen E-Core. Der Vergleichspunkt mit -6% Takt wären also 2,8Ghz in Intel4. Das ist weniger als Desktopchips in Intel7 aktuell bringen. Klar testchips haben immer niedrigere Taktraten, aber hier geht es nicht um ein design stepping das noch optimiert wird, sondern um ein einfaches Design welches die elektrische Charakteristik des Prozesses herausfinden soll. Solche Teile laufen mit voller Clockspeed, wo wäre sonst die Vergleichbarkeit?

Für high performance Desktop Chips klingt das nicht gut. Die +6% Takt beziehen sich ja auch auf einen fixen Punkt recht weit unten in der V/F Kurve, eben bei 1,1V. Die Wahrscheinlichkeit dass es dadrüber nicht besonders gut aussieht ist hoch weil Intel uns bewusst keine V/F Diagramme zeigt. Also bei den typischen Desktop Turbo voltages von 1,3V+ sind Intel7 und Intel4 wohl noch eine andere Liga. Was nützen einem dann die -30% Innenwiderstand, also potentiell weniger Verbrauch unter Last, wenn das Leistungsziel nicht erreicht wird? Im Desktop sind +30% Verbrauch eher verkraftbar als ein leistungsrückstand gegenüber AMD oder der Vorgängergeneration.
Erinnert mich an Cannonlake und Icelake, wo Comedy Lake den Karren für Intel aus dem Dreck ziehen musste.

[Zossel]

- Das klingt jetzt nicht nach einer guten Botschaft sondern eher nach eine Rechtfertigung "Es ist immerhin nicht viel schlechter als erwartet".

Klingt als hätte Intel nix aus dem 10nm Desaster gelernt.
Zweimal den selben Fehler zu machen kann tödlich enden.

Samsung nimmt ja auch immer den Mund recht voll, wie läuft es den bei Samsung?

[davidzo]

Ja, es wundert mich echt wieso es keinen intel4+BPD oder intel3+BPD Prozess gibt, sondern intel mal wieder zwei hochbrisante Technologien auf einmal einführen will. Gate all around ist Herausvorderung genug.

Sieht man ja an Samsung, die an GAA bereits seit 2019 herumdocktern.
Ursprünglich hat man den MCBFET, also Samsungs GAA Variante für 2020 angekündigt und in 2019 sogar das Product design Kit für 3GAE released. Und dazu gigantische performancesprünge von 35%, 50% power reduction und 45% area scaling im vergleich zu 7LPP (EUV). Damals schien es wirklich so als habe Samsung einen Vorsprung und auch wichtige Patente die es für andere schwer machen.
3GAE sehen wir vielleicht noch dieses Jahr in Exynos Produkten. Ansonsten wird 3GAP wohl nächstes Jahr für Kunden verfügbar sein. Ausgehend davon dass 5LPE und 5LPP also die beste Weiterentwicklung von Samsungs 7nm EUV Prozess in etwa die Performance von TSMC N6 erreicht und 3GAP ca. 10-20% Power, speed und density improvements erreichen soll, wäre der Prozess etwa vergleichbar mit TSMCs N5 Familie.
Ganz schlecht scheint der Prozess nicht zu sein, denn neben IBM werden auch Qualcomm und Nvidia den Prozess nutzen, womöglich aber nur für einen kleinen Teil der Produktpalette.

Backside Power delivery steht bei Samsung erst mit der 2nm Prozessfamilie an, theoretisch 2025, also frühstens 2026 für Kunden.

Bei TSMC gibts aber auch nur noch mickriges Scaling. N3 vs N5: 40% Density, 20% speed oder 20% power ist nicht mit echten fullnodesprüngen von früher vergleichbar. Einzelwerte wie 20% Performance erreicht man vermutlich auch mit Designtricks und Halfnodes wie N4P oder N4X.
Einer der Gründe wieso Intel so viel auf N3 setzt ist vermutlich vergleichsweise gute Density. Intel braucht dass, da man sowohl bei der CPU- als auch der GPU-Architektur PPA-technisch bzw. bei der performance per transistor hinten liegt.

[latiose88]

Ja Samsung liegt noch immer ganz schön weit hinten.Und viele Kunden hat Samsung auch nicht mehr,weil die meisten zu TSMC gehen.Mal sehen wie es mit Samsung weiter gehen wird.
Und auch ne gute Frage wer von beiden liegt mehr vorne bzw geht es besser Intel oder Samsung und welche Fertigung skaliert besser bei Leistung Intel oder Samsung? Das beide TSMC hinter her hinken ist klar,das bestreitet auch keiner.

[y33H@]

Ja, es wundert mich echt wieso es keinen intel4+BPD oder intel3+BPD Prozess gibt, sondern intel mal wieder zwei hochbrisante Technologien auf einmal einführen will.Genau deshalb gibt's ja P1277 alias Intel4 mit PowerVia um Letzteres schon fertig haben.

[KarlKastor]

Bei TSMC gibts aber auch nur noch mickriges Scaling. N3 vs N5: 40% Density, 20% speed oder 20% power ist nicht mit echten fullnodesprüngen von früher vergleichbar.
Wo hast du die Zahlen her?
Tsmc gibt für N3 25-30 Power reduction und für N3E 30-35.

[davidzo]

Es würde mich nicht wundern wenn Samsung wirklich bei GAA die Nase vorn hat. Schließlich haben sie am meisten Erfahrung und am meisten darein investiert.

TSMC führt eher mit Yieldverbessernden Maßnahmen und advanced Materialien wie Pellicles für EUV. Bei Cobalt war Intel mal führend, das scheint TSMC jetzt auch zu können, dazu noch doped germanium channels. Nicht zuletzt führt TSMC beim advanced packaging.

Wer weiß ob Samsung nur mit GAA dagegen anstinken kann und wenn dann wohl nur mit kleineren monolitischen Chips, z.B. für nvidias GB107 oder einen qualcomm Mobil-Soc.

Intel kann immerhin auch ein bisschen advanced packaging und will sich nun wohl BPD zum Steckenpferd machen. Ich sehe das noch skeptisch ob sie das executed bekommen und ob das reicht um gegen TSMC zu bestehen.

[davidzo]

Wo hast du die Zahlen her?
Tsmc gibt für N3 25-30 Power reduction und für N3E 30-35.
Semianalysis: https://www.semianalysis.com/p/tsmcs-3nm-conundrum-does-it-even
TSMC vergleicht aber auch Quark mit der unterschiedliche Finanzahl. Die sind auch weit zurückgerudert, denn in 2020 hieß es noch 1,7x scaling zwischen N5 und N3.

[KarlKastor]

Das sind die Daten aus dieser Folie.
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRCBz6n5EjUANOcseuOwZGOohUf8zWTlifT0w&usqp=CAU

Ich weiß nicht ob das nur ein Spezialfall ist. Aber die widersprechen TSMCs Overall Angaben.
Normalerweise ist zB Power reduction deutlich mehr als Performance improvement. Hier ist der Wert gleich.

Beim scaling ist aus 1.7 jetzt 1.6 geworden für Logik. Analog und SRAM ist 0.0. war vorher mit 1.1 und 1.2 angegeben.
Für nen monolithischen Chip wird man wohl etwa 1.3 erwarten können.

[Zossel]

Genau deshalb gibt's ja P1277 alias Intel4 mit PowerVia um Letzteres schon fertig haben.

Welche kaufbaren Produkte nutzen das?

[KarlKastor]

Keine. Es ist die risk mitigation fur BPD im 20A.

[HOT]

Ja, 20A scheint für ARL nicht mehr rechtzeitig zu kommen, bzw. für die meisten DIEs eh nicht interessant gewesen zu sein. Kann schon sein dass man jetzt lieber Lunarlake o.Ä. auf 20A bringt statt 18A, vorrausgesetzt man kann den Die-to-Die Pitch noch anpassen.

Der Intel4 PowerVia Prozess zeigt ja dass Backside Power delivery für den Anfang primär für mobile geeignet scheint. Wie der Thermal Response Graf von dem Testchip zeigt hat Intel das thermische Verhalten noch kaum unter Kontrolle. Teilweise ist die Wärmeableitung gleich gut oder besser als Intel4, teilweise fast doppelt so schlecht. Wenn Intel glaubt dass würde man yieldtechnisch noch groß verbessern können für 20A, dann hätte man die Häufung schlechter DIEs in dem Grafen einfach rausgebinnt und nur die guten genommen für den vergleich.
[...]

Wenn man mit 20A keine größere Serie vorbereitet ist der Prozess schlichtweg teurer Quatsch. MMn ist der Prozess dead on arrival und es gab außer rumtesten auch mMn nie einen wirklichen Anwendungszweck dafür außer für Roadmaps, also Marketing und internes Engeneering natürlich.
ARL in N3 wurde schon in 21 noch unter Bob Swan eingestielt, man erinnere sich daran, dass der Prozess eine der ersten Dinge ist, die man festlegt bei einem neuen Design. 20A war nie ne wirkliche Option aus meiner Sicht. N3 dient halt als sicherer Übergang weil man eine CPU braucht, die konkurrenzfähig ist und man 21 schlichtweg nicht sicher sein könnte, ob die ehrgeizigen Pläne überhaupt aufgehen.

MMn wird es einen Intel3 mit PowerVIAs als Übergangslösung geben für Diamond Rapids und für eine Refresh-CPU zu ARL, wie auch immer die heißen wird. Panther und Nova Lake scheinen ja gecancelt zu sein, stattdessen wird es ein Design mit Cougar Cove geben, ich vermute, dass man das Teil auch Cougar Lake nennen wird. Das wäre dann 18A, ansonsten wird man bis dahin die Strategie wie bisher fortführen mMn, also Lineup-> einzel-Die -> Lineup -> einzel-Die.

Also die reale Roadmap aus meiner Sicht:

Comet Lake Skylake (komplettes Lineup 14nm)
Rocket Lake Cypress Cove (einzelnes Die 14nm)
Alder Lake Golden Cove (komplettes Lineup Intel7)
Raptor Lake Raptor Cove (Golden Cove Refresh) (einzelnes Die Intel7)
Meteor Lake speziell siehe unten
Arrow Lake Lion Cove (komplettes Lineup in N3)
unbekannt Lake unbekannt Cove (Lion Cove Refresh) (einzelnes Die in Intel3 + PowerVIA)
Cougar Lake(?) Cougar Cove (komplettes Lineup 18A)

Und im Server:
Sapphire Rapids (Golden Cove) (Intel7)
Sapphire Rapids Refresh (Golden Cove) (Intel7)
Emerald Rapids (Raptor Cove) mMn gestrichen, stattdessen Refresh von SR (ER ist ja auch überflüssig teurer Mist mit seinen 2x 800mm²+)
Granite Rapids (Redwood Cove) (Intel3)
Diamond Rapids (Lion Cove) (Intel3 + PowerVIA)

klar das ist alles ausgedacht, aber mal sehen, wie nah ich letztendlich dran liege ;).

MTL ist deshalb speziell, weil das als Testballon für die eigene Fertigung gedient hat. Man hat ja am EUV-Ausbau bei Intel gesehen, dass Intel nicht mal theoretisch genug EUV-Kapazität hat, um ein komplettes MTL-Lineup zu bringen. Man hats versucht, es hat nicht geklappt und man mußte die Designteams auch dringend entlasten, damit der Rest pünktlich kommt. Übrig bleibt halt der mobile MTL, der aber nicht den kompletten Mobilmarkt abdeckt, sondern parallel zu RPL-Refresh läuft und die Fertigungskapazität und -möglichkeiten für spätere Produkte implementiert, sowohl beim Package als auch bei der Fertigung. MMn läuft dieses Konzept ähnlich mit ARL weiter, also, dass der Mobilmarkt sich auf ARL und MTL-Refresh aufteilen dürfte. Alles in Allem ein recht schlauer Plan seitens Intel, um wieder auf die Beine zu kommen. Leider lief es ausgerechnet im Serverbereich trotzdem ziemlich schlecht, weil man solange auf die doch recht stromfressenden 10nm-Fertigung angewiesen ist.

[y33H@]

Wir sind im Speku-Forum, ich weiß ... dennoch ^^

[reaperrr]

Sapphire Rapids Refresh (Golden Cove) (Intel7)
Emerald Rapids (Raptor Cove) mMn gestrichen, stattdessen Refresh von SR (ER ist ja auch überflüssig teurer Mist mit seinen 2x 800mm²+)

;D

Schon mal drüber nachgedacht, dass sie bei ER auf 2 dicke Dies zurückgehen, weil die Verbindung der 4 Dies bei SR zu viele Probleme macht und einer der Hauptgründe für die massiven Verspätungen ist?

Intel wird das nicht zum Spaß, sondern aus guten Gründen gemacht haben. Und aus diesen guten Gründen wird ein SR-Refresh wenig Sinn machen, weil das an der Tatsache, dass es sich offensichtlich um ein komplett verkorkstes Kontrukt handelt, nix ändern würde, und 100-200 MHz mehr Turbo-Takt SR auch nicht mehr retten würden (wenn die Yield-Rate dafür überhaupt gut genug ist).

Abgesehen davon, dass ER in der Top-Konfig immerhin 4 Kerne und massiv L3 und Snoop-Caches sowie höheren Speicher- und UPI-Takt auf den SR-Vollausbau draufpackt, neben etwaigen Yield- und Energie-Vorteilen durch weniger EMIB-Dies (3 statt 10).

[mocad_tom]

ich bin der meinung koduri und keller sind deshalb schon weg, weil sie fulminant daneben gelegen sind mit dem vielen kleinhacken der dies.

[iamthebear]

Raja Kudori hat das Arc Desaster verbockt (speziell was den Release selbst angeht) und ist deshalb nicht mehr da. Das hat mit der CPU Sparte nichts zu tun.

Jim Keller lässt sich generell nur für einzelne Projekte engagieren und welchselt alle paar Jahre die Firma. Im Fall von Intel soll er was man so hört auf Grund von persönlichen Problemen mit Bob Swan gegangen sein, da er dess Politik speziell was das Auslagern zu TSMC hin angeht nicht einverstanden war.
Kurze Zeit später war Bob Swan sowieso Geschichte aber Jim Keller hatte zu der Zeit dann schon andere Pläne mit Tenstorrent.

[latiose88]

achso war das also.Naja Intel hat die Chance verzockt,aber gut nicht jeder kann gleich gut harmonieren.So ist das halt bei so großen Firmen wie Intel eben.
Naja wir werden ja schon sehen wie es bei Intel weiter gehen wird.

[reaperrr]

Raja Kudori hat das Arc Desaster verbockt (speziell was den Release selbst angeht) und ist deshalb nicht mehr da. Das hat mit der CPU Sparte nichts zu tun.
Raja soll vor allem die Führung über manche Dinge belogen und Dinge besser dargestellt haben, als sie tatsächlich waren.
AMD kann im Nachhinein heilfroh sein, dass er damals zu Intel gegangen ist.

Auch wenn RDNA3 jetzt nicht so toll ist, an sich läuft es in AMD's Grafiksparte seitdem runder und vor allem geräuschloser ab.
Anders ausgedrückt, Wang ist fachlich genauso gut oder besser, ist nicht so ein Selbstdarsteller und erzählt auch nicht solchen Mist wie Raja teilweise.

[mocad_tom]

So wird Sierra Forest und Granite Rapids XCC und Granite Rapids MCC aussehen:
https://twitter.com/yuuki_ans/status/1639813047845011456

Man geht an das Rectangle Limit und klatscht so viele Cores wie möglich in ein Die.

EMIB wird einen kleineren Dot-Pitch bekommen und damit dann auch kleinere pJoule-Werte bei EMIB erlauben.

Falcon Shores das Gleiche.

Intel 18A wird deshalb so interessant, weil es ein maßgeschneiderter Prozess hierfür wird und man über die deutlich bessere Transistordichte nochmal mehr Cores in das 18A-Rectangle Limit reinbekommt.

Deshalb hat auch Jensen Huang schon gesagt, dass er 18A interessant findet.

Keller hat bei Sapphire-Rapids-XCC daneben gelegen.
Koduri hat bei Ponte Vecchio daneben gelegen.

Ganz Intel war Foveros-EMIB-besoffen.

Sierra Forest für 4710 und Granite Rapids-XCC für 7529 werden sehr coole Prozessoren.

Der On-Package-Link zwischen IO-Die und Compute-Die bei Milan / Genoa wird zunehmend zu einer Last für AMD. AMD muss sein Server-Portfolio ab H2 2024 auf TSMC N3P umstellen, sonst bricht der Vorsprung weg.

Und TSMC N3P schaut aktuell nicht gesund aus.

AMD hat mit Genoa-X eine Hammer-CPU, aber dort müssen aktuell noch Sachen repariert werden, die ist noch nicht aus dem gröbsten raus, speziell das IO-Die.

[HOT]

;D

Schon mal drüber nachgedacht, dass sie bei ER auf 2 dicke Dies zurückgehen, weil die Verbindung der 4 Dies bei SR zu viele Probleme macht und einer der Hauptgründe für die massiven Verspätungen ist?

Intel wird das nicht zum Spaß, sondern aus guten Gründen gemacht haben. Und aus diesen guten Gründen wird ein SR-Refresh wenig Sinn machen, weil das an der Tatsache, dass es sich offensichtlich um ein komplett verkorkstes Kontrukt handelt, nix ändern würde, und 100-200 MHz mehr Turbo-Takt SR auch nicht mehr retten würden (wenn die Yield-Rate dafür überhaupt gut genug ist).

Abgesehen davon, dass ER in der Top-Konfig immerhin 4 Kerne und massiv L3 und Snoop-Caches sowie höheren Speicher- und UPI-Takt auf den SR-Vollausbau draufpackt, neben etwaigen Yield- und Energie-Vorteilen durch weniger EMIB-Dies (3 statt 10).

ER wird Intel wegen dieser Probleme entwickelt haben. Aber du brauchst keinen ER, wenn SR läuft und das tut er ja. Dann ist ER nämlich irre viel teurer in der Herstellung als SR.

[y33H@]

Wieso muss EMR zwingend teurer sein als SPR? ja, größere Dies - aber eben weniger Packaging Kosten.

Sierra Forest für 4710 und Granite Rapids-XCC für 7529 werden sehr coole Prozessoren.Generell finde ich Birch Stream, egal SP oder AP, super interessant von der Technik sowie Performance/Effizienz her ... freue mich auf 2024, wird eine spannende Zeit!

[w0mbat]

EMIB sollte jetzt nicht soo teuer sein, vor allem weil auch EMR advanced packaging nutzt.

[reaperrr]

Dann ist ER nämlich irre viel teurer in der Herstellung als SR.
Wo?
Die gesamte Silizium-Menge eines ER-Dies ist kaum höher als die von 2 SR-Dies.

Bzgl. Defektrate, wenn Intel 7 diesbezüglich ziemlich ausgereift ist (wo man inzwischen von ausgehen sollte), wird das bei ER kaum schlechter aussehen als bei SR.
Zum Einen hat ER im Gegensatz zu SR selbst in der Top-SKU mind. 1 deaktivierten Kern je Die, also mehr Redundanz, vmtl. auch beim Cache, zum anderen bedeuten die größeren Caches + schnellerer Speicher + schnelleres UPI mehr Leistung je Kern in Bandbreiten-intensiven Anwendungen -> höhere Preise -> etwas schlechtere Ausbeute kein Beinbruch.

Und statt 10 nur noch 3 EMIB-Chips zu benötigen, gleicht eine potentiell etwas schlechtere Yield-Rate bei den beiden großen Chips noch weiter aus.

[w0mbat]

EMR ist sicher teurer als SPR in der Produktion, aber auch nicht so viel mehr. Ist schwer genau zu sagen.

[ryan]

Möglicherweise Änderungen an der Cache Architektur bei Lion Cove.


LNC may intro new L0 level cache

Should clarify, this L0 is renamed from L1, the new L1 will be a Latency-reduced L2 cache which has similar size as old day L2
https://twitter.com/xinoassassin1/status/1680539451460657152

[HOT]

Da würd ich meine Erwartungen an die Performance aber mal echt im Zaum halten. Igor hat Intels eigene Performanceprojektionen zugespielt bekommen:
https://youtu.be/2omhhYg6dhs
mehr als 7-20% gibts von ARL (15900k) nicht vs. 13900k.
Kann natürlich besser laufen als geplant, aber das wird dennoch nicht viel sein.

[Tarkin]

das wird ein Desaster sondergleichen... und ARL kommt ja auch erst in 18 Monaten (!)

Mann darf nicht vergessen... ARL bringt ZWEI Node Upgrades und ZWEI Core Updates vs. Raptor. Und dann kommt da grad mal ~10-20% mehr MT Performance raus? Das ist mehr als peinlich.

Da werden Köpfe rollen bei Intel. Gelsinger wird nicht mehr lange CEO sein wenn diese Projections stimmen.

Das ganze Gerede von "unquestioned Leadership" in 2025 war nichts als heiße Luft.

Eigentlich können die sowas Ende 2024 nicht bringen... unmöglich. Die werden von der gesamten Industrie ausgelacht.

Ich könnte mir vorstellen, dass sie eventuell schon an einer Alternative basteln wie ein Raptor Lake mit 10P cores und 20 e-cores oder sowas.

Ehrlich jetzt - für 15% mehr MT Performance braucht man keine 2 Core-Updates und 2 Node-Jumps. Da ist irgendwas ganz gewaltig schied gelaufen!

[dildo4u]

CPU/IGP Performance Arrowlake vs Raptorlake Refrech vs 13900k.


https://www.igorslab.de/intels-interne-performance-projektion-fuer-raptor-lake-s-refresh-und-arrow-lake-s-so-schnell-sollen-cpu-und-igp-werden-exklusiv/

Schätze mal 14900k bringt fast nix da die E-Core bei 16 bleiben?

[HOT]

Igor sagt 14900K = 13900KS.

Wo?
Die gesamte Silizium-Menge eines ER-Dies ist kaum höher als die von 2 SR-Dies.

Bzgl. Defektrate, wenn Intel 7 diesbezüglich ziemlich ausgereift ist (wo man inzwischen von ausgehen sollte), wird das bei ER kaum schlechter aussehen als bei SR.
Zum Einen hat ER im Gegensatz zu SR selbst in der Top-SKU mind. 1 deaktivierten Kern je Die, also mehr Redundanz, vmtl. auch beim Cache, zum anderen bedeuten die größeren Caches + schnellerer Speicher + schnelleres UPI mehr Leistung je Kern in Bandbreiten-intensiven Anwendungen -> höhere Preise -> etwas schlechtere Ausbeute kein Beinbruch.

Und statt 10 nur noch 3 EMIB-Chips zu benötigen, gleicht eine potentiell etwas schlechtere Yield-Rate bei den beiden großen Chips noch weiter aus.

Bitte was? ER ist satte 750mm² groß, SR nur ca. 380mm². ER ist also VIEL teurer als SR, selbst wenn SR 4 Dies hat. Das Package spielt da keine große Role, der Yield aber schon. ER kann eigentlich nur als Ergänzung für SR dienen für bestimmte Märkte, ansonsten ist die CPU eigentlich irrelevant und teuer für Intel. Aus meiner Sicht wäre ER nur dann sinnvoll gewesen, wenn man die 4 Dies von SR nicht in Harmonie gebracht hätte. ER ist weder ein Ersatz noch ein Nachfolger für SR.

[mocad_tom]

@HOT

Man müsste jetzt die Defect Density für den Intel 7 Prozess kennen.
Aber wenn ein Defect in den Core einschlägt, dann deaktiviert man den halt.
Mit 5MB L3 Cache nimmt der auch eine große Fläche ein. Cache hat sogar redundante Strukturen, so dass man hier nur ein paar Bereiche deaktivieren muss.

Ja es stimmt, ein so großer Die hat unterschiedliche Bereiche, wo bedingt durch die Wellenlänge des Lichts eine schärfere Belichtung in dem Bereich und eine ungenauere Belichtung im anderen Bereich stattfindet, aber auch damit kann man planen. Je nachdem wie sich Wellenberge und Wellentäler überlagern.

Aber ob man nun Emerald Rapids fertigt oder Sapphire Rapids MCC, die müssten in etwa gleich schwierig zu fertigen sein.

Und ich glaube die Hyperscaler und Facebook fragen händeringend nach Emerald Rapids.

Ich kann mir gut vorstellen und ich habe es jetzt auch schon aus unterschiedlichen Richtungen gehört, Intel Server scheinen nicht so schlecht zu laufen.

Es scheint China eher etwas mehr AMD zu kaufen, der Rest der Welt eher etwas mehr Intel (als vorausgesagt).

Und auch bei Arrow Lake jetzt bei Igors Lab.
Ich dachte der große Arrow Lake-S wird 8 Performance + 32 Efficiency
Sprich Multithreaded-Werte werden nochmals anders unterwegs sein.

[HOT]

Das wird jetzt als ARL-Refresh gehandelt, also sowas wie Raptor Lake. Die erste Iteration wird ziemlich sicher 8+16 wie bisher.

Und bei ER sag ich ja, für bestimmte Märkte könnte das Ding interessant sein. Die Frage ist nur ob das ein Produktlineup rechtfertigt...

[ryan]

Und auch bei Arrow Lake jetzt bei Igors Lab.
Ich dachte der große Arrow Lake-S wird 8 Performance + 32 Efficiency
Sprich Multithreaded-Werte werden nochmals anders unterwegs sein.


In der letzten Roadmap stand auch nur 8+16 bei ARL-S. Laut Raichu ist 8+32 unsicher...er könnte als refresh kommen.

Die MT Benchmarks wären Ok wenn ARL wirklich ohne SMT kommt und die Prognose das mit berücksichtigt. Ein SC Steigerung von 10% wäre ernüchternd. Das hätte man eher andersrum erwartet. Könnte natürlich sein, dass die peak Taktrate von 6 auf zum Beispiel 5.5 Ghz abfällt. Wir wissen noch nicht, was TSMC 3nm bei den peak Taktraten anstellen kann.

Bei der Grafik wird es eine GT1 und somit 64EUs, alles andere wäre auch überraschend gewesen.

[HOT]

Jo, die SC-Leistung ist so gut erklärbar, nämlich dann, wenn wir ne massive Taktregression sehen und das ist das was ich auch befürchte. Ein LC wird mMn 30% mehr IPC durchaus haben. Aber eben ohne SMT und ohne hohe Turbo-Takte.

[ryan]

Vielleicht sind die Gerüchte um TSMC 3nm doch wahr und die Probleme vielleicht noch größer als gedacht. Dazu kommt, dass Intels 10nm DUV mehrere Jahre Zeit für Optimierungen gehabt hat, um auf die heutigen 5,8-6 Ghz zu kommen. Selbst Alder Lake kam nur auf 5,2 oder 5,3 Ghz.

N3B wird schon länger vermutet.



Almost is what I am going to say, Xino said it's on N3B couple of days ago and I am expecting somewhat heavy clock regression based on ARL-HX and ARL-S perf numbers

Can confirm those perf numbers are legit. I had the ARL-HX numbers for sometime and it matches up .
https://twitter.com/SquashBionic/status/1680825538594869249

[HOT]

Glaub ich nicht. Das wird einfach die neue Architektur sein. Die ist einfach (noch) nicht so taktfreudig. Mal die nächste Iteration abwarten.

[Der_Korken]

Ich hatte die Sache mit dem SMT-Drop nur am Rande mitbekommen. Ist da wirklich mehr dran? Wenn ja, finde ich den MT-Score höchst interessant, denn normalerweise holt SMT schnell mal 20-30% raus. Das bedeutet, dass die Kerne bei IPC*Takt etwa 30-40% schneller sein müssen, damit ohne SMT noch so viel Gewinnt in MT ankommt. Eventuell haben die E-Cores hier mehr Gewinn als die P-Cores, d.h. 20-30% P-Cores und 40-50% E-Cores. Oder so ähnlich.

Die Frage ist dann, warum der ST-Wert so "schlecht" ist. Hier wurde ja schon gesagt, dass es einfach Taktregressionen sein können. Intel hat sowohl die 14nm- als auch die 10nm-Familie jahrelang getuned, um ihre jetzigen Taktraten zu erreichen. Mit einem neuen Prozess verliert man vielleicht erstmal wieder direkt 1Ghz.

Bleibt noch zu erklären, warum die MT-Werte nicht unter der Taktregression leiden. Die einzige für mich logische Erklärung ist ein starker Effizienzgewinn, der es erlaubt in MT quasi die gleichen Taktraten zu fahren wie in ST. Bei Zen 4 war das ja ähnlich. Theoretisch könnte man natürlich auch die Topologie verbessern wie es z.B. damals von Conroe/Penryn auf Nehalem gemacht wurde. Allerdings hat Intel bereits eine sehr homogene Architektur mit großen LLC. Da erscheint mir die Erklärung mit deutlich höherem Takt bei MT-Last schlüssiger.

Für mich klingt das erstmal sehr interessant, weil es starke Architekturänderungen impliziert. Zen 5 sollte das angeblich auch sein, aber die bisherigen Gerüchte klangen eher nach einer weiteren Zen-3-Iteration.

[HOT]

Zen5 wird extrem viel breiter als 4 Issues. Wird also die erste "echte" neue Architektur (also verlässt den bisherigen Aufbau) seit Ur-Zen. Ansonsten scheint alles gleich zu bleiben, IOD, Plattform usw.

[E39Driver]

Hmm klingt ehrlich gesagt nicht so toll. Das heißt doch zusammengefasst man hat im Intel Desktop mit MTL bis Ende 24 erstmal Stagnation und dann mit Arrow-Lake einen Fertigungs- und Architektur-Sprung, der laut Igors Folien aber kaum nennenswerte Leistungsgewinne hat. Dürfte ziemlich schwer werden gegen ZEN-5

[ryan]

Ich hatte die Sache mit dem SMT-Drop nur am Rande mitbekommen. Ist da wirklich mehr dran?


Sieht schon sehr danach aus. Mehrere Leute berichten das, darunter Exist50.



Bleibt noch zu erklären, warum die MT-Werte nicht unter der Taktregression leiden. Die einzige für mich logische Erklärung ist ein starker Effizienzgewinn, der es erlaubt in MT quasi die gleichen Taktraten zu fahren wie in ST. Bei Zen 4 war das ja ähnlich. Theoretisch könnte man natürlich auch die Topologie verbessern wie es z.B. damals von Conroe/Penryn auf Nehalem gemacht wurde. Allerdings hat Intel bereits eine sehr homogene Architektur mit großen LLC. Da erscheint mir die Erklärung mit deutlich höherem Takt bei MT-Last schlüssiger.


Die MT Taktraten liegen ein Stück unter den peak ST Taktraten. Bei der MT Taktrate zählt eher die Effizienz im maximalen Limit von 253W. Der Taktratenunterschied sollte im MT kleiner ausfallen, wenn es Taktprobleme beim erreichbaren Maximaltakt von TSMC N3B gibt. Das kann mit ein Grund sein, weswegen die MT Steigerung trotz deaktivierten SMT besser ausfällt.

Bei der MT Performance sind die E-Kerne auch groß mit beteiligt, während bei der maximalen SC Leistung der P-Kern entscheidend ist. Wir kennen die Taktraten von Skymont nicht.

[Nightspider]

Warum wird SMT entfernt?

[Gipsel]

Sieht schon sehr danach aus. Mehrere Leute berichten das, darunter Exist50.Random Twitter-Accounts zählen für mich nicht.
Ich würde zu diesem Zeitpunkt fast drauf wetten, daß da Jemand was in den falschen Hals bekommen hat. Es wird vermutlich Servervarianten (z.B. für Cloudanbieter) geben, bei denen das deaktiviert ist (aus Sicherheitsgründen) oder die das von vornherein gar nicht haben, weil es Versionen sind, die sowieso nur E-Cores besitzen (Sierra Forest Nachfolger?). Bei AMD gibt es ja auch ein paar wenige Epyc-Versionen ohne SMT (eben genau bei den Versionen für Cloudanbieter mit Zen4c, z.B. beim 9754S (https://www.amd.com/en/product/13381)). Ansonsten verschenkt man bei "normalen" Anwendern doch Einiges an MT-Leistung bei einem so breiten Kern. Das wäre schon recht überraschend und kaum rational zu erklären (maximal in Kombination mit Unmengen an E-Cores, die dann das MT-Defizit wieder ausbügeln [wäre trotzdem Verschwendung, SMT zu deaktivieren/wegzulassen]).

[w0mbat]

Jupp, abgesehen von cloud native macht es keinen Sinn SMT zu entfernen. Außer man denkt, man hat via E-cores eh genug MT, aber SMT bringt für wenig Fläche viel Leistung.

[davidzo]

Warum wird SMT entfernt?

Gibt mehrere Auflösungen:
a) Der SMT-drop ist geplant, aus ähnlichen Gründen wie Apple kein SMT anbietet: 1T Performance und Effizienzgewinne weil Caches latenzärmer werden, mit weniger Assoziativität auskommen, Register und buffer kleiner oder besser ausgelastet und schneller werden und außerdem Transistoren eingespart werden. Die MT Leistung der P-Cores sinkt dann zwar, aber das kann in Zukunft leicht durch mehr E-cores ausgeglichen werden.
b) LC ist eine völlig neue Architektur und hat nichts mehr mit den vorherigen Cove Cores gemeinsam. HT war daher ein Feature welches weiter hinten auf der Todolist stand. Wenn es eine Deadline für die Architekturentwicklung gab, kann es sein dass es das Feature einfach nicht mehr in das Release geschafft hat. Gelsinger hatte ja mal verkündet dass man bei der Hardwareentwicklung zu einer Art Rolling release übergeht und sich von einzelnen Verzögerungen nicht mehr die Roadmap durcheinander bringen lässt sondern einfach den letztbesten stabilen stand launcht (wie es übrigens auch bei AMD gehandhabt wird).
c) Es gibt einen schwerwiegenderen Bug der nicht so einfach durch ein Stepping korrigiert werden kann. Es würde auch zum Development-release-Stil von Gelsinger passen anstatt dann alles für einen Respin zu verzögern lieber mit weniger features zu launchen. Siehe AVX512, das für ADL und RTL einfach gedroppt wurde, für das es aber sicher mal Pläne gab sonst wäre es nicht auf dem DIE. Zumal die höheren MT Taktraten und die E-Cores zur Ehrenrettung der MT-Leistung wohl diesmal gerade ausreichen, es wäre also kein Beinbruch es weg zu lassen.


Random Twitter-Accounts zählen für mich nicht.

Ja, die zeitliche Übereinstimmung der verschiedenen Berichterstatter sieht für mich sehr so aus als wenn sie alle gegenseitig oder von ein und derselben Quelle abschreiben.
Wenn es also nur eine einzige Quelle ist, ist die Wahrscheinlichkeit dass diese eben falsch liegt auf jeden Fall gegeben.

[mocad_tom]

Es gab mal ein Gerücht, dass der Performance-Core 8 issue wide und der E-Core 4-issue-wide wird.

Die Execution Units sind gleich angeordnet, nur bei Performance-Core genau verdoppelt.

Aber fragt mich nicht wo das war.

Ich weiß auch gar nicht wieviel das bringt, das OOO-Window und die Shadow Register müssen bei beiden ganz unterschiedlich designed werden und dort geht ja eigentlich das größte Transistorbudget rein.

[ryan]

Random Twitter-Accounts zählen für mich nicht.
Ich würde zu diesem Zeitpunkt fast drauf wetten, daß da Jemand was in den falschen Hals bekommen hat. Es wird vermutlich Servervarianten (z.B. für Cloudanbieter) geben, bei denen das deaktiviert ist (aus Sicherheitsgründen) oder die das von vornherein gar nicht haben, weil es Versionen sind, die sowieso nur E-Cores besitzen (Sierra Forest Nachfolger?). Bei AMD gibt es ja auch ein paar wenige Epyc-Versionen ohne SMT (eben genau bei den Versionen für Cloudanbieter mit Zen4c, z.B. beim 9754S (https://www.amd.com/en/product/13381)). Ansonsten verschenkt man bei "normalen" Anwendern doch Einiges an MT-Leistung bei einem so breiten Kern. Das wäre schon recht überraschend und kaum rational zu erklären (maximal in Kombination mit Unmengen an E-Cores, die dann das MT-Defizit wieder ausbügeln [wäre trotzdem Verschwendung, SMT zu deaktivieren/wegzulassen]).


Exist50 ist kein Twitter user, der hat wirklich Quellen und ist seriös. Er ist sich 100% sicher, dass Client Lion Cove kein SMT bekommt (Client LNC, if nothing else, doesn't have SMT period. Server, if it even exists at all, I don't know. Maybe they could enable it in another stepping, but it's not being disabled for funsies.)

Nur bei den Server Varianten, wenn welche kommen, kann er nichts sagen. Es ist aber nicht nur er, auch andere bekannte Leute berichten davon. Xino hat das zuerst in die Welt gesetzt. Er schrieb they removed hyper-threading in the supported technologies list....

An eine support technology Liste kommt man im Zweifel leichter ran, als an Benchmark Projektionen für eine CPU in 1-1.5 Jahren. Für die Gründe kann man nur spekulieren, öfter zu lesen sind Validierungs und Sicherheitsgründe.

[ryan]

Übrigens meinte Raichu (https://twitter.com/OneRaichu/status/1671544495853441024) vor ein paar Wochen, dass ARL-U ein umgebrandeter MTL-U refresh wäre.


After the brand change, INTC makes a new and last one-gen product coexist in fact, and -U product is moved to N-1 gen.
So, ARL-U is the MTL-based refresh actually, based on the P1276 series process instead of P1278.


Das könnte auch mit den 20A cancelling Gerüchten zusammenhängen, weil normal ist das nicht. Jetzt gibt es im extension Datasheet zwei Arrow Lake CPU IDs, 06_C5H und 06_C6H. Nur C6H bekommt die neuen extensions, während C5H auf dem Extension Stand von Sierra Forest Lake bleibt, siehe Anhang. Sierra Forest bekommt Redwood Cove Kerne, hier wird oft Redwood+ genannt. Arrow Lake C5H würde gut zum umgebrandeten Meteor Lake refresh passen.

[HOT]

Das erklärt tatsächlich die unterschiedlichen Befehlssätze, jo. Das wird aber schon ne komplett neue Rev. von MTL sein.

[Gipsel]

Gibt mehrere Auflösungen:
a) Der SMT-drop ist geplant, aus ähnlichen Gründen wie Apple kein SMT anbietet: 1T Performance und Effizienzgewinne weil Caches latenzärmer werden, mit weniger Assoziativität auskommen, Register und buffer kleiner oder besser ausgelastet und schneller werden und außerdem Transistoren eingespart werden.Problem daran ist: Nichts davon stimmt wirklich bzw. hat das keinen Einfluß auf die ST-Performance.
Wie soll sich z.B. die L1-Cache-Latenz durch Verzicht auf SMT drücken lassen? Beim L1-D hat Apple einen Takt weniger Latenz aber auch bei einem deutlich niedrigerem Zieltakt (in absoluter Zeit ist die Latenz deutlich höher als z.B. bei Zen4; bei M1 und M2 haben L1-D 3-4 Takte, Zen4 dagegen 4-5 Takte bei >60% höherem Takt). Die anderen Zusammenhänge von maximaler Assoziativität und Cachegröße liegt dagegen schlicht an der anderen Pagegröße (16kB vs. 4kB). Und auch bei gleicher Assoziativität der Caches ist eine CPU mit SMT im Durchschnitt übrigens schneller als eine ohne (wenn die Assoziativität >2 ist, sinkt die Wahrscheinlichkeit für einen potentiellen Performanceverlust erheblich [so daß im Schnitt definitiv ein Plus bleibt]; also ist das dann kein Grund mehr). Der kleine Hardware-Aufwand für SMT rechtfertigt sich aus Performancesicht quasi immer. Übrigens auch aus Performance/Watt-Sicht (MT-Performance mit SMT hochzutreiben ist im allgemeinen effizienter als mehr Kerne zu verbauen oder gar den Takt hochzudrehen).

[Der_Korken]

Ein paar Gedanken zu SMT (auch wenn ich Gipsel damit schon in einem Zen-Thread gelöchert habe):

1. Wenn die MT-Performance in Zukunft immer weiter auf die E-Cores ausgelagert wird, spielen die P-Cores bei MT eine immer kleinere Rolle.
2. Desktop-Systeme haben bereits heute MT-Performance noch und nöcher, die meisten User wissen gar nicht, was sie mit den ganzen Kernen anfangen sollen. Für SMT braucht man auch immer mehr Threads, um es zu nutzen und da sind bereits heute viele Anwendungen im Thread-Limit.
3. Anwendungsfälle im Bereich von ML werden in Zukunft immer mehr auf Spezialbeschleuniger ausgelagert, sodass auch hier kein Bedarf an mehr Kernen generiert wird. Man könnte die P-Kerne irgendwann auch als Spezialbeschleuniger für extrem ST-limitierte Anwendungen sehen (gab afaik mal Gerüchte, dass MTL-S als 6+16 kommen sollte, was nicht unschlüssig ist, da 6 P-Cores für bursty loads gut genug sein könnten und MT mit den E-Cores erschlagen wird).
4. Das Scheduling wird komplexer, wenn man nicht nur zwei Arten von Kernen hat, sondern diese jeweils noch virtuelle Kernen haben.
5. Potenzielle Sicherheitsprobleme wurden schon genannt. Vielleicht kann man hier beim Design auch Ressourcen sparen, wenn man SMT nicht berücksichtigen muss.

Das heißt nicht, dass SMT generell überflüssig ist, aber es gibt imho schon ein paar Gründe, warum man es in Frage stellen könnte.

[latiose88]

ja ich habe schon gesehen das ab 24 Kerne SMT schon keine Wirkung mehr gezeigt hatte.Bei Intel war es da genauso gewesen.Denke mal das dann noch mehr Kerne wohl nichts bringen.Selbst ein 32 Kerner von AMD war mit 75 % Auslastung trotz Abschaltung von SMT.Mit SMT wäre wohl dieser bei rund 40% Auslastung gewesen.Man merkt hier deutlich das ab einen gewissen Punkt Hypertrading eben nicht mehr so cool ist.
Ich hoffe wenn es schon mehr E Kerne kommen werde,das man auch mittel und Wege in die Hand bekommt auch diese Optimial richtig auszulasten.Das die Leistung auch immer mehr besser wird,das wünsche ich mir.Ne Optimierung bei den E Kernen.Da kann Intel gerne bei beiden HT weg lassen,wenn am Ende die Leistung wirklich auf die Straße kommt,warum auch nicht.

[ryan]

Vielleicht wollte Intel deswegen ARL-S sogar ursprünglich mit 8+32 Kernen bringen, damit hätte ARL-S das fehlende SMT mehr als ausgleichen können. Dazu kommt es jetzt doch nicht, oder frühestens in einem refresh wenn so einer kommt. Bei MTL hätte es SMT noch gegeben.

[latiose88]

hm hm,bei Intel heißt es HT nicht SMT.SMT ist von AMD,aber egal,ja bei Intel war ursp+nglich 8+32 geplant gewesen.Scheinbar hat man das nicht unter gebracht weil die Fertigung also das Shrinken ganz schön Stock,so wird es wohl sein.ALso verschiebt Intel den Plan nach hinten Anstatt es jetzt bald zu bringen.

[Der_Korken]

HT ist afaik ein Markenname von Intel und SMT der Name für die Technik an sich. So wie variable refresh rate die Technik beschreibt und FreeSync und G-Sync Implementierungen davon sind.

Bezüglich 8+32 könnte Intel auch einfach entschieden haben, dass das am Bedarf des Marktes vorbeigeht und sich so ein riesiger Die nicht lohnt. Genauso wie es mal Gerüchte gab, dass AMD mit Zen 4 auf vier CCDs hochgehen könnte und 32 Kerne im Desktop bringen könnte. Davon hat man aber nichts mehr gehört, weil das ein absolutes Nischenprodukt wäre. Die Mehrheit der User kauft sich Hardware für Spiele und da führt der 7800X3D mit vergleichsweise popeligen 8 Kernen die Performance-Charts an.

[y33H@]

Sierra Forest bekommt Redwood Cove Kerne, hier wird oft Redwood+ genannt. Cove ist P-Core, aber SFR nutzt E-Cores.

[ryan]

Cove ist P-Core, aber SFR nutzt E-Cores.


Ja stimmt, der nutzt aber Crestmont Kerne genau wie bei Meteor Lake die E-Kerne, das Prinzip bleibt gleich.

Dass Arrow Lake C5H und Sierra Forest die gleichen extensions unterstützen bis auf LBR, deutet eher auf MTL hin. Bei C6H steht explizit ARL-S, der etliche extensions mehr bekommt. Lunar Lake mit Lion Cove und Skymont unterstützt die extensions von ARL-S ja auch.


Jetzt könnte man noch spekulieren, dass Intel vielleicht mehr als nur ARL-U mit älterem auffüllt, oder warum wird explizit ARL-S angegeben, macht das Sinn? Vielleicht ist wirklich was kaputt mit N3B/20A, oder am Design von ARL selber. Na gut das ist jetzt sehr spekulativ.

[iamthebear]

Da würd ich meine Erwartungen an die Performance aber mal echt im Zaum halten. Igor hat Intels eigene Performanceprojektionen zugespielt bekommen:
https://youtu.be/2omhhYg6dhs
mehr als 7-20% gibts von ARL (15900k) nicht vs. 13900k.
Kann natürlich besser laufen als geplant, aber das wird dennoch nicht viel sein.

Also ich sehe da 3 mögliche Erklärungen:
a) Das ganze sind sehr frühe Samples nicht einmal annähernd den Orginaltaktraten oder das igor bzw. dessen Quelle ist generell einem Fake aufgesessen

b) Arrow Lake hat wie Meteor Lake bzw. jeder neue Intel Node schwere Taktratenprobleme und wird es nie auf den Desktop schaffen. Aber vielleicht ist der 4nm bis dahin halbwegs brauchbar sodass es MTL oder ein Nachfolgerdesign schafft. Ansonsten hat Intel eben wieder eine Zen3 vs. Comet Lake Situation wo sie ein Jahr lang im Desktop klar hinten nach sind.
Ist zwar schlecht fürs Image aber finanziell nicht so ein Drama, da der Großteil des Marktes sowieso Notebooks sind und da dürfte sich Meteor Lake ganz gut schlagen.

c) Intel macht mit Arrow Lake einen Schwenk Richtung höhere Energieeffizienz im Stil von Apple und die 250W sind nur ein theoretischer Maximalwert des Sockels die in der Praxis nie erreicht werden.
Also z.B. nach dem Prinzip:
.) 40% mehr IPC
.) Dafür 20-25% weniger Takt (4,5GHz Maximaltakt)
.) Im Schnitt nur 5-10% mehr Performance
.) Aber im Schnitt nur 1/3 des Energieverbrauchs

Etwas ähnliches hat Intel damals mit dem Pentium M gemacht.

Da werden Köpfe rollen bei Intel. Gelsinger wird nicht mehr lange CEO sein wenn diese Projections stimmen.

Ich denke nicht, dass Pat Gelsinger hier der Verursacher der Probleme ist.
Das Plan für MTL/ARL bzw. das ganze Chipletzeugs bzw. der Plan bei TSMC zu fertigen geht noch auf Bob Swan zurück und laut Gerüchten war dies dann auch der Grund warum Jim Keller damals vorzeitig das Team verlassen hat.

Und die Probleme von SR dürften ihren Ursprung noch weit davor haben.

Das ganze Gerede von "unquestioned Leadership" in 2025 war nichts als heiße Luft.

Das bezog sich so viel ich mich erinnern kann primär auf den Prozess, nicht auf die Designs.
Ich bin zwar bei Intel grundsätzlich skeptisch aber aber der Prozess scheint gar nicht so schlecht zu laufen. Daniel Nenni meinte vor ein paar Monaten noch, dass die Ursachen für die MTL Verzögerungen reine Chipletprobleme sind und nicht der Node. Und auch Jensen Huang meinte vor kurzem noch, dass erste Versuche mit 18A überzeugend waren.

Eigentlich können die sowas Ende 2024 nicht bringen... unmöglich. Die werden von der gesamten Industrie ausgelacht.

Also ich sehe da ehrlich gesagt nicht das große Problem.
Der Desktopmarkt ist mittlerweile eine kleine Nische. Das Geld ist im Mobile und Datacentermarkt zu holen.
Im Zen5 wird Ende 2024 launchen, bis es da die ersten Mobile CPUs am Markt gibt ist es Mitte 2025 und wenn es Intel gelingt den Energiebedarf stark zu senken, dann wird man sich hier trotzdem gut halten können.
Nur im Datacentermarkt wird es schwierig aber hier verhält sich der Markt auch ziemlich träge.

Ich könnte mir vorstellen, dass sie eventuell schon an einer Alternative basteln wie ein Raptor Lake mit 10P cores und 20 e-cores oder sowas.

10 P Cores mit RTL machen wenig Sinn. Alles was mehr als 8 Kerne braucht kann auch gut mit den e Cores umgehen.
Wenn dann wird man eher eine 8/24 Variante bringen um die MT Krone zu holen oder einfach mit dem Rest noch etwas aufrücken.

Jo, die SC-Leistung ist so gut erklärbar, nämlich dann, wenn wir ne massive Taktregression sehen und das ist das was ich auch befürchte. Ein LC wird mMn 30% mehr IPC durchaus haben. Aber eben ohne SMT und ohne hohe Turbo-Takte.

Das halte ich für durchaus möglich und wenn man damit eine höhere Energieeffizienz erreicht ist das für einen Großteil der Märkte ja nicht falsch.

Eine mögliche Erklärung wäre:
.) Die e Cores werden deutlich schneller
.) Dafür fällt SMT weg bzw. macht weniger Sinn mehr, da dieses ohnehin nur genutzt wird wenn bereits alle 8 P Cores und 16 E Cores belegt sind.

Ansonsten verschenkt man bei "normalen" Anwendern doch Einiges an MT-Leistung bei einem so breiten Kern. Das wäre schon recht überraschend und kaum rational zu erklären (maximal in Kombination mit Unmengen an E-Cores, die dann das MT-Defizit wieder ausbügeln [wäre trotzdem Verschwendung, SMT zu deaktivieren/wegzulassen]).

Ich kann mich grob daran erinnern, dass Intel damals zu Pentium 4 Zeiten meinte, dass SMT nur 5-10% mehr Chipfläche verbraucht, dafür aber bei MT Anwendungen 30% mehr Performance liefern kann.

Ich stelle mir jedoch die Frage, ob das in der heutigen Zeit auch noch der Fall ist. Seither hat sich ja einiges geändert und die großen Transistorfresser sind womöglich nun ganz wo anders und man ist wohl mittlerweile besser dran stattdessen einfach ein paar e Cores mehr zu verbauen.

Bezüglich 8+32 könnte Intel auch einfach entschieden haben, dass das am Bedarf des Marktes vorbeigeht und sich so ein riesiger Die nicht lohnt. Genauso wie es mal Gerüchte gab, dass AMD mit Zen 4 auf vier CCDs hochgehen könnte und 32 Kerne im Desktop bringen könnte. Davon hat man aber nichts mehr gehört, weil das ein absolutes Nischenprodukt wäre.

Anwender, die sich über so eine CPU freuen würden gibt es sicher genug. Das ist eher eine Frage der Produktsegmentierung, da man diesen Kunden viel lieber einen teuren Xeon (bzw. Epyc) verkauft.

[KarlKastor]

Naja, wenn Arrow Lake in 20A gefertigt ist und dann MT nur 20% bei rum kommen, dann kann das mit der Leaderchip in der Fertigung nicht so weit her sein.
Selbst ein Golden Cove mit 2 Node Sprüngen müsste deutlich mehr machen.
Aber gut, bislang gibt's kaum belastbare Informationen.

[reaperrr]

Also z.B. nach dem Prinzip:
.) 40% mehr IPC
.) Dafür 20-25% weniger Takt (4,5GHz Maximaltakt)
.) Im Schnitt nur 5-10% mehr Performance

Mit sowas rechne ich auch, ja, wobei ich schon denke, dass sie auf mehr als nur 5-10% mehr Perf kommen werden, eher so 10-20, je nach Anwendung, vereinzelt auch mal mehr.


c) Intel macht mit Arrow Lake einen Schwenk Richtung höhere Energieeffizienz im Stil von Apple und die 250W sind nur ein theoretischer Maximalwert des Sockels die in der Praxis nie erreicht werden.
(...)
.) Aber im Schnitt nur 1/3 des Energieverbrauchs

Ähm... das Video und die Folie von igor sagt glasklar, dass für die interne Performance-Projektion RTL-R auf PL1=PL2=253W und ARL-S auf PL1=PL2=250W angenommen wurden.
Also zumindest am oberen Ende der TDP/Takt-Fahnenstange rechnet (Projektion, wohlgemerkt, keine Tests mit entsprechend hoch getakteten fertigen Chips!) Intel höchstselbst bei 250W nur mit 7-20% mehr Perf ggü. einem 13900K.
Wobei MT-Perf etwas besser sein soll, was auf schlechtere P-Kern-Auslastung in ST (weil breiter) und/oder im Verhältnis stärker zulegende E-Kerne hindeutet.

Natürlich kann der Vorteil im 65-125W-Bereich höher ausfallen, klar. RTL-S hat ja z.B. noch keine aktive DVR.


Ich denke nicht, dass Pat Gelsinger hier der Verursacher der Probleme ist.
Das Plan für MTL/ARL bzw. das ganze Chipletzeugs bzw. der Plan bei TSMC zu fertigen geht noch auf Bob Swan zurück und laut Gerüchten war dies dann auch der Grund warum Jim Keller damals vorzeitig das Team verlassen hat.

Nee, der muss es nur ausbaden.

Ich hatte es aber eher so verstanden, dass Jim Keller schon früher und konsequenter (sprich, mit Performance-CPUs) zu TSMC wollte, weil ihm das Chaos und die nicht enden wollenden Probleme der Intel Foundry auf den Sack gingen und er (in dem Fall nicht ganz zu Unrecht) Sorge hatte, dass das mit der Rückkehr an die Spitze ohne TSMC möglicherweise nix werden oder zumindest deutlich schwieriger würde, egal wie gut die Core-Teams arbeiten.

Bob Swan hat da wohl lange mit der Entscheidung gezögert, weil dadurch halt Kapital aus dem Gesamtunternehmen abfließt, das sonst nur von einem Firmenzweig zum anderen wandern würde, und er vmtl. auch die eigenen Foundry-Leute nicht vor den Kopf stoßen wollte.
Die endgültige Entscheidung pro TSMC N3 ist für einige Chips vmtl. erst unter Gelsinger gefallen, als Keller, Murthy und Swan weg waren.

Der Thread dazu ist ganz interessant (natürlich keine Garantie, dass es stimmt): https://www.reddit.com/r/intel/comments/z3set6/jim_keller_apparently_left_intel_2020_because_of/


Und die Probleme von SR dürften ihren Ursprung noch weit davor haben.

Das sowieso. Als Gelsinger angefangen hat, hätte SR schon längst fertig sein sollen.

[Zossel]

Kann es sein das sich Intel zu sehr mit Selbstverwirrung beschäftigt anstatt mit dem Design brauchbarer Produkte?

[mocad_tom]

Das ganze Intel 4 & Intel 3 und danach Intel 20A und Intel 18A Paket war so geschnürt, dass man damit derisking betreibt.

In Intel 4 steckt keine komplette Generation und es wird auch nicht ein kompletter Ramp damit gemacht.

In Intel 4 wird nur das kleine MTL-Die gefertigt und danach wird gleich auf Intel 3 gewechselt.

Was ich so herausgehört habe kann man von den Verarbeitungshandgriffen her von Intel 4 auf Intel 3 recht einfach wechseln.

Arrow Lake wird auch nur ein Pipe-Cleaner.
Intel 18A ist aber grundsätzlich so konzipiert, dass er recht viele Layer mit EUV macht und deshalb wird er teuer.

Ich denke es gibt gerade einen Kampf.
TSMC hat bei N3 gesagt nein wir mach hier kein Gate All Around
Intel sagt bei 20A und 18A ja wir machen hier Gate All Around.

Es erinnert ein bisschen an TSMC N7 vs Intel 10nm aber mit umgekehrten Vorzeichen.

Wäre Intel damals progressiver gewesen, und hätten für 10nm schon auf EUV gesetzt, dann hätten sie den Anschluss nicht verloren.

Diesmal ist Intel mit GAA progressiver und TSMC versucht sich am dichtest gepackten FINFET-Prozess(analog hierzu Intel hatte den dichtesten 10nm DUV Prozess und TSMC ist aber lieber auf EUV gegangen).

Auch Samsung ist aktuell lieber bei GAA.

Wir werden in den nächsten 2-3 Jahren ein Blutbad mit ungewissem Ausgang sehen.
Produkt-Pipelines (von Apple, nvidia, AMD) verlassen sich auf Roadmaps und Yield-Zusagen.

Vielleicht ist Intel 18A gesund und Intel kann schnell Produkte in 18A fertigen.
Evtl. sterben sie auch komplett auf dem Weg dorthin.

GET RICH OR DIE TRYIN'

[davidzo]

Ich bin zwar bei Intel grundsätzlich skeptisch aber aber der Prozess scheint gar nicht so schlecht zu laufen. Daniel Nenni meinte vor ein paar Monaten noch, dass die Ursachen für die MTL Verzögerungen reine Chipletprobleme sind und nicht der Node. Und auch Jensen Huang meinte vor kurzem noch, dass erste Versuche mit 18A überzeugend waren.


Genau, es könnten auch einfach eine Packaging- und Kapazitätsentscheidung sein. Intel besitzt nicht soviele EUV Belichter wie TSMC und die Foveros Packaging Linien wurden bisher nur für ein paar Nischenprodukte genutzt. Für MTL und RTL müssen beide Fertigungstrecken um ein vielfaches Wachsen. Es kann gut sein dass der gleichzeitige Rampup beider Technologien für den mainstream aus Prozessunabhängigen Gründen länger dauert. Vielleicht ist es auch die hohe (interne) Nachfrage von Intel4 und Intel3 die das blockiert. Man darf nicht vergessen dass Intel vor kurzem noch der größte Chiphersteller der Welt war und 80% aller PC-CPUs ausliefert. Da reicht es nicht wenn man ein gutes Produkt hat und rechtzeitig am Markt ist, man muss auch in entsprechenden Stückzahlen liefern können.




Ich kann mich grob daran erinnern, dass Intel damals zu Pentium 4 Zeiten meinte, dass SMT nur 5-10% mehr Chipfläche verbraucht, dafür aber bei MT Anwendungen 30% mehr Performance liefern kann.

Es waren 5% Transistoren, bzw. 2-3Mio bei Northwood laut Intel. Heutzutage dürfte das noch weniger sein prozentual. Was das aber nicht berührt ist dass durch die zusätzlichen Strukturen eventuell die Latenzen in der Pipeline erhöht werden, also möglicherweise ST Leistung verloren geht wenn die physischen Strukturen auch vorhanden sind.

Der Leistungsgewinn durch SMT war beim P4 auch eher bescheiden mit durchschnittlich 5%, bei MT loads 7%. Von zweistelligen Werten wie 30% konnte man nur träumen, selbst in sehr multithreaded workloads. Entweder war die HT Implementierung noch nicht besonders gut, oder das schwache frontend mit dem 1-way decode und Tracecache hat dem P4 Core da einen Strich durch die Rechnung gemacht.

Vielleicht geht es auch ums Power Management. Wenn Intel die P-Cores besser clock gaten kann, so dass ggf. ungenutzte Execution-Ressourcen auch keine extra Energie verbrauchen, dann könnte es sinnvoller sein einen E-Core mit dem zweiten Thread zu belegen anstatt die 20-30% Speedup durch HT mit zu nehmen und dabei aber auch den maximalen Power Draw des P-Cores zu provozieren.

[Der_Korken]

Bezüglich der Flächeneffizienz sollte man noch bedenken, dass die E-Cores hier etwa doppelt so effizient sind wie P-Cores: 50% Leistung bei 25% der Fläche. Wenn ich auf 2 P-Cores einen zusätzlichen E-Core verbaue, habe ich die MT-Leistung um 25% erhöht (also etwa SMT-Level) und dafür 12,5% mehr Fläche gebraucht. SMT würde mich vielleicht nur 5% kosten, dafür brauche ich dann aber auch 4 statt 3 Threads, um das Setup auszulasten und habe allgemein einen komplexeren Kern. Wenn Intel von SMT weg geht, dann werden die sich schon überlegt haben, ob und wie sich das lohnt. Zumindest erscheint es mir nicht völlig abwegig.

[mocad_tom]

Es könnte jetzt auch mit den Tools interessant werden.

Wer hat wie viele
ASML NXE3400C
ASML NXE3600D
ASML NXE3800E (davon werden in diesen Tagen die ersten ausgeliefert)

Nicht nur die reine Anzahl, sondern auch in welcher Generation hat man welches EUV-Tool gekauft.

[ryan]

Naja, wenn Arrow Lake in 20A gefertigt ist und dann MT nur 20% bei rum kommen, dann kann das mit der Leaderchip in der Fertigung nicht so weit her sein.
Selbst ein Golden Cove mit 2 Node Sprüngen müsste deutlich mehr machen.
Aber gut, bislang gibt's kaum belastbare Informationen.


Golden Cove würde da noch weniger reißen. Jetzt stelle dir vor, der Maximaltakt sinkt von 6 auf 5.5 oder 5.0 Ghz, wie toll würde Golden Cove in N3B/20A abschneiden gegen Raptor Lake? ARL hat wenigstens IPC Verbesserungen.

Intel sieht sich in der leadership Position mit 18A, mit 20A noch nicht. 20A wäre eher nebensächlich wenn 18A dann wie geplant funktioniert. 20A war immer nur für ARL geplant. 18A ist der Prozess für Alles inklusive externer Abnehmer.

Jetzt ist heute zu lesen, dass die high end Arrow Lake tiles in N3B gefertigt werden, dafür die lower end tiles in 20A. Also auch desktop lower end bis maximal 6+8 in 20A. Das ist zu lesen in geschützen Nachrichten oder Chat Gruppen. Alles sehr widersprüchlich mit 20A im Moment.

[HOT]

MMn gibts kein 20A mehr. Ist rein fürs Engeneering von Intel, aber der Prozess wird sicherlich niemals in Massenproduktion gehen. 18A-Entwicklung läuft gut, das wird aber sicher noch bis 26 dauern. ARL besteht aus ARL und ARL-S, wobei ARL non-S nur das Featureset von MTL hat und RC+ haben soll, sehr verdächtig, und ARL-S ist N3.

[KarlKastor]

Diesmal ist Intel mit GAA progressiver und TSMC versucht sich am dichtest gepackten FINFET-Prozess(analog hierzu Intel hatte den dichtesten 10nm DUV Prozess und TSMC ist aber lieber auf EUV gegangen).

Tsmc N7 ist auch DUV und hat super funktioniert. EUV haben sie parallel entwickelt.

[mocad_tom]

TSMC N7 (der erste Prozess hatte weniger Performance, der war DUV)

TSMC N7P war auch noch rein DUV

TSMC N7+ war mit EUV und damit ging der Performance-Unterschied richtig los.

Und man konnte Designs so halb weiterverwenden und musste beim Umstieg auf N7+ nicht so viel anpassen.

Bei GAA kann man das so nicht machen. Es gibt keine "Softe" Art der Migration.

Selbst beim Pfad von TSMC N3 zu TSMC N3X bekommt man das aktuell nicht hin.

-----------------------------

Weil ich da im Kleingedruckten so noch nicht drauf geachtet habe:

Playstation 5 CPU Oberon wurde mit TSMC N7 (DUV-only) gefertigt und Oberon Plus wird mit TSMC N6 (ein paar Layer EUV) gefertigt.
Fand ich interessant. Damit ist tatsächlich zahlenmäßig das Hauptvolumen in der N7-Generation ohne EUV gelaufen.

https://www.computerbase.de/2022-09/sony-playstation-5-revision-cfi-1202-soc/

[KarlKastor]

TSMC N7 (der erste Prozess hatte weniger Performance, der war DUV)

TSMC N7P war auch noch rein DUV


Genau, deswegen passt die Aussage nicht, TSMC ist lieber auf EUV gegangen. Der Großteil der 7nm Chips kam ohne auf den Markt. Ich kenne nur ein einziges Produkt (HiSilicon), welches in N7+ hergestellt wurde.
Das war ein Versuchsträger um EUV in annähernd Massenproduktion zu testen.
Breit wurde dass dann erst später in N6 und N5 eingesetzt.


TSMC N7+ war mit EUV und damit ging der Performance-Unterschied richtig los.
Laut TSMC ist N7+ kaum leistungsfähiger als N7P.

Und man konnte Designs so halb weiterverwenden und musste beim Umstieg auf N7+ nicht so viel anpassen.

N7/N6 war nicht Designkompatibel mit N7+. Ich kenne nicht ein Chipdesign welches von N7 auf N7+ umgestiegen ist. Die sind hinterher auf N6 gegangen.

[Gipsel]

Ein paar Gedanken zu SMT (auch wenn ich Gipsel damit schon in einem Zen-Thread gelöchert habe):

1. Wenn die MT-Performance in Zukunft immer weiter auf die E-Cores ausgelagert wird, spielen die P-Cores bei MT eine immer kleinere Rolle.
2. Desktop-Systeme haben bereits heute MT-Performance noch und nöcher, die meisten User wissen gar nicht, was sie mit den ganzen Kernen anfangen sollen. Für SMT braucht man auch immer mehr Threads, um es zu nutzen und da sind bereits heute viele Anwendungen im Thread-Limit.Dann helfen E-Cores mit vergleichbarer pro-Thread-Leistung aber auch nicht wirklich, oder?
4. Das Scheduling wird komplexer, wenn man nicht nur zwei Arten von Kernen hat, sondern diese jeweils noch virtuelle Kernen haben.Zumindest sind da die Charakteristiken völlig klar und die beiden Threads eines Kerns auch völlig gleichberechtigt (gleichperformant). Das amcht das Scheduling zumindest im Prinzip nicht soo schwer.
Maximale MT-Leistung gefragt => alles vollmachen
Maximale ST-Leistung gefragt => keinen zweiten Thread auf dem Kern schedulen

Die E-Core-Geschichte ist da schon etwas schwieriger, weil da die Kerne auch unterschiedliche Performancecharakteristiken zeigen. Man kann zwar als grobe Faustregel vielleicht sagen, daß ein Thread eines P-Cores in etwa so schnell ist wie ein E-Core (wenn der P-Core 2 Threads am Laufen hat), das gilt aber eben auch je nach Situation längst nicht immer und verkompliziert die Sache dann etwas.

Eine Situation wie bei Zen4/4c ist da eher noch einfacher zu handhaben, weil die Charakteristik der Kerne für die meisten Sachen quasi gleich ist und die sich nur durch die Taktfrequenz unterscheiden (die voraussichtliche relative Performance der Kerne ist für den Scheduler also recht einfach zu ermitteln).

=====================

ja ich habe schon gesehen das ab 24 Kerne SMT schon keine Wirkung mehr gezeigt hatte.Bei Intel war es da genauso gewesen.Denke mal das dann noch mehr Kerne wohl nichts bringen.Dann hast Du halt schlicht nicht den richtigen Anwendungsfall/Software für die Hardware (und kannst beruhigt eine etwas kleinere/preiswertere CPU kaufen). Das ist kein fundamentales Problem der Hardware.Ich hoffe wenn es schon mehr E Kerne kommen werde,das man auch mittel und Wege in die Hand bekommt auch diese Optimial richtig auszulasten.Bei mangelnder Leistungsanforderung/Parallelität Deines Anwendungsfalls helfen mehr E-Cores dann allerdings überhaupt nicht. Eher im Gegenteil. ;)

[Gipsel]

Bezüglich der Flächeneffizienz sollte man noch bedenken, dass die E-Cores hier etwa doppelt so effizient sind wie P-Cores: 50% Leistung bei 25% der Fläche. Wenn ich auf 2 P-Cores einen zusätzlichen E-Core verbaue, habe ich die MT-Leistung um 25% erhöht (also etwa SMT-Level) und dafür 12,5% mehr Fläche gebraucht. SMT würde mich vielleicht nur 5% kosten, dafür brauche ich dann aber auch 4 statt 3 Threads, um das Setup auszulasten und habe allgemein einen komplexeren Kern.Nur ist der P-Kern mit einem Thread eben noch nicht wirklich ausgelastet. Wenn man von Deinen Leistungszahlen ausgeht:
P-Kern ohne SMT: Leistung 1
E-Kern ohne SMT: Leistung 0,5
P-Kern mit SMT: Leistung 1,25 (mit 2 Threads)

Dann erreichen 2 P-Kerne mit SMT und 4 Threads die gleiche MT-Leistung (2,5) wie 2 P-Kerne ohne SMT + 1 E-Kern auf etwas niedrigerer Fläche.
Nur haben wir eben jetzt schon die Kombination aus P- und E-Kernen und was spricht dagegen, das zu kombinieren, um bei Problemen mit größerer Parallelität noch mehr Leistung rauszuquetschen? Die Alternative zu 2 P- ohne SMT + 1 E-Kern ist eben nicht 2 P-Kerne mit SMT sondern 2 P-Kerne mit SMT + 1 E-Kern (Leistung 3 mit 5 Threads) mit relativ gesehen niedrigerem Flächenoverhead für die MT-Mehrleistung. Im Fall weniger Threads hat man mindestens die gleiche Leistung, im Fall mit mehr Parallelität eine höhere. Dazwischen hat man maximal ein paar Corner Cases.

PS:
Bei den alten intel-Zahlen zum Flächenoverhead bezog man sich afair auf die reine Core-Area (ohne Caches).

PPS:
Intel hat vermutlich noch ein paar Reserven bei der Flächenoptimierung, wenn man sich mal Zen4 und Zen4c ansieht. Zen4c ist ja nur minimal größer als ein E-Core.

[mocad_tom]

@KarlKastor

Auf einer Zeitachse war der TSMC N7+-Prozess für TSMC der erste Prozess, bei dem EUV eingesetzt wurde.

Der HiSilicon Kirin 990 (mit N7+ und EUV) kam im November 2019 mit dem Huawei Mate Pro auf den Markt.

TSMC N5 mit dem Apple A14 kam erst im September 2020 (auch wieder mit ein paar Layer EUV).

Sie haben den N7+ Prozess vermarktet und damit hat man sich dann als Technologieführer abgesetzt.

[HOT]

Klitzekleine Ergänzung nur im genau zu sein:
Kirin 990 -> N7
Kirin 990 5G -> N7+

https://www.hisilicon.com/en/products/Kirin/Kirin-flagship-chips/Kirin-990-5G

[KarlKastor]

@mocad_tom
Ich verstehe nicht, was du mir damit sagen möchtest. Ich sagte ja, dass N7+ der erste mit EUV war. Nur eben in sehr kleiner Stückzahl. Die Masse hat man mit N7 aber in DUV bedient. Im Gegensatz zu Intel hat man das halt relativ problemlos hinbekommen.

[Zossel]

Eine Situation wie bei Zen4/4c ist da eher noch einfacher zu handhaben, weil die Charakteristik der Kerne für die meisten Sachen quasi gleich ist und die sich nur durch die Taktfrequenz unterscheiden

Das "quasi" kann man eigentlich weglassen:

https://www.techpowerup.com/img/tURCxsYBNANET3BI.jpg

[basix]

16MByte L3$ anstatt 32MByte. "Quasi" ist also nicht so verkehrt ;)

In vielen Anwendung spielt das faktisch keine Rolle. Bei Spielen, CAD usw. sehr wohl

[HOT]

Da ist ja nur der Gesamtcache entscheidend. Aber ist ja auch logisch, wenn die Cores nur halb so groß sind, dass man schon rein platztechnisch nur halben L3 im gleichen CCX haben kann, wenn man Phoenix2 betrachtet z.B..

[ryan]

MMn gibts kein 20A mehr. Ist rein fürs Engeneering von Intel, aber der Prozess wird sicherlich niemals in Massenproduktion gehen. 18A-Entwicklung läuft gut, das wird aber sicher noch bis 26 dauern. ARL besteht aus ARL und ARL-S, wobei ARL non-S nur das Featureset von MTL hat und RC+ haben soll, sehr verdächtig, und ARL-S ist N3.



20A ARL-S 6+8 kommt einfach für den gecancelten MTL-S 6+8, das passt schon. Mobile ist undurchsichtiger bis auf ARL-U. 18A hat den großen Vorteil eine optimierte Version von 20A zu sein. Die großen Neuerungen GAA und PowerVia kommen schon mit 20A. Ansonsten könnte der ja auch nicht (nach der Planung) so zeitnah nach 20A kommen. Sieht man auch an der internen Bezeichnung, nur die Nachkommastelle ändert sich.


P1276.31= Intel 4
P1276.4/5= Intel 3

P1278.2= 20A
P1278.3= 18A
P1278.6= xx

P1280.2= xx

[iamthebear]

Bei Spielen ist die Gesamtmenge des L3 relativ egal. Entscheidend ist die Menge pro CCX, denn das ist die Menge die effektiv genutzt wird.
Hat man 2 CCX mit je 16MB, so werden in beiden L3s großteils dieselben Daten doppelt drin stehen.
Das hat man beim Wechsel von Zen2 auf Zen3 sehr gut gesehen was ein Unified L3 bringt bzw. Gegenbeispiel der 7950X ist nicht schneller als der 7700X in Spielen trotz mehr L3.

Ähm... das Video und die Folie von igor sagt glasklar, dass für die interne Performance-Projektion RTL-R auf PL1=PL2=253W und ARL-S auf PL1=PL2=250W angenommen wurden.

Auf der Folie steht nur, dass die TDP Grenze auf 250W eingestellt wurde. Das bedeutet nicht, dass auch wirklich so viel verbraucht wurde bzw. verbraucht werden kann.

Wenn ich das grob überschlage:
Das MTL Compute Die hat ca. 40mm²
MTL 8+16 würde dann wohl um die 100-120mm² liegen in Intel 4.

ARL 8+16 dürfte in 20A dann wohl grob bei <= 80mm² liegen

Wie zur Hölle sollen denn da 250W abgeführt werden können?

Zum Vergleich:
5800X und 7700X haben eine vergleichbare CCD Größe und 140W und sind schon ziemliche Hitzköpfe.

Bob Swan hat da wohl lange mit der Entscheidung gezögert, weil dadurch halt Kapital aus dem Gesamtunternehmen abfließt, das sonst nur von einem Firmenzweig zum anderen wandern würde, und er vmtl. auch die eigenen Foundry-Leute nicht vor den Kopf stoßen wollte.
Die endgültige Entscheidung pro TSMC N3 ist für einige Chips vmtl. erst unter Gelsinger gefallen, als Keller, Murthy und Swan weg waren.

Also ich habe da das Gegenteil gehört nämlich, dass Bob Swan ein starker Befürworter von TSMC war, da er sich mangels Fachkompetenz firmenintern nie gegen die Leute aus der Fertigung durchsetzen konnte und er sie so an der kurzen Leine halten konnte.

Genau, es könnten auch einfach eine Packaging- und Kapazitätsentscheidung sein. Intel besitzt nicht soviele EUV Belichter wie TSMC und die Foveros Packaging Linien wurden bisher nur für ein paar Nischenprodukte genutzt. Für MTL und RTL müssen beide Fertigungstrecken um ein vielfaches Wachsen. Es kann gut sein dass der gleichzeitige Rampup beider Technologien für den mainstream aus Prozessunabhängigen Gründen länger dauert. Vielleicht ist es auch die hohe (interne) Nachfrage von Intel4 und Intel3 die das blockiert. Man darf nicht vergessen dass Intel vor kurzem noch der größte Chiphersteller der Welt war und 80% aller PC-CPUs ausliefert. Da reicht es nicht wenn man ein gutes Produkt hat und rechtzeitig am Markt ist, man muss auch in entsprechenden Stückzahlen liefern können.

Das war früher auch mein Gedanke, dass man bei Intel 4 zu Chiplet gezwungen wurde, da die Kapazität für monolithische Kerne nicht da ist. War ja bei AMD auch ähnlich.

Nur warum versucht Intel dann gerade die neuen Nodes im Foundry Business zu vermarkten. Wenn man schon keine Kapazität für die eigenen Produkte hat wieso bietet man dann 18A Kapazitäten an ARM, Nvidia etc. an. Als Foundry wird die Marge mit Sicherheit weit unter dem liegen was man mit den eigenen Produkten macht und erlaubt AMD Marktanteile in Bereichen zu holen, wo sie normalerweise nie rein kommen würden.

Es waren 5% Transistoren, bzw. 2-3Mio bei Northwood laut Intel. Heutzutage dürfte das noch weniger sein prozentual. Was das aber nicht berührt ist dass durch die zusätzlichen Strukturen eventuell die Latenzen in der Pipeline erhöht werden, also möglicherweise ST Leistung verloren geht wenn die physischen Strukturen auch vorhanden sind.

Was ist mit dem Branch Predictor und dem ganzen OoO Scheduling? Muss das nicht auch alles doppelt vorhanden sein bei 2 Threads und diese unabhängig voneinander analysieren?

Der Leistungsgewinn durch SMT war beim P4 auch eher bescheiden mit durchschnittlich 5%, bei MT loads 7%. Von zweistelligen Werten wie 30% konnte man nur träumen, selbst in sehr multithreaded workloads. Entweder war die HT Implementierung noch nicht besonders gut, oder das schwache frontend mit dem 1-way decode und Tracecache hat dem P4 Core da einen Strich durch die Rechnung gemacht.

Ich denke das Hauptproblem war damals eher, dass es noch so gut wie keine Software gab, die mit 2 Kernen umgehen konnte egal ob physisch oder virtuell.
Bei den wenigen Anwendungen die das konnten war der Unterschied aber gar nicht so gering:
https://www.computerbase.de/2002-11/test-intel-pentium-4-3066-mhz/15/#abschnitt_setihome

Die Frage die ich mir stelle ist:
Wenn SMT weiterhin nur 5% die size kostet warum nutzen Apple oder ARM es dann nicht? Gerade Apple mit seinen ganzen Multimediaanwendungen und immer gut optimierter Software dürfte da doch noch mehr profitieren.

Bezüglich der Flächeneffizienz sollte man noch bedenken, dass die E-Cores hier etwa doppelt so effizient sind wie P-Cores: 50% Leistung bei 25% der Fläche. Wenn ich auf 2 P-Cores einen zusätzlichen E-Core verbaue, habe ich die MT-Leistung um 25% erhöht (also etwa SMT-Level) und dafür 12,5% mehr Fläche gebraucht. SMT würde mich vielleicht nur 5% kosten, dafür brauche ich dann aber auch 4 statt 3 Threads, um das Setup auszulasten und habe allgemein einen komplexeren Kern. Wenn Intel von SMT weg geht, dann werden die sich schon überlegt haben, ob und wie sich das lohnt. Zumindest erscheint es mir nicht völlig abwegig.

Das mit dem 1:4 Verhältnis bei der Fläche ist leider nur die Theorie. In der Praxis sieht es ca. so aus:
.) 1 P Core hat die Fläche von 3 e Cores
.) 1 P Core ohne SMT hat 1.8x Performance
.) 1 P Core mit SMT hat 2.5x Performance

SMT darf also die P Core Fläche um maximal (2.5 -1.8) * 1/3 = 23% erhöhen damit es noch Sinn macht.

Da SMT im Datacenterbereich aber großteils aus Sicherheitshgründen nicht nutzbar ist wird es Intel wohl schon bei knapp 20% fallen lassen.

[Zossel]

Was ist mit dem Branch Predictor und dem ganzen OoO Scheduling? Muss das nicht auch alles doppelt vorhanden sein bei 2 Threads und diese unabhängig voneinander analysieren?
Auch bei nur einem Thread gibt es bei einer OOO-Maschine nach einem Branch in der Zukunft 2 Quasi-Threads.

Ich denke das Hauptproblem war damals eher, dass es noch so gut wie keine Software gab, die mit 2 Kernen umgehen konnte egal ob physisch oder virtuell.
Im Userspace kann man sowieso nicht unterscheiden ob das ein "physikalischer" oder "virtueller" Thread ist. (Außer durch spezielle Abfragen oder Seitenkanäle)
Die Frage die ich mir stelle ist:
Wenn SMT weiterhin nur 5% die size kostet warum nutzen Apple oder ARM es dann nicht? Gerade Apple mit seinen ganzen Multimediaanwendungen und immer gut optimierter Software dürfte da doch noch mehr profitieren.
Frag Apple, und mittlerweile wünsche ich mir das Apple das endlich einbaut damit nicht ständig irgendein Marketingopfer denkt das kein SMT ein Teil der (nicht existierenden) secret sauce ist.

Da SMT im Datacenterbereich aber großteils aus Sicherheitsgründen nicht nutzbar ist wird es Intel wohl schon bei knapp 20% fallen lassen.

Das ist eine unzulässige Verallgemeinerung.

[Zossel]

16MByte L3$ anstatt 32MByte. "Quasi" ist also nicht so verkehrt ;)

Was ist ein Core?

[mocad_tom]

@KarlKastor

Quintessenz dessen was ich sagen will:

Intel / Samsung / TSMC hocken sich hin und machen Pathfinding für die einzelnen Nodes.

Sprich TSMC hat für sich beschlossen bei TSMC N7+ EUV einzusetzen.
Intel hat bei diesem Pathfinding-Prozess bei Intel 10nm (später dann Intel 7) beschlossen nur DUV zu machen.

Die Risikobereitschaft von TSMC hat sich ausgezahlt, Intel kam ins hintertreffen, die EUV-Technologie half N7+/N6/N5 zu verbessern.

GAA ist wieder so ein Technologiemeilenstein / so eine Technologiehürde / aber auch ein möglicher Technologiebeschleuniger

TSMC hat innerhalb ihres Pathfindings beschlossen GAA erst in TSMC N2 zu verwenden.

Jetzt wird es spannend, ob es sich auszahlt dass man bei TSMC N3 auf GAA verzichtet hat, oder ob GAA die Eigenschaften beim Intel 20A / Intel 18A so verbessert, dass der Prozess schneller schönere Yields zustande bringt.

Ich glaube man darf die Gerüchte mit Intel Arrow Lake mit Intel 20A eher negativ einschätzen. Das ist eine massive Strukturverkleinerung und man wäre damit TSMC dann wirklich enteilt. Aber der Teufel liegt im Detail und bei den Verzögerungen war Intel schmallippig und ist TSMC schmallippig.

Intel 3 schließt weitgehend mit TSMC N4 auf - ich glaube wir sehen einen Desktop-Prozessor im Intel 3-Prozess und mit recht wenig EMIB oder Foveros Gedöns. Ein Granite-Rapids soweit eingedampft, dass er in den Sockel 1851 reinpasst.

[HOT]

Intel hat sich als letztes für GAA entschieden, das wird gerne vergessen.
Samsung war bei GAA vorne und hat als erstes den Pfad festgelegt, danach TSMC, danach erst Intel. Entsprechend ist Samsung jetzt soweit und hat den ersten Chip in GAA Massenproduktion, TSMC wird ab Ende 24 N2 in Massenproduktion haben, Intel wird frühestens in 25 soweit sein. Intel hat folgenden Weg eingeschlagen: 14nm -> 10nm (I7 umbenannt) -> 7nm (EUV, I3 und I4 genannt) -> 20A/18A (GAA). Man braucht sicher keiner Illusion hingeben, dass Intel 7nm quasi direkt überspriingen wird ;). Das wird seine Zeit brauchen und wir werden Intel3 und 4 ein paar Jahre haben.

[w0mbat]

Hat 20A/18A nicht auch backside power delivery? Also zusätzlich zu GAA? Intel nimmt sich ziemlich viel auf einmal vor, war schon bei 10nm das Problem.

Wisst ihr, ab wann Intel high-NA einsetzten will?

[mocad_tom]

Intel Clearwater Forest angekündigt für 2025

https://www.golem.de/news/server-roadmap-intel-kuendigt-sierra-forest-mit-144-kernen-an-2303-173077.html

TSMC N2

https://www.anandtech.com/show/17356/tsmc-roadmap-update-n3e-in-2024-n2-in-2026-major-changes-incoming

"Our progress so far today for the N2 is on track," said Mr. Wei. "All I want to say is, yes, at the end of 2024, [N2] will enter the risk production. 2025, it will be in production, probably close to the second half or the – or the end of 2025. That is our schedule."


https://www.eetimes.com/tsmcs-3-nm-push-faces-tool-struggles/

TSMC has delayed the introduction and ramp of 3 nm due to a need to adopt multi-patterning with EUV lithography from tool supplier ASML, Hosseini said.

“While the high cost of EUV multi-patterning has made the cost/benefit of EUV unattractive, loosening the design rules to minimize the number of EUV multi-patterning layers has led to a much higher die size,” Hosseini said. The “real” 3-nm node will not scale until a higher-throughput EUV system, ASML’s NXE:3800E, is available during the second half of 2023, he added.

The NXE:3800E will help improve wafer throughput by about 30% over the current NXE:3600D by lowering the overall cost of EUV multi-patterning, according to Hosseini.

TSMC will accelerate adoption of the NXE:3800E in the first half of 2024 as the foundry scales N3E and other variations of the 3-nm node for more customers, Hosseini said in the report.

Derjenige, der am meisten DXE:3800E-Maschinen bekommt, der gewinnt das nächste Rennen.
Intel 18A und TSMC N2 wird mit diesen Maschinen arbeiten.

TSMC N2 ist dichter als Intel 18A - es wird spannend, ob TSMC mit den NXE:3800E Maschinen N2 so bearbeiten kann, oder ob die dort erneut warten müssen, bis die EXE:5200 ausgeliefert werden.

[ryan]

Intel hat sich als letztes für GAA entschieden, das wird gerne vergessen.
Samsung war bei GAA vorne und hat als erstes den Pfad festgelegt, danach TSMC, danach erst Intel. Entsprechend ist Samsung jetzt soweit und hat den ersten Chip in GAA Massenproduktion, TSMC wird ab Ende 24 N2 in Massenproduktion haben, Intel wird frühestens in 25 soweit sein. Intel hat folgenden Weg eingeschlagen: 14nm -> 10nm (I7 umbenannt) -> 7nm (EUV, I3 und I4 genannt) -> 20A/18A (GAA). Man braucht sicher keiner Illusion hingeben, dass Intel 7nm quasi direkt überspriingen wird ;). Das wird seine Zeit brauchen und wir werden Intel3 und 4 ein paar Jahre haben.


TSMC peilt H2 2025 für den Massenstart, die sind am weitesten von GAA entfernt. Bei der backside power delivery noch weiter, der kommt erst mit N2P.



Intel 18A und TSMC N2 wird mit diesen Maschinen arbeiten.


Intel hat von High-NA bei 18A Abstand genommen und würde sich ja auch gar nicht ausgehen. An eine Umstellung mitten im life cycle von 18A glaube ich nicht, das würde doch dann Intel anders nennen. In der Roadmap gibt es eine weitere optimierte P1278 Version, welche sich dafür anbieten würde. Oder sogar erst mit dem nächsten major shrink P1280.

Von N2 mit High-NA ist mir nichts bekannt, gibt es dazu offizielle Aussagen?



TSMC N2 ist dichter als Intel 18A -


Redest Du von der semiwiki Prognose?

2024 – in the first half Intel 20A (20 angstrom = 2nm) process is due with a 15% performance improvement. This will be Intel’s first HNS (they call it RibbonFET) and they will also introduce back side power delivery (they call this PowerVia). The backside power delivery addresses IR power drops while making front side interconnect easier. We are estimating a 1.6X density improvement. In the second half of 2024 Intel’s 18A process is due with a 10% performance improvement. We are estimating a 1.06X density improvement making this another half node. This process has been pulled in from 2025 and Intel says they have delivered test devices to customers.
https://semiwiki.com/semiconductor-services/techinsights/310900-can-intel-catch-tsmc-in-2025/


Weil von Intel gibt es meines Wissens nach keine Angabe. Von TSMC gibt es Angaben:

N3E vs N5 1.3x
N2 vs N3E 1.15x
https://www.anandtech.com/show/18832/tsmc-outlines-2nm-plans-n2p-brings-backside-power-delivery-in-2026-n2x-added-to-roadmap

Woraus liest Du ein N2 dichter als 18A?

[basix]

Von N2 mit High-NA ist mir nichts bekannt, gibt es dazu offizielle Aussagen?

Offiziell nicht. Die meisten gehen aber davon aus.

Falls es TSMC ohne High-NA hinbekommt, wäre das ein Vorteil verglichen mit Intels 18A.

[HOT]

Glaubt jemand ernsthaft, dass CF pünktlich in 25 kommt? :freak: Produktionsbeginn vielleicht, wenn alles glatt läuft... Ist doch wieder typisch Intel... Außerdem musste das Marketing was unternehmen, Intel verliert immer mehr wichtige Kunden, die muss man irgendwie bei der Stange halten.
MTL kommt Ende 22, MTL kommt Mitte 23, MTL kommt Q3 23, MTL kommt Q4 23 und was wird es werden? Hoffentlich CES24... klar was ich meine? Bei TSMC hab ich mich vertan, meinte Ende 25. Aber das sollte verdeutlichen, was 18A überhaupt für ein Projekt ist. Das macht man eben nicht mal einfach so in 3 Jahren. Da gehört auch ne gehörige Portion richtige Entscheidungen und auch Glück dazu.

N2 soll AFAIK kein HighNA verwenden und auch keine backside Powerdelivery, wie TSMC das nennt. N2 ist nur Nanosheets. N2P bringt dann die PowerVIAs und <N2 wird dann HighNA. Auch bei 18A sollte das doch jetzt nicht mehr zum Einsatz kommen.

Ich mach mal einen höchst spekulativen und subjetiven Plan, wie ich die Entwicklung bei Intel in der nächsten Zeit sehe:

Okt.23 RPL-R
Anfang 24 MTL-P (I4+N5), RPL-R-H, RPL-R-P, ER als SR-Ergänzung, SR-Refresh
Q3 24 SF (I3)
Q4 24 GR (I3), ARL-S (N3B+N4(BM))
Q1 25 ARL (MTL-R, I3/4+N4)
1H 25 SF Refresh
2H 25 ARL-R (N3X?), GR-R (?Intel3+PowerVIA?)
irgendwann in 26 Nova Lake (Panther Lake) (Cougar Cove) und CF beide 18A.

MMn macht auch Intel jetzt eins nach dem anderen, nicht mehr alles gleichzeitig. Ursprünglich wollte man PowerVIAs und Nanosheets gleichzeitig bringen, das findet mMn jetzt nicht mehr statt. Wir sahen erste Samples mit Intel4+PowerVIAs, erstmal nur mit 2 FINs, was natürlich übelstes low-power nur ist. Man wird erst mal versuchen, das jetzt Produktionsreif zu bekommen. Und das dürfte dann in einem Intel3-Prozess mit PowerVIAs münden mMn, welcher sicherlich auch eingesetzt werden wird. Die Nanosheets kommen dann mit 18A und High-NA dann mit dem Nachfolgeprozess dazu, dann hat man die 3 wichtigen Baustellen schonmal gestreckt und dann wirds auch realistisch das fertig zu bekommen.

[amdfanuwe]

Worauf läuft das eigentlich für Desktop hinaus?
Für Games reichen 8 Cores und viel Cache, Profis arbeiten in der Cloud oder mit Workstations.
Einziges PRO für Desktop ist doch eigentlich, dass man sich ne dicke GPU reinstecken kann.
Was soll da noch die CPU Entwicklung für Desktop bringen?
Ein paar MHz mehr bei geringerem Verbrauch.

Also bei neuen zukünftigen Nodes geht es vornehmlich um Mobile und HPC Systeme.
Für Desktop als zunehmend kleinere Nische würde ich da von Intel nicht zu viel erwarten.

[HOT]

Man sieht ja, dass man für Desktop schon auf TSMC ausweicht, was ja dafür spricht, dass man nicht mehr so irre viel Marktanteil erwartet. Außerdem haben wir ja mit ARL offensichtlich eine Konzentration auf mehr IPC und weniger Takt, Mobilfähigkeit und die Möglichkeit mehr Kerne powereffizient in Server-CPUs unterzubringen, also auch hier eher eine Abkehr von großen, hochgetakteten Kernen für möglichst viel SC-Performance. Intel orientiert sich offensichtlich mehr in Richtung Apple als die bisherige Intel-Strategie weiter zu verfolgen. AMD geht mit den Compact-Kernen einen etwas anderen, interessanten Weg.

[amdfanuwe]

AMD geht mit den Compact-Kernen einen etwas anderen, interessanten Weg.
AMD diversifiziert und durch das Chiplet Design fallen auch gute Desktop CPUs ohne hohen Aufwand ab.
Zudem ist das Package ohne Interposer/Bridges sehr billig.

[KarlKastor]

Die Risikobereitschaft von TSMC hat sich ausgezahlt, Intel kam ins hintertreffen, die EUV-Technologie half N7+/N6/N5 zu verbessern.

Es gab keine Risikobereitschaft, weil N7 komplett ohne EUV war. Man hat sich lediglich den Luxus gegönnt parallel N7+ zu bringen, quasi als Kleinserie anstatt reine Labortestung. Das ist ne Investition um EUV schneller zur Marktreife zu entwickeln, hat aber null Risiko. Wenn N7+ komplett untauglich gewesen wäre und N6 erst ein Jahr später gekommen, hätte das rein gar keinen Einfluss auf TSMCs Geschäftszahlen gehabt.

Samsung ist auf Risiko gegangen, allerdings grandios gescheitert.

[y33H@]

Okt.23 RPL-R
Anfang 24 MTL-P (I4+N5), RPL-R-H, RPL-R-P, ER als SR-Ergänzung, SR-Refresh
Q4 24 GR (I3), ARL-S (N3B+N4(BM))
Q1 25 ARL (MTL-R, I3/4+N4), Sierra Forest
2H 25 ARL-R (N3X?), GR-R (?Intel3+PowerVIA?)
irgendwann in 26 Nova Lake (Cougar Cove) und CF beide 18A.Orientiere doch wenigstens an dem, was öffentlich ist - SFR in H1/24 und GRN kurz danach, CWF für 2025. Zudem wurde weder Intel 4 noch Intel 3 mit PowerVia als Node für Produkte angekündigt, sondern einzig 20A und 18A.

https://www.intel.com/content/www/us/en/newsroom/news/four-takeaways-from-intel-investor-webinar.html

[mocad_tom]

@ryan

Das war mal ein Diagramm, das so rumgegeistert ist und das auch ziemlich viel Wahrheitsgehalt hatte.

https://twitter.com/p1cturedump/status/1665330268058664961

Nur wurde der entsprechende Intel-Prozess in diesem Diagramm immer als 5-10% zu positiv angesetzt.

TSMC N2 setzt auf normales EUV und noch nicht auf EUV High-NA.

Also setzt TSMC auf NXE:3800E für N2 - nur ist der N3-Prozess jetzt schon so schwierig, dass TSMC gerade auf die neuen NXE:3800E-Maschinen für den N3-Prozess wartet und diesen Prozess dann lieber damit macht.

Intel scheint sich so zwischen die N5 und N3 reingeparkt zu haben -> das ist Intel 3 und der läuft gut mit NXE:3600D

Und Intel hat sich gut zwischen N3 und N2 reingeparkt das ist dann Intel 18A und der wird gut mit NXE:3800E zusammenarbeiten.

Für Intel 14A benötigt Intel dann High-NA.

Ich weiß aber nicht, ob TSMC bei N2 unglücklich agiert hat und sich dort zu viel vorgenommen hat und praktisch wieder zwischen NXE:3800E und EXE:5200(High-NA) ist.

Mit einer viel zu coolen Belichtungsmaschine einen Schnarchprozess hinzubekommen ist kein Problem. Z.B. mit NX:E3800E einen TSMC N6 aufzusetzen ist kein Problem.

[HOT]

Orientiere doch wenigstens an dem, was öffentlich ist - SFR in H1/24 und GRN kurz danach, CWF für 2025. Zudem wurde weder Intel 4 noch Intel 3 mit PowerVia als Node für Produkte angekündigt, sondern einzig 20A und 18A.

https://www.intel.com/content/www/us/en/newsroom/news/four-takeaways-from-intel-investor-webinar.html
Was Intel öffentlich macht ist seit Jahren BS, das ist das Problem.

[ryan]

Ich mach mal einen höchst spekulativen und subjetiven Plan, wie ich die Entwicklung bei Intel in der nächsten Zeit sehe:

Okt.23 RPL-R
Anfang 24 MTL-P (I4+N5), RPL-R-H, RPL-R-P, ER als SR-Ergänzung, SR-Refresh
Q4 24 GR (I3), ARL-S (N3B+N4(BM))
Q1 25 ARL (MTL-R, I3/4+N4), Sierra Forest
2H 25 ARL-R (N3X?), GR-R (?Intel3+PowerVIA?)
irgendwann in 26 Nova Lake (Cougar Cove) und CF beide 18A.



Nimm doch erstmal die richtigen Generationen, das wäre nach Arrow Lake Panther Lake. Wahrscheinlich wirst du schon beim zweiten falsch liegen, weil MTL-P sollte schon in Q4 kommen. Es gibt keinerlei Indizien für eine Verschiebung, ich meine es gibt schon QS Modelle. Aber gut, drauf los spekulieren kann man immer viel wenn der Tag lang ist.


@ryan

Das war mal ein Diagramm, das so rumgegeistert ist und das auch ziemlich viel Wahrheitsgehalt hatte.

https://twitter.com/p1cturedump/status/1665330268058664961




Das sieht nach einem user selfmade Diagramm aus, darauf würde ich nicht viel geben. Oder worauf basiert das? Der Sprung von N3 auf N2 ist gewaltig, wie kommt das bei 1.15x zustande?

[HOT]

Nimm doch erstmal die richtigen Generationen, das wäre nach Arrow Lake Panther Lake. Wahrscheinlich wirst du schon beim zweiten falsch liegen, weil MTL-P sollte schon in Q4 kommen. Es gibt keinerlei Indizien für eine Verschiebung, ich meine es gibt schon QS Modelle. Aber gut, drauf los spekulieren kann man immer viel wenn der Tag lang ist.

lt. MLID ist Panther Cove und damit mMn auch Panther Lake gecancelt.

Okt.23 RPL-R
Anfang 24 MTL-P (I4+N5), RPL-R-H, RPL-R-P, ER als SR-Ergänzung, SR-Refresh
Q3 24 SF (I3)
Q4 24 GR (I3), ARL-S (N3B+N4(BM))
Q1 25 ARL (MTL-R, I3/4+N4)
1H 25 SF-Refresh
2H 25 ARL-R (N3X?), GR-R (?Intel3+PowerVIA?)
irgendwann in 26 Nova Lake (?Panther Lake?) (Cougar Cove) und CF beide 18A.

aktualisiert nach der Kritik.


Das sieht nach einem user selfmade Diagramm aus, darauf würde ich nicht viel geben. Oder worauf basiert das? Der Sprung von N3 auf N2 ist gewaltig, wie kommt das bei 1.15x zustande?

Jo sieht nach Unsinn aus. MMn hat jeder Prozessnode (Intel3/4 ist einer) mindestens 10 Produkte und keinesfalls nur 6.

[ryan]

lt. MLID ist Panther Cove und damit mMn auch Panther Lake gecancelt.



Es bleibt trotzdem Panther Lake. Übrigens ist das schon länger bekannt, was MLID sagt ist nichts Neues.


Panther used Cougar instead of Panther.
https://twitter.com/OneRaichu/status/1590761980838936576?t=jEYfyAgBcMlHxzserJeaQQ&s=19



Panther Cove sollte urspünglich mit Nova Lake kommen. Es macht also noch weniger Sinn Nova Lake nach Arrow Lake anzusetzen. Von Nova Lake selber ist nichts mehr zu lesen, dafür von Panther Lake umso mehr, zum Beispiel auch hier (https://il.linkedin.com/in/arnold-cheskis) oder hier (https://www.tomshardware.com/news/panther-lake-50-percent-more-efficent-vs-alder-lake).

Increased performance on Alder, Lunar, and Panther Lake projects

[iamthebear]

Auch bei nur einem Thread gibt es bei einer OOO-Maschine nach einem Branch in der Zukunft 2 Quasi-Threads.

Wird denn der Alternativzweig wirklich weiter verfolgt? Ein paar Daten aus dem L1 vorladen macht ja eventuell noch Sinn aber Berechnungen kann ich mir nicht wirklich vorstellen. Dachte das wäre seit dem Netburst Ende vorbei.

Im Userspace kann man sowieso nicht unterscheiden ob das ein "physikalischer" oder "virtueller" Thread ist. (Außer durch spezielle Abfragen oder Seitenkanäle)

Unterscheiden kann man es nicht aber die Performance könnte sich anders verhalten.
Eine sehr speicherlastige Anwendung wird z.B. eher schlechter mit der Kernanzahl skalieren aber SMT wird sich sehr ähnlich wie 2 echte Kerne verhalten, da im Kern selbst ja fast alles dahin idlet.
Eine sehr rechenintensive Anwendung wird vermutlich zwar vielleicht sehr gut mit der Kernanzahl skalieren aber SMT wird hier gegenüber 2 echten Kernen weiter zurück liegen, da die Ressourcen im Kern eben stärker belegt sind.

Aber damals um 2003 herum war das beides nicht der Fall. Da war das Hauptproblem, dass so gut wie alle Anwendungen rein ST waren und da bringen dann weder SMT nocht mehr Kerne etwas. Diese Anwendungen muss man bei solchen Diskussionen immer ausklammern.

Frag Apple, und mittlerweile wünsche ich mir das Apple das endlich einbaut damit nicht ständig irgendein Marketingopfer denkt das kein SMT ein Teil der (nicht existierenden) secret sauce ist.

Nur SMT weg zu lassen ist wohl kaum die Lösung für AMD/Intel aber irgendeinen Grund wird es schon haben warum alle ARM Designs kein SMT unterstützen und ich denke nicht, dass das irgendetwas mit dem Befehlssatz an sich zu tun hat.

Das ist eine unzulässige Verallgemeinerung.

Klar trifft das nicht auf alle Server zu aber zumindest auf alle Cloudprovider wo Daten von verschiedenen Kunden auf demselben physischen Server gehostet werden und der Kunde eigenen Native Code ausführen kann.

Ich weiß nicht ob das die Regel war aber zumindest einige HPE Server (auch die kleinen) wurden schon vor der ganzen Meltdown Sache mit SMT default off ausgeliefert.

Intel hat sich als letztes für GAA entschieden, das wird gerne vergessen.
Samsung war bei GAA vorne und hat als erstes den Pfad festgelegt, danach TSMC, danach erst Intel. Entsprechend ist Samsung jetzt soweit und hat den ersten Chip in GAA Massenproduktion, TSMC wird ab Ende 24 N2 in Massenproduktion haben, Intel wird frühestens in 25 soweit sein. Intel hat folgenden Weg eingeschlagen: 14nm -> 10nm (I7 umbenannt) -> 7nm (EUV, I3 und I4 genannt) -> 20A/18A (GAA). Man braucht sicher keiner Illusion hingeben, dass Intel 7nm quasi direkt überspriingen wird ;). Das wird seine Zeit brauchen und wir werden Intel3 und 4 ein paar Jahre haben.

Daran habe ich auch immer gezweifelt und ehrlich gesagt hat mich das sehr an die letzten Atemzüge von GF leading Nodes erinnert.
Aber anscheinend sehen das die meisten Spezialisten aus der Branche anders und sehen 18A sehr positiv.

Was das Releasedatum angeht, so muss man unterscheiden zwischen der Verfügbarkeit des Prozesses an sich und dem Release der ersten echten Produkte.
Intel 4 ist z.B. schon die ganze Zeit bereit für die Massenproduktion. Es gibt nur noch kein Produkt dazu.

Als grober Anhaltspunkt:
Schau dir an wann TSMC 5nm veröffentlicht wurde und schau dir an ab wann AMD die erste CPU damit gebaut hat.

Redest Du von der semiwiki Prognose?

https://semiwiki.com/semiconductor-services/techinsights/310900-can-intel-catch-tsmc-in-2025/

Weil von Intel gibt es meines Wissens nach keine Angabe. Von TSMC gibt es Angaben:

N3E vs N5 1.3x
N2 vs N3E 1.15x
https://www.anandtech.com/show/18832/tsmc-outlines-2nm-plans-n2p-brings-backside-power-delivery-in-2026-n2x-added-to-roadmap

Woraus liest Du ein N2 dichter als 18A?

Die Frage ist, ob hier nicht generell Äpfel mit Birnen verglichen werden. Es gibt sehr viel Spielraum innerhalb des Prozesses, ob auf Performance oder Transistordichte optimiert wird und dieser Spielraum scheint eher Größer zu werden.

Falls es TSMC ohne High-NA hinbekommt, wäre das ein Vorteil verglichen mit Intels 18A.

Wenn beide kein High NA verwenden wo ist dann der Vorteil für TSMC?

[Zossel]

Derjenige, der am meisten DXE:3800E-Maschinen bekommt, der gewinnt das nächste Rennen.
Intel 18A und TSMC N2 wird mit diesen Maschinen arbeiten.

TSMC N2 ist dichter als Intel 18A - es wird spannend, ob TSMC mit den NXE:3800E Maschinen N2 so bearbeiten kann, oder ob die dort erneut warten müssen, bis die EXE:5200 ausgeliefert werden.

Wie viele von den EUV Layern müssen den mit den richtig guten Maschinen belichtet werden?

[basix]

Was ist ein Core?

:rolleyes:

Es ging um die (Performance-)Charakteristik der Kerne (=das was hinten raus kommt). Und die wird vom L3$ im CCX beeinflusst. Wenn du den Kern in einem hypothetischen und real nicht existierenden Chip ohne L3$ vergleichen willst, von mir aus. Das ist aber eine akademische Übung ohne Praxisrelevanz.

Wenn du bei Zen 4 & 4c die gleiche Menge an L3$ verbaust, ja dann besteht kein Unterschied im Verhalten. Wird man evtl. bei den Mobile-Chips so sehen.

Wenn beide kein High NA verwenden wo ist dann der Vorteil für TSMC?
Dann besteht natürlich kein Vorteil.

[Tarkin]

Was Intel öffentlich macht ist seit Jahren BS, das ist das Problem.

Jup, Investoren wird Sand in die Augen gestreut mit idiotischen Fab-Erweiterungsplänen und "5 nodes und 4 Years" Bullshit und Kunden/Partner werden schlicht belogen mit Fantasie-Roadmaps die man nicht einhält und Aussagen wie:

"The performance of Granite [Rapids], relative to what customers need, and what the competitors will have, is going to be fantastic,” Zinsner said."

"All things considered, “the reception has been quite good on Sapphire Rapids… in certain workloads that actually performs extremely well,” Zinsner said."

Das ist einfach nur lächerlich. Jeder mit bissl Hirn weiß, dass Intel mit GR und SF keine Chance gegen Genoa haben wird - von Turin ganz zu schweigen.

Und gleichzeitig zockt man sich noch MILLIARDEN an Steuergeldern rein - ja, Politiker lassen sich super vor den Karren spannen. Das nutzt man jetzt noch mal so richtig aus, nimmt was man kriegen kann auf Kosten der Gesellschaft. Was Intel da treibt ist einfach nur zum Kotzen.

Das fast den aktuellen Stand der Dinge eigentlich sehr gut zusammen:

https://forums.anandtech.com/threads/speculation-zen-4-epyc-4-genoa-ryzen-7000-etc.2571425/page-506#post-41041823

[latiose88]

Unterscheiden kann man es nicht aber die Performance könnte sich anders verhalten.
Eine sehr speicherlastige Anwendung wird z.B. eher schlechter mit der Kernanzahl skalieren aber SMT wird sich sehr ähnlich wie 2 echte Kerne verhalten, da im Kern selbst ja fast alles dahin idlet.
Eine sehr rechenintensive Anwendung wird vermutlich zwar vielleicht sehr gut mit der Kernanzahl skalieren aber SMT wird hier gegenüber 2 echten Kernen weiter zurück liegen, da die Ressourcen im Kern eben stärker belegt sind.

Aber damals um 2003 herum war das beides nicht der Fall. Da war das Hauptproblem, dass so gut wie alle Anwendungen rein ST waren und da bringen dann weder SMT nocht mehr Kerne etwas. Diese Anwendungen muss man bei solchen Diskussionen immer ausklammern.



Also interessante Kenntnis. Ich habe genau so ein Programm. Ab gewisser Anzahl an kernen sklaliert smt nicht mehr mit. So richtig 0. Gillt das was für Zen 2 threadripper gallt auch für Zen 3 threadripper? Weil ich habe nur Zen 2 24 und 32 Kerner und Zen 3 threripper 24 Kerne. Ne feste auf kerne festgelegtes brachte auf Zen 2 noch was. Es holte alles raus und konnte dann die selbe Leistung abliefern mit seinen 24 Kerner wie ein 32 Kerner. Habe nur scheinbar bei mir nur das Problem. Zen 3 threripper fand ich keinen mit 32 kernen nur einen mit 24 kernen. Taktbereinigt je nach dem wenn man es festen kernen zu ordnen und das maximum raus holt, dann ist der sprung nicht sehr hoch. Heißt das es ist genau das wo du geschildert hattest.
Der 24 Kerner wird zu 100 % zu bei 32 Kerner mit 75 % ausgelastet es genau so Schildern. Lohnt sich dann mit dieser Erkenntnis noch den Zen 3 32 Kerner zu testen oder wird sich zu Zen 2 nichts dran ändern am Verhalten der Software?

Bei Zen 4 brachte der CPU takt sehr viel. Bandbreiten limitiert ist meine Anwendung ebenso nicht. Auch ddr5 RAM ebenso getestet mit ddr5 4800 vs ddr5 6200 MHz. Auch Festplatte wurde von mir ausprobiert und sogar die l1 zu l2 cache von der CPU wurde getestet. Engpass gab es auch da nicht. Gibt es sonst noch was um herauszufinden was noch so limitiert außer die CPU oder habe ich alles durch?

Das Problem ist auch wenn nix limitiert kann die CPU dennoch nicht schneller berechnen. Ich schaffe es also leider nicht noch mehr aus dem ganzen heraus zu holen. Oder kann man noch was machen. Oder liegt es ganz auf die CPU, so das man villeicht da noch was holen kann. Ich könnte mir vorstellen es noch mit mehr cpu takt kurz auszuprobieren. Wunder erwarte ich jedoch nicht.

PS :Bei Intel verhält sich die Software genauso wie bei AMD. Ich kann machen was ich will, da geht wohl nicht mehr so viel. Mal sehen wie die Nachfolger Intel CPU so sein wird. Wenn da noch mehr cpu takt geht, dann rennt Intels CPU noch weiter davon. Bei 6 - 6,2 GHz geht meine Software so richtig ab gegenüber nur 5,7 GHz und so.

[HOT]

Nach Oracle hat jetzt offenbar auch Meta Intel vor die Tür gesetzt. Ich sag ja, das Marketing muss irgendwas tun, dann kommen eben die nächsten wirren Ankündigungen mit durchschaubar zu knappen Releaseterminen...


Jup, Investoren wird Sand in die Augen gestreut mit idiotischen Fab-Erweiterungsplänen und "5 nodes und 4 Years" Bullshit und Kunden/Partner werden schlicht belogen mit Fantasie-Roadmaps die man nicht einhält und Aussagen wie:

"The performance of Granite [Rapids], relative to what customers need, and what the competitors will have, is going to be fantastic,” Zinsner said."

"All things considered, “the reception has been quite good on Sapphire Rapids… in certain workloads that actually performs extremely well,” Zinsner said."

Das ist einfach nur lächerlich. Jeder mit bissl Hirn weiß, dass Intel mit GR und SF keine Chance gegen Genoa haben wird - von Turin ganz zu schweigen.

Und gleichzeitig zockt man sich noch MILLIARDEN an Steuergeldern rein - ja, Politiker lassen sich super vor den Karren spannen. Das nutzt man jetzt noch mal so richtig aus, nimmt was man kriegen kann auf Kosten der Gesellschaft. Was Intel da treibt ist einfach nur zum Kotzen.

Das fast den aktuellen Stand der Dinge eigentlich sehr gut zusammen:

https://forums.anandtech.com/threads/speculation-zen-4-epyc-4-genoa-ryzen-7000-etc.2571425/page-506#post-41041823

Oh, das ist ein guter Punkt. Steuergelder aquirieren ist ein sehr guter Grund Roadmaps zu frisieren.

[...]

Daran habe ich auch immer gezweifelt und ehrlich gesagt hat mich das sehr an die letzten Atemzüge von GF leading Nodes erinnert.
Aber anscheinend sehen das die meisten Spezialisten aus der Branche anders und sehen 18A sehr positiv.[...]

Nicht falsch verstehen, ich sehe 18A auch sehr positiv, das wird ein toller Prozess. Mich stören nur die unrealistischen Zeiträume, die Intel, oder besser deren Marketing, uns da ständig verkaufen will. Und das 20A ne Luftnummer wird war mir schon an dem Tag klar, als ich das zuerst auf ner Roadmap las. Intel3, evtl. mit PowerVIAs, wird der nächster großer Wurf, danach 18A, aber eben frühestens 26.

[aceCrasher]

Jupp, abgesehen von cloud native macht es keinen Sinn SMT zu entfernen.
Naive Gegenfrage - wenn es keinen Sinn ergibt, wieso haben Apples Big-Kerne dann kein SMT? Das sind ja auch keine cloud native Kerne, sondern breite Kerne in consumer Geräten.

Meine Meinung: Wenn das entfernen von SMT auch nur 5% ST-Leistung auf den P-Cores bringt, ist das für mich bereits sinnvoll im Desktop Segment. MT-Leistung satt ist dank der E-Kerne eh vorhanden. Was interessiert mich ob meine P-Cores SMT haben, wenn ich sowieso 16-24 E-Cores habe? SMT zu entfernen würde außerdem die Hitzedichte in den P-Kernen reduzieren, wodurch sich nachweislich der Takt erhöhen lässt (https://www.youtube.com/watch?v=DV07huhbbQE).

[KarlKastor]

Das ist einfach nur lächerlich. Jeder mit bissl Hirn weiß, dass Intel mit GR und SF keine Chance gegen Genoa haben wird - von Turin ganz zu schweigen.

Ich denke ich habe ein wenig Hirn. Aber, dass GR keine Chance haben soll gegen Genoa ist mir bei der momentanen Faktenlage eher nicht so klar.
Das größte Problem ist, dass GR noch weit weg ist.

[HOT]

Ich glaube dass LC offenbar kein SMT haben soll ist recht einfach erklärt. Intel nutzt offenbar für die 2. Cove-Generation die e-Cores als Basisarchitektur und hat daraus einen großen Kern gemacht. Die alten .cove würden damit nach Redwood Cove fallen gelassen werden und dürften als ziemlich unrühmliche Serie in die Geschichte eingehen.
Intel wird sich schon seit dem M1-Launch an Apple orientiert haben und seine Pläne für die P-Kerne schon sehr früh verändert haben, sieht man ja auch an ADL. Das Ergebnis ist mMn Lion Cove, welcher die erste Auskopplung dieser neuen P-Kerne auf e-Kern-Basis sein dürfte. SMT stand vielleicht für eine Entwicklungsstufe im Lastenheft (oder auch nicht), aber wird es schlichtweg nicht mehr in das Design geschafft haben. Irgendwann muss man halt nen Punkt machen und das Design fertigstellen. Das würde auch die Taktregression erklären übrigens. Spätere Designs dürften hier aber vom Takt her wieder potenter werden (Cougar Cove).

Ich denke ich habe ein wenig Hirn. Aber, dass GR keine Chance haben soll gegen Genoa ist mir bei der momentanen Faktenlage eher nicht so klar.
Das größte Problem ist, dass GR noch weit weg ist.
Jo halte ich auch für Quatsch die Aussage, aber gegen Turin, vor allem Turin Dense, wirds mit GR mMn auch nicht reichen.

Es bleibt trotzdem Panther Lake. Übrigens ist das schon länger bekannt, was MLID sagt ist nichts Neues.


Panther used Cougar instead of Panther.
https://twitter.com/OneRaichu/status/1590761980838936576?t=jEYfyAgBcMlHxzserJeaQQ&s=19



Panther Cove sollte urspünglich mit Nova Lake kommen. Es macht also noch weniger Sinn Nova Lake nach Arrow Lake anzusetzen. Von Nova Lake selber ist nichts mehr zu lesen, dafür von Panther Lake umso mehr, zum Beispiel auch hier (https://il.linkedin.com/in/arnold-cheskis) oder hier (https://www.tomshardware.com/news/panther-lake-50-percent-more-efficent-vs-alder-lake).

Increased performance on Alder, Lunar, and Panther Lake projects

Für mich hat dieses Namenschaos noch nie Sinn ergeben. Ich glaub, da haben Leaker etliches Durcheinandergeworfen. MMn war der Plan Anfangs eher:

Arrow-Lake -> Lion Cove + CE-GFX -> 20A
(Arrow-Lake-S -> Lion Cove + CE GFX -> N3 als Backup)
(Lunar Lake -> Panther Cove + DR GFX -> 20A)
Panther-Lake -> Panther Cove + DR GFX -> 20A
Nova Lake -> Cougar Cove + DR GFX -> 18A

MMn hats einfach Panther Lake zerblasen.

[mksn7]

Wird denn der Alternativzweig wirklich weiter verfolgt? Ein paar Daten aus dem L1 vorladen macht ja eventuell noch Sinn aber Berechnungen kann ich mir nicht wirklich vorstellen. Dachte das wäre seit dem Netburst Ende vorbei.

Der Alternativzweig wird überhaupt nicht verfolgt. Ich glaube mich zu erinnern, dass es mal Überlegungen/Gerüchte/Spekulationen gab sowas zu machen, auch im Zusammenhang mit Bulldozer. Ich weiß aber nicht mehr wie sich das nannte und habe deswegen auch nichts mehr dazu gefunden. Der Gedanke lag damals nahe, jede Menge execution units die schwer auszulasten sind. Warum also nicht die branch misprediction penalty reduzieren indem auch auf dem anderen Pfad weiter gerechnet wird?

Aus heutiger Sicht ist das spekulative Ausführen von Instruktionen, die mit einer höheren Wahrscheinlichkeit verworfen werden, einfach eine Energieverschwendung, vor allem da branch prediction immer besser wurde. Eigentlich lohnt sich das nur wenn branches fast gar nicht vorhersehbar sind.



Unterscheiden kann man es nicht aber die Performance könnte sich anders verhalten.
Eine sehr speicherlastige Anwendung wird z.B. eher schlechter mit der Kernanzahl skalieren aber SMT wird sich sehr ähnlich wie 2 echte Kerne verhalten, da im Kern selbst ja fast alles dahin idlet.


Eine speicherbandbreitenlastige Anwendung wird nicht skalieren, die können die physischen Kerne ja schon saturieren. Bei speicherlatenzgebundenen Anwendungen hilft SMT aber richtig gut. Bei reinem pointer chasing ist ein glatter Faktor 2x nicht unrealistisch.

[w0mbat]

Naive Gegenfrage - wenn es keinen Sinn ergibt, wieso haben Apples Big-Kerne dann kein SMT? Das sind ja auch keine cloud native Kerne, sondern breite Kerne in consumer Geräten.

Meine Meinung: Wenn das entfernen von SMT auch nur 5% ST-Leistung auf den P-Cores bringt, ist das für mich bereits sinnvoll im Desktop Segment. MT-Leistung satt ist dank der E-Kerne eh vorhanden. Was interessiert mich ob meine P-Cores SMT haben, wenn ich sowieso 16-24 E-Cores habe? SMT zu entfernen würde außerdem die Hitzedichte in den P-Kernen reduzieren, wodurch sich nachweislich der Takt erhöhen lässt (https://www.youtube.com/watch?v=DV07huhbbQE).
Du hast nicht ganz Unrecht. Für Intels big.LITTLE Architektur, vor allem wenn man 16+ E-Cores hat, ist SMT auf den P-Cores nicht mehr so wichtig für die MT-Performance.

Gleichzeitig sind Intels P-Cores eh viel zu groß, jede Verschlakungskur wäre willkommen.

[Gipsel]

Naive Gegenfrage - wenn es keinen Sinn ergibt, wieso haben Apples Big-Kerne dann kein SMT? Das sind ja auch keine cloud native Kerne, sondern breite Kerne in consumer Geräten.Frag' Apple! Ein paar Varianten wurden schon genannt. Schutz vor potentiellen Sicherheitsproblemen mit SMT stand glaube ich recht weit oben auf der Liste.
Meine Meinung: Wenn das entfernen von SMT auch nur 5% ST-Leistung auf den P-Cores bringt, [..]Das tut es aber nicht.
SMT zu entfernen würde außerdem die Hitzedichte in den P-Kernen reduzieren, wodurch sich nachweislich der Takt erhöhen lässt (https://www.youtube.com/watch?v=DV07huhbbQE).Und die Performance dann bei erhöhtem Takt dann trotzdem niedriger ausfällt. Ein Kern mit SMT tut natürlich in MT-Szenarien mehr als einer ohne.
Umgekehrt kann man in MT-Szenarien auch den Takt des Kerns mit SMT etwas senken um Strom zu sparen (bei gleichbleibendem Durchsatz).
Bei gleichem Durchsatz verbraucht der Kern mit SMT weniger, alternativ hat er mehr Durchsatz bei gleichem Verbrauch (wenn nicht irgendwer was beim Design verbockt hat). Wie man es dreht und wendet, in MT-Szenarien bringt SMT höhere Performance, höhere Performance/Watt und höhere Performance/Fläche im Vergleich zum gleichen Kern ohne SMT.

[amdfanuwe]

Das größte Problem ist, dass GR noch weit weg ist.
Eben. Die Genoa Plattform ist mittlerweile Verifiziert. Dauert ja immer >0,5 Jahre vom Erscheinen des Prozessors bis sich die Firmen für den Großeinsatz entscheiden.
Bei Bergamo und Genoa-X sieht das anders aus. Die sind Plattform und ISA kompatibel. Die kann man ohne weitere großartige Verifikation direkt einsetzen und verwenden.
Bei Turin könnte ich mir ähnliches vorstellen.
Zudem kann AMD wegen Chiplet ohne weiteres auch CPUs mit speziellen Beschleunigern auf die gleiche Plattform bringen.
MI300C mit 96 Core und 128/192 GB HBM geistert ja auch schon rum.
Zudem steht dieses Jahr noch die günstigere Siena Plattform an.

Für die neuen Intel CPUs muss erst mal die Plattform Verifiziert werden.
D.h.: Nach Ausliefern der ersten GR Muster dauert es noch mal mindestens 6 Monate bis die zum Einsatz kommen könnten.
Wer weiß, was AMD bis dahin wieder bringt.

[latiose88]

Mit anderen Worten Intel ist zu langsam und braucht einfach zu lange bis die mal was brauchbares liefern. Da ist Intel halt zu träge und darum wird es für Intel sehr schwer werden mit AMD auf Augenhöhe in sachen Leistung und des gesammt packetes zu liefern. AMD ist da halt so weit angepasst und sie verwenden kleine cpus. Bei Kosten kann Intel ebenso nicht mit halten.
Aber was noch nicht ist, kann ja in Zukunft was werden. AMD braucht nur mal in sachen Entwicklung ne Verzögerung zu haben und schon kann Intel mal wieder aufholen.

Klar ist wenn man mehr auf die CPU gibt, kann diese auch mehr liefern. Nur eben der Preis ist mit dem höheren Stromverbauch auch sehr hoch.

Wenn dann schreibe ich immer von vollast auf die CPU. Beim zocken liegt ja meist nur ne teillast an.
Da kann Intel sich besser behaupten aber zocken alleine ist halt nicht das Augenmerk bei ner CPU. Ich sehe immer das gesamte an.
In meinem Fall brauchte ne Intel CPU ne sehr hohe CPU takt aber auch mehr als alles andere auf der Welt an höheren Stromverbauch. Man sollte wohl doch besser nicht zu stark ne CPU auslasten wenn man keinen so hohen Stromverbauch haben will.
So ist die von AMD auch nicht zu 100 % die CPU ausgelastet. Zum Glück kann man dazu nur sagen, sonst sehe diese auch sehr viel höher aus.

[davidzo]

Zudem kann AMD wegen Chiplet ohne weiteres auch CPUs mit speziellen Beschleunigern auf die gleiche Plattform bringen.
MI300C mit 96 Core und 128/192 GB HBM geistert ja auch schon rum.

Ist das so?
Der Sockel sieht zwar sehr ähnlich aus, aber bisher klang das nicht so als wenn neben dem onboard HBM auch noch DDR5 unterstützt wird. Wenn Mi-300 tatsächlich in die gleichen boards geht und vergleichbares i/o bietet, dann wäre dass in der Tat ein Trumpf für AMD und würde ai/GPU Beschleunigung sehr gut zugänglich für den Massenmarkt machen. Bisher würde ich aber davon ausgehen dass Mi-300 mit SH-5 einen eigenen, inkompatiblen Sockel hat, nur HBM on package und keinen 12ch DDR5, sowie womöglich weniger PCIelanes.

[amdfanuwe]

Ist das so?
Der Sockel sieht zwar sehr ähnlich aus, aber bisher klang das nicht so als wenn neben dem onboard HBM auch noch DDR5 unterstützt wird.
Wo wäre das Problem entsprechende I/O zu erstellen und das Pin-Layout SP5 kompatibel zu machen?
Es geht mehr darum, dass AMD durch das Stacking den entsprechenden Platz hat im gleichem Format auch HBM unterzubringen.

[basix]

Naive Gegenfrage - wenn es keinen Sinn ergibt, wieso haben Apples Big-Kerne dann kein SMT? Das sind ja auch keine cloud native Kerne, sondern breite Kerne in consumer Geräten.

Frag' Apple! Ein paar Varianten wurden schon genannt. Schutz vor potentiellen Sicherheitsproblemen mit SMT stand glaube ich recht weit oben auf der Liste.

Zusätzlicher Punkt:
Bei Smartphone SoCs ist maximale MT-Leistung jetzt nicht ein Killer-Feature. Solange die Kerne primär für das entwickelt werden, ist die SMT Komplexität den Aufwand wohl nicht wert. Bei den Apple Mx CPUs sieht das etwas anders aus. Dort würde sich das schon lohnen. Warten wir mal ab, was der M3 bringt.

[basix]

Bisher würde ich aber davon ausgehen dass Mi-300 mit SH-5 einen eigenen, inkompatiblen Sockel hat, nur HBM on package und keinen 12ch DDR5, sowie womöglich weniger PCIelanes.

CXL-3 und damit Distributed Memory scheinen von MI300 unterstützt zu werden. Ist jetzt die frage, ob 250ns anstatt 100ns ein Problem sind.

[davidzo]

Wo wäre das Problem entsprechende I/O zu erstellen und das Pin-Layout SP5 kompatibel zu machen?
Es geht mehr darum, dass AMD durch das Stacking den entsprechenden Platz hat im gleichem Format auch HBM unterzubringen.

Du glaubst also dass im i/o DIE von mi300 noch ein 12ch DDR5 IMC steckt?

Wieso meinst du dann heißt der Mi-300 Sockel SH5 und nicht SP5 wie bei genoa, Genoa-X und Bergamo?


CXL-3 und damit Distributed Memory scheinen von MI300 unterstützt zu werden. Ist jetzt die frage, ob 250ns anstatt 100ns ein Problem sind.
Das war nicht die Frage. CXL und ein DDR5 IMC sind zwei verschiedene Dinge. Es ging darum ob Mi-300 dieselben mainboards benutzen kann wie Genoa und damit zahlreiche kompatile Plattformen vom Start an verfügbar sind AMD sich ein großteil der validierung sparen kann.
Genoa hat nicht nur CXL sondern auch selber einen IMC mit 12C DDR5 für den ein Großteil der 6096 Pins von SP5 reserviert sind. Was glaubst du, wird Mi-300 diese Pins auch haben, werden sie einfach nicht belegt sein oder ist das Pinout einfach komplett ein anderes und man nutzt diese Pins für power delivery etc.?


Sry aber langsam sind wir hier im Intel Fred ziemlich OT.
Ich wollte nur der Hypothese von amdfanuwe widersprechen dass Mi-300C deswegen schneller als sierra forest kommt, weil es sich um dieselbe Plattform wie Genoa, Genoa-X und Bergamo handelt. Das ist nach aktuellem Stand mitnichten der Fall. Der Sockel sieht zwar physisch ähnlich aus, also vom ILM und dem pincount, aber da enden dann schon alle Gemeinsamkeiten.

[amdfanuwe]

Du glaubst also dass im i/o DIE von mi300 noch ein 12ch DDR5 IMC steckt?

Wo steht das?
Lese mal genau, was ich schrieb.
MI300A bzw. MI300X haben anderen Sockel.
Und nochmals: was hindert AMD daran die MI300 Technik für eine Genoa kompatible CPU mit HBM zu verwenden?
Entsprechend neues I/O mit IF$ und 12ch DDR5 etc. sollte kein Problem für AMD sein.

[basix]

Das war nicht die Frage. CXL und ein DDR5 IMC sind zwei verschiedene Dinge. Es ging darum ob Mi-300 dieselben mainboards benutzen kann wie Genoa und damit zahlreiche kompatile Plattformen vom Start an verfügbar sind AMD sich ein großteil der validierung sparen kann.

Ich hoffe MI300 kann es. Wäre eine grosse ungenutzte Chance.

Ein neues Package mit wie du sagst weniger Power Delivery und dafür DDR5 Pins wäre denkbar. 400W wären eh das limit, damit man SP5 kompatibel wird.

Und ja, ist OT hier.

[iamthebear]

Also interessante Kenntnis. Ich habe genau so ein Programm. Ab gewisser Anzahl an kernen sklaliert smt nicht mehr mit. So richtig 0.

Welche Kombinationen hast du denn da genau getestet? Für mich hört sich das eher nach eine Limitierung der Threadanzahl an sich an d.h. 24 zusätzliche echte Kerne würden auch nicht mehr viel bringen.
Woran es da bei den alten Threadrippern genau scheitert weiß ich auch nicht aber ab einer gewissen Anzahl an Threads scheinen die sich bei gewissen Anwendungen zu verschlucken bzw. skalieren relativ schlecht mit der Kernanzahl.

Oh, das ist ein guter Punkt. Steuergelder aquirieren ist ein sehr guter Grund Roadmaps zu frisieren.

Roadmap hin oder her. Der Grund warum Intel gefördert wird ist weil das der einzige Auftragsfertiger ist, der bereit ist eine Leading Edge Fab in USA/Europa aufzustellen.
Sowohl Taiwan als auch Korea ist zu nahe an China und kann im Ernstfall kaum verteidigt werden.

Nicht falsch verstehen, ich sehe 18A auch sehr positiv, das wird ein toller Prozess. Mich stören nur die unrealistischen Zeiträume, die Intel, oder besser deren Marketing, uns da ständig verkaufen will. Und das 20A ne Luftnummer wird war mir schon an dem Tag klar, als ich das zuerst auf ner Roadmap las. Intel3, evtl. mit PowerVIAs, wird der nächster großer Wurf, danach 18A, aber eben frühestens 26.

Dass 20A als erster Node dieser Generation gleich sofort super Taktraten im Desktop schaffen wird daran habe ich auch meine Zweifel.
Aber 18A Testwafer gibt es schon seit 2022. Da sollte der Node selbst doch hoffentlich 2025 zumindest für irgendetwas brauchbar sein wenn auch nicht für den High End Desktop Node.
Selbst bei der Vollkatastrophe 10nm waren es nur ca. 2 Jahre von den ersten Testwafern 2017 bis Ice Lake 2019 in Server/Notebook kam.

Meine Meinung: Wenn das entfernen von SMT auch nur 5% ST-Leistung auf den P-Cores bringt, ist das für mich bereits sinnvoll im Desktop Segment.

Ein Design ohne SMT Support wird nicht mehr ST Performance haben. Es wird wird lediglich der Kern kleiner d.h. man ist in der Lage mehr Kerne zu verbauen, was aber wieder nur bei MT Anwendungen etwas bringt.

SMT zu entfernen würde außerdem die Hitzedichte in den P-Kernen reduzieren, wodurch sich nachweislich der Takt erhöhen lässt (https://www.youtube.com/watch?v=DV07huhbbQE).

Das Problem hier war einfach die insgesamt zu hohe Energiemenge, nicht die lokale Hitzedichte.

Mag sein, dass durch das Deaktivieren von SMT bei manchen MT Applikationen 5% mehr Takt drin ist. Aber dafür verliert man 20-30% an Performance weil man weniger Threads hat.

Und bei allen ST Anwendungen, Spielen usw. so SMT nichts bringt wird man auch nicht mehr Takt erreichen weil dort sowieso am Kern kein 2. Thread läuft.

Insgesamt ist SMT aber immer noch der energiesparenste Weg die Performance zu steigern, noch mehr als die Verwendung von E Cores. Geldmann3 hat hier ein paar interessante Benchmarks gemacht:
https://i.ibb.co/pzDQG2f/12900-K-Performance-Watt.png

Ich glaube dass LC offenbar kein SMT haben soll ist recht einfach erklärt. Intel nutzt offenbar für die 2. Cove-Generation die e-Cores als Basisarchitektur und hat daraus einen großen Kern gemacht. Die alten .cove würden damit nach Redwood Cove fallen gelassen werden und dürften als ziemlich unrühmliche Serie in die Geschichte eingehen.

Das macht keinen Sinn. Raptor Cove ist an sich eine gute Architektur und hängt Zen3 sehr deutlich ab. Gegen Zen 4 ist man halt einen Node hinten nach.

Big/Little als Konzept ist auch eine gute Idee aber Gracemont an sich ist einfach Schrott.

Ich halte es für deutlich sinnvoller Gracemont einzustampfen und für die E Cores ähnlich wie AMD mit Zen4c die Big Cores abzuspecken und diese bei weniger Takt zu betreiben.

Eine speicherbandbreitenlastige Anwendung wird nicht skalieren, die können die physischen Kerne ja schon saturieren. Bei speicherlatenzgebundenen Anwendungen hilft SMT aber richtig gut. Bei reinem pointer chasing ist ein glatter Faktor 2x nicht unrealistisch.

Die Frage ist wie viele stark speicherlatenzlastige Anwendungen es in der Praxis gibt, alle Kerne (inkl. SMT) nutzen aber trotzdem nicht bandbreitenlimitiert sind.

Was partiell bandbreitenlimitierte Anwendungen angeht (Beispiel WinRAR):
Ja in absoluten Zahlen bringt hier SMT weniger. Aber verglichen mit physischen Kernen steht man besser da.

Beispiel:
Bei rechenintensiven Anwendungen:
10 Kerne mit ohne SMT 100 Punkte
10 Kerne mit SMT 130 Punkte
13 Kerne mit SMT 130 Punkte

Bei bandbreitenintensigen Anwendungen:
10 Kerne ohne SMT 100 Punkte
10 Kerne mit SMT 120 Punkte
16 Kerne ohne SMT 120 Punkte

Frag' Apple! Ein paar Varianten wurden schon genannt. Schutz vor potentiellen Sicherheitsproblemen mit SMT stand glaube ich recht weit oben auf der Liste.

Und wen jucken diese Lücken auf einem Smartphone mit 1 Benutzer wo nur geprüfte Anwendungen aus dem eigenen Store laufen?

Zusätzlicher Punkt:
Bei Smartphone SoCs ist maximale MT-Leistung jetzt nicht ein Killer-Feature. Solange die Kerne primär für das entwickelt werden, ist die SMT Komplexität den Aufwand wohl nicht wert. Bei den Apple Mx CPUs sieht das etwas anders aus. Dort würde sich das schon lohnen. Warten wir mal ab, was der M3 bringt.

Man kann mit SMT aber z.B. nur 6 statt 8 Kerne verbauen bei gleicher ST und MT Performance und so Fläche sparen.

Oder man investiert die zusätzlichen Transistoren irgendwo anders und baut damut schnellere Kerne.

[dildo4u]

Die igor Benches waren angeblich der i7, der i9 soll deutlich später kommen.
8+16 vs 8+32


ZuriVO-s26k

[HOT]

Meine Güte, der kanns aber auch wirklich nicht verknuspern, dass Igor ihm da voll die Tour vermasselt hat.
Igor hat Projections, das sind natürlich keine finalen Daten. Und dann dieser Vergleich mit einem I7, das hört sich für mich nach komplettem BS an. Und das sind auch keine A0-Sample-Tests, sondern eben Produkt-Projektionen, das soll hinterher dabei rauskommen. Intel macht keine Projektion zwischen 2 unterschiedlichen Produktklassen :freak:, so ein Unsinn.
Der ist wirklich von Igor auf dem falschen Fuß erwischt worden ;D. Und diese Rechtfertigungsorgie am Anfang :D.
Noch dämlicher ist die SMT-Geschichte. Entweder er hat SMT oder nicht.

Dann bringt er ARL für Q4 24 und den 8+32 (den er mit SMT wissen will, was Unsinn ist, wofür dann 32 e-Cores?) Q2-3 25. Und dann noch nen Refresh, nein Tom das ist der Refresh ;).

Letztendlich dürfte ARL ungefähr in der Performanceregion von Zen5 rauskommen.

Was er über Intel sagt ist noch größerer Blödsinn. Als ob in der Company soviel Chaos herrschen würde... die wissen intern schon genau was sie bauen, vielleicht gibts mal hier und da ein Projekt, die nicht funzt, aber ich würde eher sagen, dass das eher dazu beitragen wird, dass Dinge auch mal zuende gebracht werden die funktionieren, und andere eben nicht. Da wird nicht mehr jeder Holzweg zuende gegangen.

[Mandalore]

Meine Güte, der kanns aber auch wirklich nicht verknuspern, dass Igor ihm da voll die Tour vermasselt hat.
Igor hat Projections, das sind natürlich keine finalen Daten. Und dann dieser Vergleich mit einem I7, das hört sich für mich nach komplettem BS an. Und das sind auch keine A0-Sample-Tests, sondern eben Produkt-Projektionen, das soll hinterher dabei rauskommen. Intel macht keine Projektion zwischen 2 unterschiedlichen Produktklassen :freak:, so ein Unsinn.
Der ist wirklich von Igor auf dem falschen Fuß erwischt worden ;D. Und diese Rechtfertigungsorgie am Anfang :D.
Noch dämlicher ist die SMT-Geschichte. Entweder er hat SMT oder nicht.

Dann bringt er ARL für Q4 24 und den 8+32 (den er mit SMT wissen will, was Unsinn ist, wofür dann 32 e-Cores?) Q2-3 25. Und dann noch nen Refresh, nein Tom das ist der Refresh ;).

Letztendlich dürfte ARL ungefähr in der Performanceregion von Zen5 rauskommen.

Was er über Intel sagt ist noch größerer Blödsinn. Als ob in der Company soviel Chaos herrschen würde... die wissen intern schon genau was sie bauen, vielleicht gibts mal hier und da ein Projekt, die nicht funzt, aber ich würde eher sagen, dass das eher dazu beitragen wird, dass Dinge auch mal zuende gebracht werden die funktionieren, und andere eben nicht. Da wird nicht mehr jeder Holzweg zuende gegangen.


Sollte die Projektion von Igor wirklicj stimmen, dann wird Arrow Lake deutlich unter Zen 5 liegen IPC mäßig…(zumindest mit den momentanen Daten zu Zen 5 und Arrow Lake aus der Gerüchteküche)

[HOT]

Glaub ich nicht. Guck dir die IPC von Raptor Lake an, die ist auch höher als die von Zen4. Wenn man zusätzlich noch von starken Verbesserungen bei Cache+IO ausgeht, dürfte ARL sehr gut abschneiden letztendlich.

Die neuen Kerne sind glaub ich ein echter Knaller, wie sich das anhört.
SMT scheint auch komplett gegessen zu sein, stattdessen gibts "rentable Units". Allein das wär schon ein gewaltiger Fortschritt, kommt aber im Desktop wohl erst mit Cougar Cove.

[Tarkin]

Sollte die Projektion von Igor wirklicj stimmen, dann wird Arrow Lake deutlich unter Zen 5 liegen IPC mäßig…(zumindest mit den momentanen Daten zu Zen 5 und Arrow Lake aus der Gerüchteküche)

Jup, sehe ich auch so. Eigentlich benötigt AMD Zen 5 gar nicht wirklich. Alles was man gegen ARL bringen müsste um vorne zu bleiben ist, ein zen 4 + zen 4c auf Desktop. Man würde mit 8+16 alles in MT schlagen ... wahrscheinlich sogar auch den ARL Refresh LOL

Dass ARL vl 10% mehr ST Performance erzielt als Raptor Lake ist eigentlich komplett egal. Paar MHz könnte man mit einem neuen Stepping vl. noch rausquetschen bei Zen 4 ;)

Mich würde es ja wirklich nicht wundern, wenn Intel die Pläne nochmal komplett über den Haufen wirft und Ende 2024 doch nochmal einen weiteren Raptor Refresh bringt. Die Kosten für den ARL Ramp sind sicher nicht zu unterschätzen - das Design ist mega-komplex! Und wenn diese Projections richtig sind, dann sind die Erbsenzähler intern sicher schon am rechnen.... Ist ARL wirtschaftlich sinnvoll? Könnte man nicht mit einem billigeren Refresh vl. auch auf 95% dieser Projections kommen?

[HOT]

Ihr unterschätzt die CPU wirklich. Ich habe nur davor gewarnt diese hohen Erwartungen an ARL-S anzulegen (30% mehr als Zen5 blablabla). Aber jetzt ins Gegenteil abzudriften ist auch nicht zielführend.
Diese Projektionen sind natürlich eher das untere Ende, was erreicht werden muß. Wenn Intel es schafft den Takt weiter zu steigern, als jetzt geplant, wird das Ding u.U. viel schneller als die Projektion.
Ich würde echt davon ausgehen, dass die Battle weitergeht und keiner den Kürzeren zieht.

[Tarkin]

Glaub ich nicht. Guck dir die IPC von Raptor Lake an, die ist auch höher als die von Zen4. Wenn man zusätzlich noch von starken Verbesserungen bei Cache+IO ausgeht, dürfte ARL sehr gut abschneiden letztendlich.

Die neuen Kerne sind glaub ich ein echter Knaller, wie sich das anhört.
SMT scheint auch komplett gegessen zu sein, stattdessen gibts "rentable Units". Allein das wär schon ein gewaltiger Fortschritt, kommt aber im Desktop wohl erst mit Cougar Cove.

Ich glaube Igor mehr als diesem MLID Deppen, sorry. Der erzählt viel BS wenn der Tag lang ist.

(Zen 4 und Raptor IPC ist quasi identisch siehe https://twitter.com/OneRaichu/status/1569904688933531649/photo/1)

[HOT]

Ich glaube Igor mehr als diesem MLID Deppen, sorry. Der erzählt viel BS wenn der Tag lang ist.

(Zen 4 und Raptor IPC ist quasi identisch siehe https://twitter.com/OneRaichu/status/1569904688933531649/photo/1)
Dass er auch ein Depp sein kann, hat er mit dem Video bewiesen ;). Aber ich würd das dennoch nicht verteufeln, die anderen Leaks in dem Video sind schon sehr interessant.
Man muss halt wissen, wie man das einordnen muss.

[Badesalz]

Schätze mal 14900k bringt fast nix da die E-Core bei 16 bleiben?
Ich hab wohl gepennt :usad: Ab wann fing man an die Leistung in Corecount zu messen?

[dildo4u]

Ich hab wohl gepennt :usad: Ab wann fing man an die Leistung in Corecount zu messen?
Der 14900k ist nur ein Refrech von dem was schon verfügbar ist also IPC und Takt ändern sich nur minimal.
Ein Modell mit mehr E-Cores hätte zumindest mehr Multi Thread Leistung.

[HOT]

14900K = 13900KS mit etwas mehr MT-Leistung, weil die Stromversorgung ja etwas flexibler ist.
Schade, dass sich der 14600k mit 8 p-Kernen nicht bewahrheitet hat sondern "nur" 6+8 ist.

[ryan]

Meine Güte, der kanns aber auch wirklich nicht verknuspern, dass Igor ihm da voll die Tour vermasselt hat.
Igor hat Projections, das sind natürlich keine finalen Daten. Und dann dieser Vergleich mit einem I7, das hört sich für mich nach komplettem BS an. Und das sind auch keine A0-Sample-Tests, sondern eben Produkt-Projektionen, das soll hinterher dabei rauskommen. Intel macht keine Projektion zwischen 2 unterschiedlichen Produktklassen :freak:, so ein Unsinn.



Das ist aber auch Spekulation von deiner Seite. Wir kennen die Hintergründe nicht zu den Projektionen, die können durchaus aus dem Kontext gerissen sein. Ob das Projektionen für das finale Produkt mit finalen Taktfrequenzen darstellen sollen oder Projektionen vom aktuellen Stand, wissen wir wirklich nicht. Ich würde stark zu deiner Theorie tendieren, wenn ARL-S nicht fast 1,5 Jahre vom Marktstart entfernt wäre.

Das mit dem i7 ist aber Quatsch bzw. nicht relevant, weil 8+16 die höchste Variante ist, mit der ARL-S an den Start geht. Also ist der Vergleich legitim. Ob Intel den als i7 oder i9 branded macht erstmal kein Unterschied.

ARL-S 8+32 wäre als refresh logisch. MLID meint ja jetzt, Panther Lake wäre womöglich cancelled für Desktop, das würde dann Sinn machen. Das würde für ein ARL-S refresh release sprechen als Übergangslösung für die nächste richtig neue Generation.



Sollte die Projektion von Igor wirklicj stimmen, dann wird Arrow Lake deutlich unter Zen 5 liegen IPC mäßig…(zumindest mit den momentanen Daten zu Zen 5 und Arrow Lake aus der Gerüchteküche)


Aus der Projektion kannst du die IPC nicht ablesen, es fehlen die Taktraten. Du müsstest annehmen, dass Intel die Taktraten von Raptor Lake erreichen kann, also 5,8 oder 6,0 Ghz. Das ist alles andere als selbstverständlich, sogar sehr unwahrscheinlich würde ich sagen. Historisch gesehen hat Intel bei einem Prozess shrink anfangs immer an Taktrate eingebüßt. Das war bei 22nm so, bei 14nm, bei 10nm und bei Intel 4 sieht es auch danach aus.

Die besseren MT Werte deuten eher auf deutliche IPC Verbesserungen hin, weil Arrow Lake ohne SMT auskommt. Bei den MT Benchmarks spielt allerdings Skymont noch mit rein.

[KarlKastor]

Naja MLID erzählt immer viel Unsinn wenn der Tag lang ist. Auch +40% MT Performance von MTL zu ARL @same Power bei gleicher Kernzahl klingt ziemlich übertrieben.
Aber Igors Zahlen klingen in der Tat sehr schlecht für zwei Nodesprünge und zwei Core Iterationen. Taktrate hin oder her.
Ich hoffe da kommt mehr bei rum.

[Edgecrusher86]

Ich gehe einfach mal davon aus, dass final dann grob ein Kopf-an-Kopf-Rennen zwischen Intel und AMD stattfinden dürfte bei ARL-S gegen Zen 5 und man im Mittel wohl 10-30% auf Raptor-S/R und Zen 4(X3D) drauf legen wird können - mehr vermutlich nur, wenn neue oder stark verbesserte Befehlssätze zum Einsatz kommen wie AVXxxx.

Bei Intel würde ich von 5,0-5,5 GHz maximal ausgehen mit dem TSMC N3B für Arrow Lake-S.

Ja, der Refresh dürfte dann ein Jahr später mit besagten 8C+32c kommen als eine Art KS, aber dieses Mal nicht nur mit ein wenig Mehrtakt und TGP.

AMD wird wohl MT zumeist komfortabel anführen, wenn man Q4/24 bzw Q1/25 mit 8C/8T+16c gegen 16C/32T antritt. Da kann Intel noch froh sein, dass AMD nicht schon auf zum Beispiel 24C/48T erhöhen wird.

Ich bin echt gespannt, ob die 8T der P-Cores im Groß der kommenden Titel ausreichend sein werden, denn 8C/16T Zen 2 ist ja die Leadplattform über die Konsolen und P + E Cores zum Spielen möglichst homogen zusammen werkeln zu lassen dürfte nicht so einfach sein. Bisher bringen diese ja quasi keine spürbare Mehrleistung.

Die E-Cores dürften wohl im Takt langsam Richtung 5,0 GHz kommen - vermutlich noch etwas darunter. Deren IPC sollte wohl bald auf Coffee Niveau sein.

[y33H@]

Coffee Lake war auch Skylake-basiert, die E-Cores in Arrow Lake (also Skymont) dürften eher Sunny Cove Niveau oder drüber sein.

[Edgecrusher86]

Ja, dann habe ich mich nicht genau genug ausgedrückt. Ich meinte Coffee Lake Leistung - also etwa 1/4 auf Skylake in Form des 6700K. IPC + Mehrtakt. Icelake-Level(+) denkst du, ja - mag hin kommen.

Um grob 18-40% IPC hatte man damals dort zugelegt (18% im Schnitt, also ca. 1/5 Plus).

Dann wären wir im Prinzip bei der Core Leistung des 9900K - wäre schon sauber.

Ein bis zwei Architekturen später sollte es wohl in etwa Golden Cove Leistung sein. :)

[KarlKastor]

Bisher bringen diese ja quasi keine spürbare Mehrleistung.

Das Problem ist ja nicht, dass die E-Cores untauglich für Spiele wären sondern, dass kaum Spiele mehr als 8 Kerne benötigen.
Beim Vergleich 6C vs 6C+8E liegt letzterer schon ab und an nicht unerheblich vorne. Aber den meisten Spielen reichen eben auch 6C, erst recht 8C. Wenn Spiele mehr Threads auslasten ist es sicher kein Problem anstatt HTT E-Kerne zu nutzen.

[Platos]

Es gibt schon Spiele, die mit 8 Kernen auch mehr FPS liefern (~10-20%), wie mit 6 (jeweils mit HT, ohne E-Kerne). Manche sogar mehr wie 10, aber bei 6 vs 8 gibts schon einige.

Wenn du also mit nem i5 halt durch die E-Kerne mit nem 8-Kerner gleichkommen könntest, ist das ein erheblicher Vorteil. Denn es wird dann sicherlich 2 Threads geben, die mit den E-Kernen zufrieden sind.

Ebenfalls muss man bedenken, dass die Spielebenches alle so durchgeführt wurden, dass nichts im Hintergrund läuft. Also nie den Browser offen im Hintergrund, noch sonst was.

Ein paar E-Kerne dafür sind also auch noch gut.

Also quasi 6+4 für's Gaming und weitere 4 für Hintergrund. Eine super CPU als i5. Oder eben 6+2 für's Gaming und 2 für Hintergrund.

Das hiesse, möglicherweise wäre ein i5 dann mehr oder weniger gleich gut, wie die Top-End Consumer-CPU im Gaming.

Wenn man das mal so sieht, ist dann eben alles über i5 gar nicht mehr notwendig für die meisten Gamer. Ergo kann man das so sehen, dass diese CPUs eher für Leute sind, die nebenher auch noch andere Dinge tun, die viel MT Leistung benötigt.

Das Mehr an Kernen ist schon gut, denn so braucht man nicht mehr ein i7 oder sowas, um die volle Gaming-Perfomance zu haben. Ergo wird es billiger und oben durch ist es eben nicht mehr nötig für Gamer, das sind also CPUs, die eig. gar nicht an Gamer gerichtet sind.

Mit dem i9 ist das ja z.B schon lange so. Der ist kein Vorteil als Gamer. Vlt. wird es ja bald das gleiche mit dem i7 (meistens ist es ja jetzt schon so, dass ein i5 gleich gut ist, wie ein i7, nur nicht immer).

Und selbst innerhalb der i5 Klasse gibt es ja Unterschiede. Wenn ich mit nem 14400 das gleiche Kriege, wie mit nem 13600k, ist das eben nicht unbrauchbar für Gamer. Und wenn mit Arrow Lake eben die E-Kerne gut werden, sind die auch im Gaming dann brauchbar.

Man muss das so sehen: Die Kernaufstockung ist oben nicht für Gamer, sondern gegen unten hin. Man braucht keine grössere CPU mehr, die sind nicht mehr für Gamer.

[iamthebear]

1.) Die große Frage ist wie das mit den Performance Projections gemeint war:
a) Es wurde die A0 Version (mit vermutlich deutlich niedrigeren Taktraten) getestet und daraus eine Vorhersage der Release Version erstellt => So hat es igor ausgelegt

b) Es wurde die A0 Version in einigen Benchmarks getestet (z.B. Geekbench) und daraus eine Vorhersage der A0 Version über die reale Performance gemacht nach dem Motto "bei GB ist ARL 10% schneller als RTL also wird das wohl bei echten Anwendungen auch so sein" => so behauptet es MLID

Ich würde aus dem Bauch heraus eher sagen, dass MLID Recht hat, denn igors Daten sind ja schon so schlecht, dass ARL wohl nie released werden wird.

Es könnte aber auch sein, dass wir von ARL noch nicht alles verstehen und dieser eventuell wo anders seine Stärken hat z.B. beim Energieverbrauch und das Ding eher in den 15W Geräten landet.

2.) Für den Fall, dass MLID Recht hat d.h.:
.) ARL vs. RTL +40% ST und MT
.) ARL P Cores kein SMT aber auch noch keine Rentable Units

SMT bringt bei RTL ca. 40% mehr MT Performance.
Das würde bedeuten, dass die ARL P Cores (ohne TDP Limitierung) ca. gleich schnell sind wie die RTL P Cores mit SMT.

Wenn aber ARL 8+16 in Summe trotzdem 40% mehr MT Performance haben soll, dass bedeutet dies, dass die E Cores deutlich mehr als 40% zulegen müssen.

Wenn ich das grob überschlage:
RTL E Cores: 100% (Basis)
RTL P Cores ohne SMT: 180%
RTL P Cores mit SMT: 250%
RTL 8+16 gesamt: 8*250%+16*100% = 36

ARL P Cores mit SMT: 250%
ARL 8+16: 8*250% + 16*x = 50,4

Dann müsste ein E Core bei 190% raus kommen also in etwa auf dem Niveau der RTL P Cores (ohne SMT).

Das würde bedeuten, dass sich Intel von dem bisherigen Konzept der Atom like E Cores komplett verabschiedet hat und einen Weg ähnlich wie AMD mit den Zen4c Cores beschreitet.

Was den Vergleich von ARL i7 vs. RTL i9 angeht:
Ab der Raptor Lake Refresh hat der i7 nun 12 statt 8 E Cores. Ich gehe einmal davon aus, dass das mit ARL so bleiben wird. Das würde dann bedeuten:
.) RTL: 8*250% + 16*100% = 36
.) RTL: 8*250% + 12*190% = 42,8 => 19% mehr

Die 40% MT Performance von ARL 6+8 vs. MTL 6+8 bei gleicher TDP können sich dadurch erklären, dass die TDP sehr niedrig gewählt wurde wo bei MTL nicht mehr sinnvoll betrieben werden kann. Da liegt immerhin ein Node dazwischen.

Natürlich 40% bei ST/MT wäres schon eine kräftige Ansage aber jetzt auch nicht so unglaubwürdig sondern eher das, was man von 2 Node Jumps nach aktueller Definition (entspricht 1 Node Jump nach klassischer Definition) erwartet.
Alder Lake vs. Comet Lake hat auch um die 40% ST drauf gelegt und noch ein Stück mehr MT Performance durch die E Cores bei gleicher TDP.
Zen3 vs. Zen+ war auch um die 40-50% und deutlich mehr MT durch mehr Kerne.

3.) Ich frage mich wie diese "Rentable Units" genau aussehen sollen. Das hört sich so an als würden manche Einheiten dynamisch den jeweiligen Cores zugeordnet werden und so das klassiche Denkmuster in 2-way bzw. 4-way SMT überflüssig machen.

[HOT]

Mit den Projektionen ist die simulierte finale Leistung des tatsächlichen Siliziums gemeint. Das Teams setzt sich Ziele, baut ne Architektur und simuliert dann, was dabei rumkommt und tadaa...
Wie gesagt, wenn man mehr Takt schafft als erwartet muss man die Projektion nach hinten hinaus nach oben skalieren. Das halte ich für wahrscheinlich, weil Intel darin gut ist.

[Gipsel]

SMT bringt bei RTL ca. 40% mehr MT Performance.
Das würde bedeuten, dass die ARL P Cores (ohne TDP Limitierung) ca. gleich schnell sind wie die RTL P Cores mit SMT.

Wenn aber ARL 8+16 in Summe trotzdem 40% mehr MT Performance haben soll, dass bedeutet dies, dass die E Cores deutlich mehr als 40% zulegen müssen.

Wenn ich das grob überschlage:
RTL E Cores: 100% (Basis)
RTL P Cores ohne SMT: 180%
RTL P Cores mit SMT: 250%
RTL 8+16 gesamt: 8*250%+16*100% = 36

ARL P Cores mit SMT: 250%
ARL 8+16: 8*250% + 16*x = 50,4

Dann müsste ein E Core bei 190% raus kommen also in etwa auf dem Niveau der RTL P Cores (ohne SMT).
Ich würde SMT bei Raptorlake im Schnitt etwas schwächer einschätzen (und damit die E-Cores im Moment etwas stärker). SMT bringt bei konservativerer Schätzung im Schnitt bei MT eher 15-20% (aus 180% ohne SMT werden also eher nur 210-220%).
Und man muß beachten, daß wenn intel die Kerne etwas stromsparender bekommt, die Leistungssteigerung bei MT-Lasten etwas höher ausfällt, weil man die Takte besser halten kann. Ein 13900k zieht ungedrosselt ja locker so 320W+, wenn man die also bei 250W Powerlimit betreibt und die Kerne etwas sparsamer werden, kommt etwas mehr hinten raus.

[dildo4u]

Kein Plan welche Generation aber AVX512 soll für P und E cores kommen.



https://wccftech.com/intel-avx10-isa-to-feature-avx-512-instructions-with-support-on-both-p-cores-e-cores/

[Zossel]

Kein Plan welche Generation aber AVX512 soll für P und E cores kommen.

Und natürlich kriegt es Intel mal wieder nicht gebacken nur einen bestimmten Stand einzuführen:

AVX10 ISA that seems to be coming in two versions, a pre-enablement (AVX10.1) and a post-enablement (AVX10.2).

[mocad_tom]

Dann haben wir AVX10.1 in Granite Rapids aber nicht in Sierra Forest

Und AVX10.2 in Diamond Rapids & Clearwater Forest und vllt auch schon Arrow Lake, spätestens aber in Lunar Lake.

[Gipsel]

Und AVX 10.1 gibt es einmal mit 512bit Support und einmal ohne, also quasi AVX10.1_256 und AVX10.1_512.

[Zossel]

Und AVX 10.1 gibt es einmal mit 512bit Support und einmal ohne, also quasi AVX10.1_256 und AVX10.1_512.

Intel scheint die Internet Explorer Strategie von MS in Hardware nachzuahmen.

[ryan]

Es gibt nicht den bestimmten Standard. AVX512 war ein komplettes Durcheinander mit zig unterschiedlichen feature flags. AVX10 wird zukünftig die Nachkommastelle bei neuen Erweiterungen hochzählen. Das wurde auf Developer Feedback hin gendert. Die wirklich neuen Features kommen in AVX10.2, wo dann auch die E-cores mit unterstützt werden.


The developer community has provided feedback that the current Intel AVX-512 enumeration method has become increasingly unwieldy over time. As new instructions were introduced, they were assigned a new CPUID feature flag that would need to be checked to determine processor support. As of future Intel Xeon processors with P-cores, codenamed Granite Rapids, there are expected to be more than 20 discrete Intel AVX-512 feature flags. To address this, Intel AVX10 introduces a new versioning approach to enumeration: a Vector ISA feature bit specifying Intel AVX10 support, an Intel AVX10 ISA Version Number, and three bits enumerating 128-, 256-, and 512 bit vector length support in the product.

The Intel AVX10 ISA Version Number will be inclusive and monotonically increasing. A developer can expect that Intel AVX10 Version N+1 will include all the features and capabilities included in Version N. With the stated goal of minimizing developer impact, a new version of the Intel AVX10 ISA can be expected to include a significant suite of new instructions and capabilities, delivering sufficient additional value to justify the associated software enablement effort. In rare cases, a discrete CPUID feature flag may be allocated for a segment-specific feature or in the case of an interim launch in between new Intel AVX10 versions.

[Gipsel]

Es gibt nicht den bestimmten Standard. AVX512 war ein komplettes Durcheinander mit zig unterschiedlichen feature flags. AVX10 wird zukünftig die Nachkommastelle bei neuen Erweiterungen hochzählen. Das wurde auf Developer Feedback hin gendert. Die wirklich neuen Features kommen in AVX10.2, wo dann auch die E-cores mit unterstützt werden.
Im Prinzip gibt es ein Bit für "AVX10.2 base" Support (mit verpflichtend lediglich 128bit Operanden), und dann noch zusätzliche Flags für Unterstützung des gleichen Befehlssatzes mit 256bit bzw. 512bit Operanden.
Bei AVX10.2 ist also weiterhin zu diesem Zeitpunkt unklar, ob die E-Cores wirklich "AVX512 v2.0" (also 512bit Operanden) unterstützen. Denn auch bei AVX10.2 ist 512bit Unterstützung wie erwähnt lediglich optional (technisch sogar 256bit). Es ist also sehr gut möglich, daß die einzige Verbesserung sein wird, daß der Befehlssatz an sich vereinheitlicht wird. Das ist natürlich auch schon was wert, denn AVX512 bringt auch schon mit 256bit Operanden manchmal was. Und es dürfte dem Chaos von den 27 verschiedenen AVX-Versionen perspektivisch ein Ende bereiten.
Aber am Ende könnte es durchaus so sein, daß die Desktop-CPUs auch in Zukunft auf 256bit limitiert bleiben.

[Zossel]

Im Prinzip gibt es ein Bit für "AVX10.2 base" Support (mit verpflichtend lediglich 128bit Operanden), und dann noch zusätzliche Flags für Unterstützung des gleichen Befehlssatzes mit 256bit bzw. 512bit Operanden.
Bei AVX10.2 ist also weiterhin zu diesem Zeitpunkt unklar, ob die E-Cores wirklich "AVX512 v2.0" (also 512bit Operanden) unterstützen. Denn auch bei AVX10.2 ist 512bit Unterstützung wie erwähnt lediglich optional (technisch sogar 256bit). Es ist also sehr gut möglich, daß die einzige Verbesserung sein wird, daß der Befehlssatz an sich vereinheitlicht wird. Das ist natürlich auch schon was wert, denn AVX512 bringt auch schon mit 256bit Operanden manchmal was. Und es dürfte dem Chaos von den 27 verschiedenen AVX-Versionen perspektivisch ein Ende bereiten.
Aber am Ende könnte es durchaus so sein, daß die Desktop-CPUs auch in Zukunft auf 256bit limitiert bleiben.

Anscheinend will Intel noch weitere Befehlssätze einführen:

https://www.phoronix.com/news/Intel-APX
https://blog.fefe.de/?ts=9a4173fe

Der Treppenwitz wäre das AMD für FP schon mal vor längerer Zeit eine 3-Operanden Maschine einführen wollte, Intel aber damals nicht mitgezogen ist. Jetzt soll auch Integer als 3-Operanden Maschine implementiert werden.

Bzgl. Conditional Instructions: Hat ARM die nicht bei 64-Bit abgeschafft?

[ryan]

Im Prinzip gibt es ein Bit für "AVX10.2 base" Support (mit verpflichtend lediglich 128bit Operanden), und dann noch zusätzliche Flags für Unterstützung des gleichen Befehlssatzes mit 256bit bzw. 512bit Operanden.
Bei AVX10.2 ist also weiterhin zu diesem Zeitpunkt unklar, ob die E-Cores wirklich "AVX512 v2.0" (also 512bit Operanden) unterstützen. Denn auch bei AVX10.2 ist 512bit Unterstützung wie erwähnt lediglich optional (technisch sogar 256bit). Es ist also sehr gut möglich, daß die einzige Verbesserung sein wird, daß der Befehlssatz an sich vereinheitlicht wird. Das ist natürlich auch schon was wert, denn AVX512 bringt auch schon mit 256bit Operanden manchmal was. Und es dürfte dem Chaos von den 27 verschiedenen AVX-Versionen perspektivisch ein Ende bereiten.
Aber am Ende könnte es durchaus so sein, daß die Desktop-CPUs auch in Zukunft auf 256bit limitiert bleiben.


Die zuküntigen E-Kerne in ARL und Lunar Lake unterstützen nur 256 Bit. Der Vorteil wäre, dass sie trotzdem auf das AVX512(AVX10.2) Feature Set mit neuen Instruktionen und Registern zurückgreifen können trotz fehlender 512 Bit Vector Breite. Es profitiert nicht alles von 512 Bit. Praktisch wird das Feature Level von der Vectorbreite entkoppelt. Übrigens sollen AVX2 Anwendungen ohne Software Tuning alleine durch die Neukompilierung mit AVX10 einen performance Zuwachs bekommen.


Intel AVX2-compiled applications, re-compiled to Intel AVX10, should realize performance gains without the need for additional software tuning.

[Zossel]

Übrigens sollen AVX2 Anwendungen ohne Software Tuning alleine durch die Neukompilierung mit AVX10 einen performance Zuwachs bekommen.

Da wo Vektoren Spaß machen findet man oft Assembler aus der Manufaktur.
Beispiel (strlen()): mit Erklärung: https://lock.cmpxchg8b.com/zenbleed.html#introduction

[mczak]

Es gibt nicht den bestimmten Standard. AVX512 war ein komplettes Durcheinander mit zig unterschiedlichen feature flags. AVX10 wird zukünftig die Nachkommastelle bei neuen Erweiterungen hochzählen. Das wurde auf Developer Feedback hin gendert.

Naja also die verschiedenen Feature Sets hat intel doch bloss wegen Xeon Phi gemacht. Diese Chips unterstützten ja auch AVX-512, aber ausser dem Base-Set sind da praktisch sämtliche Extensions zu denen der "normalen" Chips unterschiedlich. (AVX512ER z.B. konnte schon der erste Xeon Phi aber auch die neuesten Xeons nicht, das scheint nun komplett tot zu sein und nicht in AVX10 enthalten.) Darauf braucht man nun keine Rücksicht mehr zu nehmen, und kann daher wieder zum alten Schema wie es auch bei SSE üblich war zurückkehren. Und klar, dass da zumindest theoretisch beliebige AVX512 Feature Set Kombinationen möglich waren mochte natürlich niemand.
Bei den "normalen" CPUs haben meines Wissens aber immer die neuen Chips alle Features der vorherigen Chips unterstützt und ich würde darauf wetten so wurde in der Praxis auch dafür programmiert (es reicht in der Praxis aus auf ein neues Feature zu testen und geht dann davon aus dass auch alle älteren Features vorhanden sind), da ändert sich also in der Praxis wohl so gut wie nichts.

Die wirklich neuen Features kommen in AVX10.2, wo dann auch die E-cores mit unterstützt werden.
AVX10 kann trotzdem nicht darüber hinwegtäuschen dass es halt bloss AVX512 ist bei dem 512bit Vektoren optional sind - bloss wegen der underschiedlichen Feature-Nummerierung hätte man das sicher nicht gebraucht.
Finde das übrigens ziemlich interessant dass intel ganz offensichtlich nicht vorhat in naher Zukunft 512bit Vektoren bei den E-Cores zu unterstützen - das hätte man ja wie AMD machen können und die Befehle einfach in 2x256bit splitten. Dann würde es AVX10 gar nicht geben.

[mksn7]

Vom Lesen der News hätte ich auch gedacht, dass AVX10 nur AVX512 mit optionalem 512 ist. Laut einem Kollegen, der das Dokument tatsächlich gelesen hat, ist es aber auch möglich vektorlängenagnostischen code und binaries zu schreiben (a la SVE), die je nach vorhandener Vektorlänge in hardware so oder so ausgeführt werden.

Nur das migrieren von threads zwischen cores mit unterschiedlicher Vektorlänge kann ich mir technisch nicht vorstellen. Entweder das OS vermeidet das einfach, oder bei P und E core gemischt geben die P cores auch nur 256 bit Vektorlänge an.

AMD's Ansatz braucht zwar nur halb breite execution units, aber voll breite Register. Und manche Befehle wie shuffle usw müssen dann doch voll breit gemacht werden.

Spannender als AVX10 finde ich aber APX. Davon profitiert ja wirklich alles, nicht nur die SIMD Nischen.

[Cubitus]

14900K = 13900KS mit etwas mehr MT-Leistung, weil die Stromversorgung ja etwas flexibler ist.
Schade, dass sich der 14600k mit 8 p-Kernen nicht bewahrheitet hat sondern "nur" 6+8 ist.

Das ist doch gut, jeder P Core erzeugt Hitze und Leistung.
Der 13600K ist aktuell ein sehr effizientes Stück HW.

6P Cores reicht noch für jedes Spiel

[dildo4u]

Das ist doch gut, jeder P Core erzeugt Hitze und Leistung.
Der 13600K ist aktuell ein sehr effizientes Stück HW.

6P Cores reicht noch für jedes Spiel


Ebend und 7600x sind 230€ daher ist der 13600k eher mäh, macht deutlich mehr Sinn die 100€ in die GPU zu stecken.
Die billigen Intel Modelle sind leider vom Takt beschränkt was die Gaming Performance senkt.

[mczak]

Vom Lesen der News hätte ich auch gedacht, dass AVX10 nur AVX512 mit optionalem 512 ist. Laut einem Kollegen, der das Dokument tatsächlich gelesen hat, ist es aber auch möglich vektorlängenagnostischen code und binaries zu schreiben (a la SVE), die je nach vorhandener Vektorlänge in hardware so oder so ausgeführt werden.

Das Paper habe ich auch gelesen (sind ja bloss 3 Seiten), und davon steht da kein Wort.
https://cdrdv2.intel.com/v1/dl/getContent/784343


Spannender als AVX10 finde ich aber APX. Davon profitiert ja wirklich alles, nicht nur die SIMD Nischen.
Ja, allerdings darf man keine Wunder erwarten. Würde mich aber interessieren in welchem Zeitraum das kommen soll, dazu sagt intel (im Gegensatz zu AVX10) nichts.

[ryan]

Vom Lesen der News hätte ich auch gedacht, dass AVX10 nur AVX512 mit optionalem 512 ist. Laut einem Kollegen, der das Dokument tatsächlich gelesen hat, ist es aber auch möglich vektorlängenagnostischen code und binaries zu schreiben (a la SVE), die je nach vorhandener Vektorlänge in hardware so oder so ausgeführt werden.



AVX10 ist zu erst einmal ein rebranded AVX512, weil 512 zukünftig nicht mehr passend wäre. Granite Rapids ist AVX512 in AVX10.1, ich sehe da nichts Neues. Neuerungen gibt es erst mit AVX10.2, wo es dann auch Support für E-Kerne mit 256er Breite geben soll, sozusagen ein 256er subset von AVX512.




Finde das übrigens ziemlich interessant dass intel ganz offensichtlich nicht vorhat in naher Zukunft 512bit Vektoren bei den E-Cores zu unterstützen - das hätte man ja wie AMD machen können und die Befehle einfach in 2x256bit splitten. Dann würde es AVX10 gar nicht geben.


Wo liest du das denn raus mit 512 Bit Vektoren?

[mksn7]

Das Paper habe ich auch gelesen (sind ja bloss 3 Seiten), und davon steht da kein Wort.
https://cdrdv2.intel.com/v1/dl/getContent/784343


Nicht da kurze Ding, die architecture specification mit >1300 Seiten

https://cdrdv2.intel.com/v1/dl/getContent/784267

Aber ehrlich gesagt seh ichs auch gerade nicht so richtig wie man damit vektorlängenagnostischen code schreiben soll.

[Zossel]

Aber ehrlich gesagt seh ichs auch gerade nicht so richtig wie man damit vektorlängenagnostischen code schreiben soll.

Dafür bräuchte man doch bestimmt bitbreiten agnostische Register?

[mczak]

Wo liest du das denn raus mit 512 Bit Vektoren?
Das ist einfach meine Interpretation weshalb es AVX10 überhaupt gibt. Natürlich schon möglich dass irgendwann E-Cores mit 512 bit Unterstützung kommen, ich denke aber das wird ein paar Generationen dauern.

[Gipsel]

Finde das übrigens ziemlich interessant dass intel ganz offensichtlich nicht vorhat in naher Zukunft 512bit Vektoren bei den E-Cores zu unterstützenWo liest du das denn raus mit 512 Bit Vektoren?https://cdrdv2.intel.com/v1/dl/getContent/784267 Seite 13:
The Intel AVX10 architecture introduces several features and capabilities beyond the Intel AVX2 ISA:
Version-based instruction set enumeration.
Intel AVX10/256 − Converged implementation support on all Intel® processors to include all the existing Intel AVX-512 capabilities such as EVEX encoding, 32 vector registers, and eight mask registers at a maximum vector length of 256 bits and maximum opmask length of 32 bits.
Intel AVX10/512 − Support for 512-bit vector and 64-bit opmask registers on P-core processors for heavy vector compute applications that can leverage the additional vector length.

[ryan]

Das ist einfach meine Interpretation weshalb es AVX10 überhaupt gibt. Natürlich schon möglich dass irgendwann E-Cores mit 512 bit Unterstützung kommen, ich denke aber das wird ein paar Generationen dauern.


Ich hab mich verlesen. Dachte du meinst, es sollen E cores mit 512 bit kommen.

[mksn7]

Dafür bräuchte man doch bestimmt bitbreiten agnostische Register?

Dafür müsste das instruction encoding die Vektorbreite offen lassen, und die kann man at runtime abfragen, um zu sehen wie weit man z.B. loop indices inkrementieren muss. Geht bei SVE auch. Allerdings sehe ich das (soweit ich gesehen habe) bei AVX10 nicht.

Da muss ich meinen Kollegen nochmal fragen dass er mir das erklären soll was er da gesehen haben will.

[Zossel]

Dafür müsste das instruction encoding die Vektorbreite offen lassen, und die kann man at runtime abfragen, um zu sehen wie weit man z.B. loop indices inkrementieren muss. Geht bei SVE auch. Allerdings sehe ich das (soweit ich gesehen habe) bei AVX10 nicht.

Eigentlich kämpft man ja in den inneren Schleifen von vektorisierten Code um jeden Taktzyklus, da sind Fallunterscheidungen zur Laufzeit eher blöd.

[mksn7]

Eigentlich kämpft man ja in den inneren Schleifen von vektorisierten Code um jeden Taktzyklus, da sind Fallunterscheidungen zur Laufzeit eher blöd.

Nein, natürlich keine Fallunterscheidung!

Einfach nur Vektorinstruktionen und register, für die keine fixe Vektorlänge bei Compilezeit definiert ist.

Eine update, "A[:] *=2" Schleife könnte in pseudo assembler so aussehen:


%r1 = [0,1,...vlen]
vcmp %r1, $100- > %p1
.loop
@p1 vld vector [%r1] -> %v1
@p1 vmul %v1, $2 -> %v1
@p1 vst %v2 -> [%r1]
vadd %r1, vlen -> %r1
vcmp %r1, $100 -> %p1
jb .loop


%r1 ist ein GP register mit den indizes (müsste man nicht so machen, weil die ld/st dann scatter/gather werden, aber in meiner Fantasie ISA ist das kein Problem), %v1 ist ein Vetkorregister der Länge vlen (Hardwareeigenschaft), und %p1 ist ein Maskenregister/Prädikat. Je nachdem welche vlen die hardware hat, werden dann unterschiedliche viele Elemente pro Schleife abgearbeitet. SVE macht das so, AVX10 denke ich nicht.

Ich weiß nicht ob das Beispiel eines echten SVE code klarer ist oder nicht:

https://community.arm.com/resized-image/__size/1240x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-37-98/Scalable-Vector-Extension-Graph-1.png

Der Schlüssel ist hier auch, dass das incd um die erst zur runtime bekannten Vektorlänge inkrementiert, und das whilelt die Maske p0 generiert für den remainder. Die 128bit Variante links braucht 2 Schleifendurchläufe für 3 Elemente, die 256bit Variante rechts nur einen.

Aber nochmal: Ich bin mir recht sicher dass AVX10 das nicht macht.

[ryan]

Es gibt keine Änderungen was 20A angeht, alles on track. edit: das erste Stepping läuft im Labor



Intel remains on track to meet its goal of achieving five nodes in four years and to regain transistor performance and power performance leadership by 2025. The company announced an industry-first implementation of backside power using Intel PowerVia in a test chip, resulting in notable performance and efficiency gains. PowerVia will be incorporated into Intel 20A, expected to launch in the first half of 2024.

Intel 4: Ramping Meteor Lake production wafer starts; expect to launch in 2H 2023
• Intel 3, Intel 20A, Intel 18A: On track

5 nodes in 4 years:
Intel 7 done, Intel 4 production ramping
Intel 3, Intel 20A, Intel 18A on track
RibbonFet and PowerVia on 20A and 18A


Meteor Lake PRQ in Q3’23 bringing AI to the PC at scale
Arrow Lake and Lunar Lake in 2024

Emerald Rapids in Q4’23
Sierra Forest in 1H’24 followed by Granite Rapids both on Intel 3
Clearwater Forest on 18A in ’25
Gaudi3 in 1H’24

https://www.intc.com/news-events/press-releases/detail/1637/intel-reports-second-quarter-2023-financial-results


Meteor Lake Production Release Qualification (PRQ) soll noch in Q3 erfolgen. Das sieht nach einem launch im September oder Oktober aus.

[reaperrr]

Naja MLID erzählt immer viel Unsinn wenn der Tag lang ist. Auch +40% MT Performance von MTL zu ARL @same Power bei gleicher Kernzahl klingt ziemlich übertrieben.
Aber Igors Zahlen klingen in der Tat sehr schlecht für zwei Nodesprünge und zwei Core Iterationen. Taktrate hin oder her.
Ich hoffe da kommt mehr bei rum.

Was wir (und v.a. auch MLID) meiner Meinung nach nicht unterschätzen dürfen:

1. Intel 7 ist vielleicht in Sachen Effizienz und Logik-Packdichte nur knapp auf N7-Niveau, aber zumindest in Sachen SRAM-Packdichte (und vermutlich auch -Performance) sowie generell Transistorperformance (wenn TDP zweitrangig ist) schneidet Intel 7 inzwischen ganz gut ab.
Und: Intel hat Intel 7 jetzt jahrelang bis zum Erbrechen auf ihre eigene Architektur optimiert, v.a. hinsichtlich Performance (Taktraten). Das ist was völlig anderes, als wenn man wie AMD Prozesse "von der Stange" mit nur moderaten Parameter-Anpassungen verwenden muss.
So schlecht es mit 10nm angefangen hat, inzwischen ist Intel 7 mMn ca. so weit ausoptimiert, wie es 14nm gegen Ende war.

Was heißen soll, selbst wenn 20A "on track" ist, heißt das noch lange nicht, dass man damit gleich ähnliche, geschweige denn höhere Taktraten schafft, wenn gleichzeitig die Kerne fetter werden.
Gleiches gilt auch, wenn sie N3B oder N3E verwenden sollten, das sind keine bis zum Erbrechen auf Intel und möglichst hohe Taktraten optimierte Prozesse, selbst wenn für Intel ein paar Dinge mehr angepasst werden als für andere Kunden.

2. So viel mehr IPC, wie ARL ggü. RTL haben soll, erreichst du meiner Einschätzung nach eigentlich nur mit (deutlich) mehr Transistor-Aufwand.
Und die RTL-Kerne brauchen für ihre IPC bereits wesentlich mehr Transistoren als Zen4.
Heißt, in einem nur unwesentlich besseren Prozess wird der Verbrauch je Kern je MHz in höheren Taktbereichen eher weiter steigen.

Die Kombination aus 1. und 2. kann absolut dazu führen, dass ARL trotz 30-40% mehr IPC der P-Kerne am Ende nur 7-20% schneller ist als RTL, wenn man beim Takt aufgrund a) weniger ausoptimierter Prozesse und b) deutlich mehr Transistoren je Kern in gleicher TDP halt nur noch Zen3-artige Taktraten (~5 GHz Turbo, 4.5-4.7 AllCore) schafft.

Natürlich kann es sein, dass es am Ende einige Hundert MHz mehr werden und die Perf stärker ansteigt, aber dass sowohl 20A als auch N3(B/E) Probleme haben, 8 so richtig Transistor-schwere Kerne wie Lion Cove innerhalb von 250W auf mehr als 5 Ghz zu kriegen, ist für mich nicht abwegig.
Und 1 Ghz weniger im Vergleich zu RTL würde bereits reichen, um trotz 30-40% mehr IPC bei den Igor-Zahlen zu landen.

[mocad_tom]

https://www.fool.com/earnings/call-transcripts/2023/07/28/intel-intc-q2-2023-earnings-call-transcript/

Intel hat mit Ericsson einen ersten Intel 18A-Kunden unter Vertrag genommen.

Intel hat jedes Release Date in 2023 und 2024 so bestätigt.

Gaudi3 wird im H1 2024 fertig (vielleicht genau richtig für Micron HBM3 Gen2).

Emerald Rapids ist nicht verzögert, Intel 20A ist nicht verzögert.

Dort wo es Schmerzen gibt trägt wohl eher TSMC mit Schuld dran.
Arrow Lake für den Laptop mit Intel 20A scheint wohl auf dem Weg zu sein.
Aber Arrow Lake-S mit TSMC-Prozess wurde nicht eigens genannt.


Und dann gibt es die Ansage, dass man an Falcon Shores 1 für 2025 und Falcon Shores 2 für 2026 arbeitet.

Wovon man halt nichts gehört hat war Melville Sound und Battlemage.

[ryan]

Dort wo es Schmerzen gibt trägt wohl eher TSMC mit Schuld dran.
Arrow Lake für den Laptop mit Intel 20A scheint wohl auf dem Weg zu sein.
Aber Arrow Lake-S mit TSMC-Prozess wurde nicht eigens genannt.


Warum sollten sie das eigens nennen? Intel versucht TSMC so gut wie möglich gar nicht erst zu erwähnen. Die Gerüchte, Intel hätte 20A komplett gecancelt, hat Gelsinger eine Absage erteilt. Das ist die wichtigste Erkenntnis von gestern.

Im übrigen wurde mobile nicht explizit genannt. Der letzte Stand war, es gibt ein tile mit 20A, der auch für Desktop kommen soll. Und zwar ist das ein 6+8 tile. Ein 6+8 tile würde sich natürlich auch für mobile anbieten.

Hier sollte man auch nicht vergessen, dass ursprünglich MTL-S die 6+8 Lücke für Desktop übernehmen sollte. Aus der Zeit stammen die 20A mobile only und TSMC N3 Desktop only Gerüchte. MTL-S wurde im Mai endgültig gecancelt, weswegen (so sieht es aus) ARL-S doch für 20A kommt als 6+8 Variante.

[HOT]

Ja, ne. Das ist einfach Unsinn. Ich zitiere:

Intel remains on track to meet its goal of achieving five nodes in four years and to regain transistor performance and power performance leadership by 2025. The company announced an industry-first implementation of backside power using Intel PowerVia in a test chip, resulting in notable performance and efficiency gains. PowerVia will be incorporated into Intel 20A, expected to launch in the first half of 2024.

Was steht denn da:
1.) Es gibt Testchips mit PowerVIA, kein Wort von GAA! Soweit waren wir schon im März.
https://www.computerbase.de/2023-03/intel-20a-und-18a-tape-out-erfolgt-und-alles-super-an-der-fertigungsfront/
Es hat sich also seit März nichts geändert. Es wird weiter herumgetestet, von GAA bisher fehlt jede Spur.
2.) Wenn es Testchips gibt, gibts bisher kein ARL-Tapeout in 20A. Das würde aber langsam knapp.
3.) Bereitschaft der Fertigung 25 bedeutet, man kann da in 18A seine finalen Chips ins Tape In geben.
Produkte gibts dann aber nicht vor 26 ;).

Ich bleibe dabei, es hat sich nichts geändert, das ist nur Marketingblabla. 20A kommt mMn nicht pünktlich genug für ARL Anfang 25, wenn dann gibts erste Tape Outs in 24. eigentlich lohnt sich der Prozess nicht, wenn 18A läuft.

[ryan]

Ja, ne. Das ist einfach Unsinn. Ich zitiere:



Du erzählst Unsinn, so wie meistens.



On Intel 20A, our first node using both RibbonFET and PowerVia, Arrow Lake, a volume client product is currently running its first stepping in the fab.

[HOT]

Na immerhin das. MTL Silizium gibt es schon seit Mitte 21, ich möchte nur daran erinnern, wie lange das bei Intel dauert.

[ryan]

Na immerhin das. MTL Silizium gibt es schon seit Mitte 21, ich möchte nur daran erinnern, wie lange das bei Intel dauert.


Auch dieser Vergleich ist falsch. Mitte 2021 gab es den tape in vom Compute tile, seit Q4 2021 ist das Compute tile erstmals "lauffähig", der Chip als Ganzes allerdings erst seit Q2 2022, seit April 2022 um genau zu sein. Letzteres müsstest du als Vergleich ranziehen. Das genaue Datum von Arrow Lake kennen wir nicht, der kann auch schon seit 2 Monaten im Labor laufen. Es liegt gut ein Jahr oder etwas mehr ein Jahr dazwischen kann man sagen, das passt schon eher.



On Intel 4, we had taped out our compute tile for Meteor Lake and this quarter it came out of the fab and powered up within 30 minutes with outstanding performance, right where we expected it to be.


Intel 4 Meteor Lake has now successfully booted Windows, Chrome, and Linux.


We have officially powered-on our first disaggregated product: Meteor Lake. An incredible milestone resulting from the efforts of so many across @intel
. Congratulations, team!
https://www.rev.com/blog/transcripts/intel-intc-q3-2021-earnings-call-transcript
https://videocardz.com/newz/14th-gen-core-meteor-lake-has-been-powered-on-on-track-to-launch-in-2023

[ryan]

Der L2 Cache steigt angeblich auf 3MB pro Kern.


ARL-S Big Core L2 3MB (per Core)
https://twitter.com/9550pro/status/1690365660420071424
https://www.bilibili.com/opus/828961789450387462

[w0mbat]

Puh, Intel dreht weiter an der L2$ Schraube. Golden Cove = 1.25MB, Raptor Cove = 2MB, Lion Cove (?) = 3MB. Dadurch werden die Kerne auch nicht kleiner (wobei der Sprung auf 2MB bei Raptor Cove nicht wirklich viel Fläche gebraucht hat).

Echt interessant, dass Intel den L2$ in so kurzer Zeit so massiv erhöht.

[Platos]

Bringt das überhaupt noch was beim Gaming? Gibts Tests bezüglich Raptorlake vs Alderlake bei selben Taktraten ?

[w0mbat]

Ich glaub das ist vor allem dazu da, um L3$ Zugriffe zu minimieren und damit den ringbus zu entlasten. Wenn man acht große und sechzehn kleine Kerne hat und jeder was vom L3$ will, wird es problematisch.

[ryan]

Bringt das überhaupt noch was beim Gaming? Gibts Tests bezüglich Raptorlake vs Alderlake bei selben Taktraten ?


Computerbase hatte damals beim Raptor Lake launch +3% IPC in Spielen gemessen. Wie sich das bei Lion Cove auswirkt kann man davon aber nicht wirlich ableiten, weil es bei Lion Cove ingesamt einen größeren Cache Umbau geben soll, der Zuwachs beim L1 wäre noch bemerkenswerter.


LNC may intro new L0 level cache

Should clarify, this L0 is renamed from L1, the new L1 will be a Latency-reduced L2 cache which has similar size as old day L2



Ich glaub das ist vor allem dazu da, um L3$ Zugriffe zu minimieren und damit den ringbus zu entlasten. Wenn man acht große und sechzehn kleine Kerne hat und jeder was vom L3$ will, wird es problematisch.


Zumal die tGPU schon ab Meteor Lake keinen Zugriff mehr auf den L3 hat. Bei den riesigen L1 und L2 Zuwächsen muss man sich schon die Frage stellen, ob es einen L3 in der jetzigen Form überhaupt geben wird.

[Zossel]

Ich glaub das ist vor allem dazu da, um L3$ Zugriffe zu minimieren und damit den ringbus zu entlasten. Wenn man acht große und sechzehn kleine Kerne hat und jeder was vom L3$ will, wird es problematisch.

Intel hätte trotz seiner Schwäche in der Fertigung ruhig mal die Architektur auf Vordermann bringen können.

[reaperrr]

Intel hätte trotz seiner Schwäche in der Fertigung ruhig mal die Architektur auf Vordermann bringen können.
Ringbus skaliert nur bis zu einem bestimmten Punkt vernünftig, aber bis zu diesem Punkt ist es scheinbar die einfachste Lösung (auch AMD ist ja innerhalb der CCDs auf Ringbus umgeschwenkt).
Außerdem gilt generell, solange es das Transistorbudget zulässt, sind größere Caches was Positives. L2 ist schneller als L3, und on-die Cache ist generell schneller und energiesparender als off-chip zum RAM oder einem externen L4 zu müssen.

AMD knausert da nur etwas mehr, weil SRAM halt recht viel Fläche benötigt. Performance und Perf/W würden auch bei AMD von einem größeren L2 profitieren (wenn sie die Latenz weitgehend gleich halten könnten).

Zu Lion Cove: Ich denke, Intel will hier die Stärken der früheren, schnellen inklusiven L2-Caches mit den Vorteilen der langsamen, aber größeren L2 seit Tiger Lake kombinieren.
Das Problem ist, je größer die L2 werden, desto höher wird schleichend auch die Latenz (oder, wenn man die Latenz nicht erhöht, der Energieverbrauch je MHz).
Da noch einen inklusiven 256KB "L1,5" Cache mit nur 12-Cycle Latenz zwischenzuschalten würde in latenz-sensitiven Anwendungen - dazu zählen u.a. auch Spiele - ne Menge bringen, gleichzeitig könnte man ruhigen Gewissens die Größe und Latenz des großen L2 erhöhen, um neben L3- vor allem auch die langsamen und energetisch teuren VRAM-Zugriffe weiter zu reduzieren.

[iamthebear]

Ich denke, dass es bei Intel langfristig auf folgendes hinaus läuft:
L1 bleibt so wie bisher
L2 wird auf 2 Level aufgeteilt:
256KB schnellen L2 pro Kern
ca. 4MB L2, die wahlweise über 2 Kerne geshared oder fix einem Kern zugeordnet werden können (siehe MLID Video über Rentable Units)
Der L3 wandert runter in den Base Die und wird mit der iGPU geshared (Adamantine)

Was den Ringbus angeht: Ja dieser limitiert allerdings sind die Alternativen noch schlimmer:
Bei einem Mesh wie SR ist die Core to Core Latenz und damit auch die Speicherlatenz deutlich höher.
Auch der Ansatz von AMD überzeugt nicht wirklich wo der L3 bei 2 CCDs nicht über alle Kerne geshared wird. Das ist toll für aktuelle Spiele die nur 8 Kerne brauchen oder Multimediaanwendungen die kaum Speicherbandbreite brauchen aber bei zukünftigen Spielen die 16+ Threads nutzen und auch viel gemeinsame Daten verwenden ist das suboptimal.

[ryan]

Ich denke, dass es bei Intel langfristig auf folgendes hinaus läuft:
L1 bleibt so wie bisher


Der L1 wird aber in L0 umbenannt.



Should clarify, this L0 is renamed from L1, the new L1 will be a Latency-reduced L2 cache which has similar size as old day L2

[Der_Korken]

Ich fände es komisch 3 private Cache-Stufen zu verbauen, da man immer auch bedenken muss, dass die obere Cache-Stufe alle Latenzen der unteren mitschleppt. Beispiel:

Raptor Cove:
48kB L1D: 5 Takte
2MB L2: 16 Takte (+11 auf vorigen)

hypothetischer Lion Cove*:
48kB L1D: 5 Takte
256kB L2: 12 Takte (+7 auf vorigen**)
3MB L3: 24 Takte (+12 auf vorigen***)

Zwischen 48 und 256kB verbessert sich die Latenz von 16 auf 12, aber von 256kB bis 2MB verschlechtert sie sich von 16 auf 24. Schwer zu sagen, ob sich das lohnt. Der L3 wird natürlich auch nochmal um 8 Takte langsamer, da auf dem Weg dahin ein Cache mehr durchsucht werden muss.

Interessant fände ich eher, wenn die Kerne zu Gruppen zusammengefasst werden. So ähnlich wie die E-Cores aktuell zu viert jeweils einen L2 für sich haben. Statt dass jeder P-Core 2MB L2 für sich hat, teilen sich je vier P-Cores z.B. 8MB oder 12MB (oder zwei Cores 4MB oder 6MB). Dadurch wird bei wenig paralleler Rechenlast der platzfressende Cache besser ausgenutzt.

Für Zen 5 gab es auch mal Gerüchte, dass der L2 dort über ein ganzes CCX geshared wird. Da hatte ich mich auch gefragt, ob AMD wieder auf 4C-CCX gehen könnte (wie bei Zen 2), mit dem Unterschied, dass auf dem IOD dann noch ein gemeinsamer (mglw. gestackter) L3 sitzt und der L2 pro Kern dann kleiner ausfallen könnte als der aktuelle L3. Imho wäre das in Zukunft das überlegenere Speichersystem als die getrennten L3-Caches (von denen auch wieder nur einer gestackt ist bei den 3D-Modellen :freak:). Es scheint nicht so zu kommen, aber es wäre lustig, wenn Intels und AMDs Speichersystem nach so langer Zeit wieder konvergieren würden.



* Die Cache-Level-Namen spielen keine Rolle, ich fange immer bei 1 an zu zählen.
** Entspricht dem Skylake-Wert, eigentlich müssten es eher 13 sein, da Skylakes L1 nur 4 Takte hatte afaik
*** Habe +1 Takt gegenüber den 2MB von Raptor Cove genommen

[aceCrasher]

Raptor Cove:
48kB L1D: 5 Takte
2MB L2: 16 Takte (+11 auf vorigen)

hypothetischer Lion Cove*:
48kB L1D: 5 Takte
256kB L2: 12 Takte (+7 auf vorigen**)
3MB L3: 24 Takte (+12 auf vorigen***)Skylake-SP hatte bereits einen "11-13 cycle" (https://www.anandtech.com/show/11550/the-intel-skylakex-review-core-i9-7900x-i7-7820x-and-i7-7800x-tested/4) 1MB L2 - keine Ahnung wieso da eine Spanne angegeben wird. Also auch +7 (+9?) cycle zum L1, trotz 4x Größe.

hypothetischer alternativer Lion Cove:
48kB L1D: 5 Takte
1MB L2: 12-14 Takte (+7-9 auf vorigen)
3MB L3: 24-26 Takte (+12-14 auf vorigen)

Keine Ahnung ob das sinnvoll wäre. Wohl eher nicht im Vergleich zu "nur" 3MB L2 @15 cycle.

Sinnvoll wäre das dreistufige Design wohl IMO nur wenn der "L2" zwischen einem Cluster geteilt wäre. Zum Beispiel zwei nebeneinander liegende P-Kerene, da könnte man sie trotzdem noch wie bisher um den Ringbus herum anordenen. Ich könnte mir das so vorstellen:
- 48kB L0 privat
- 512kB/1MB L1 privat
- 6MB L2 mit benachbartem P-Kern geteilt (also 3MB/Kern)
- 3MB L3 pro Kern/Cluster zwischen allen geteilt