Intel - Ab Nova Lake - Royal/Cobra Core [Archiv]

HOT

2024-09-16, 22:35:49

Na ja, wenn man alles einordnen würde, würde ich eher sagen, dass Jim Kellers Endstadium für Royal Core Beastlake+ gewesen wäre und das von Pat gecancelt wurde.
Ich würde daher davon ausgehen, dass die Cobra Cores einfach der Nachfolger der Cores aus Nova Lake und Beast Lake sein wird, also mehr oder weniger ein normaler p-Core. Ob da jetzt rentable Units drin sind, wie das letztendlich umgesetzt wird, ob das wirklich 2 leichte oder ein heftiger Thread dann sind, wird sich alles zeigen.
die Frage ist, wie sieht das jetzt aus: Etwa so?

2024/25 -> Lunar Lake/Arrow Lake U/H/S
2025/26 -> Panther Lake U/H / Arrow Lake Refresh S
26/27 -> Nova Lake U/H / Beast Lake S
27/28 -> Produkte auf Cobra Cove Basis ?

Sunrise

2024-09-17, 11:41:55

Royal TS and Cobra Kai sag ich nur.

HOT

2024-09-18, 14:05:23

https://www.guru3d.com/story/intel-royal-core-x86-microarchitecture-origins-features-and-future-plans/

ein paar sehr interessante Dinge zum Thema... wobei ich glaube, dass die da durcheinandergekommen sind, 4x SMT wurde vorher schon für Panther Cove zugeordnet und jetzt taucht Panther Cove plötzlich bei Nova Lake wieder auf... lt MLID (ja ich wiess) soll Panther Cove von Radwood Cove abstammen, nicht von Lion Cove... sehr interessant alles.

iamthebear

2024-09-18, 17:49:43

Ich glaube dass das mit "royale core" bzw. die Aufgabe von Jim Keller etwas falsch aufgefasst wurde. Jim Kellers Projekte sind nicht deshalb ein Erfolg weil er selbst so gute CPUs designed sondern weil er Organisation in den Laden rein bringt und die anfänglixhe Planung richtig macht. Der Rest läuft denn quasi von alleine.

So wie ich das sehe ist Royale Core nicht ein einzelner Core sondern das Konzept dass die CPU in einzelne Blöcke zerlegt wird und zuerst einmal die Schnittstellen definiert werden.
Danach lassen sich die jeweiligen Teile individuell designen und in verschiedenen Projekten recyclen. Beispiel: Lunar Lake bekommt zwar dieselben P/E Cores aber in der Stromsparausführung mit E Cores ohne L3 Zugang damit man P Cores inkl. Ring/L3 abschalten kann. Bei ARL ist es ein Compute Die und die E Cores haben L3 Zugriff und im Datacenterbereich kann man wieder etwas Anderes machen.

In MTL hat man bisher nur das Chipletkonzeot umgesetzt und auf Intel 4 geshrinked. Mit ARL/Lunar Lake hat man dieses verbessert und einen neuen E Core konstruiert. Der P Core dürfte eine Übergangslösung sein.
Nova Lake macht vermutlich den P Core neu (oder leitet diesen vom E Core Design ab)

Aus Highend Desktop Gamer Sicht ist das alles nicht so spektakulär aber für den deutlich grösßeren Laptopmarkt ist Lunar Lake ein echt wichtiger Schritt. Und Clearwater Forrest hört sich auch so an als würde Intel damit wieder ein konkurrenzfähiges Datacenter Produkt haben.

https://www.guru3d.com/story/intel-royal-core-x86-microarchitecture-origins-features-and-future-plans/

ein paar sehr interessante Dinge zum Thema... wobei ich glaube, dass die da durcheinandergekommen sind, 4x SMT wurde vorher schon für Panther Cove zugeordnet und jetzt taucht Panther Cove plötzlich bei Nova Lake wieder auf... lt MLID (ja ich wiess) soll Panther Cove von Radwood Cove abstammen, nicht von Lion Cove... sehr interessant alles.

Laut einem älteren MLID Video gab es 2 parallele Entwicklungen:
a) Rentable Units: Kleinere Kerne ohne SMT bei denen sich 2 den L2 teilen und im ST Betrieb lassen sich 2 davon zu einem Kern zusammenschalten (oder umgekehrt von 1 in 2 aufsplitten je nachdem woe man es sieht).
b) Große Kerne mit SMT4: Das hört sich nach dem Royale Core Design an

In Simulationen hat das SMT4 Design aber so schlecht abgeschnitten dass man es gecanceled hat.

Meine Vermutung: Beast Lake war ein Nachtfolger davon und ist somit "mitgestorben". Die Aussagen, dass es "kein Problem mit dem Design gab" nehme ich ehrlich gesagt nicht wirklich Ernst. Das sind mit Sicherheit frustrierte gekündigte Mitarbeiter die jetzt leaken. Die werden kaum zugeben dass das was sie fabriziert haben nicht gut war.

HOT

2024-09-18, 18:21:38

Das ist wieder nur Mist den Tom da gefolgert hat. Man muss echt unterscheiden, was tatsächlich leak ist und was er selber schlussfolgert, denn er ist leider ein ziemlich schlechter Analyst für die ganzen Infos, die er ausgräbt. Ich glaube nicht, dass Panther Cove so schlecht war, ich denke, es war Intel einfach zu teuer, zwei komplett parallele Teams laufen zu lassen, die jährlich ne neue Architektur raushauen. Und hier kommt Pat ins Spiel und das Cannceln: Ich könnt mir vorstellen, dass Pat die Nachfolger von Lion Cove und Cougar Cove, welche Royal Core gewesen wären, gecancelt hat und stattdessen wieder Panther Cove ausgegraben hat. Intel kann das ja jetzt einfach Royal Core nennen, Keller ist ja schon lange weg und Marketing kann Intel ja im Gegensatz zu AMD.
Ich vermute (ist aber nur Vermutung), dass Cobra Core ein neuer p-Kern auf Basis der e-Kerne ist und dass man hier evtl. Rentable Units erstmals sehen wird.
Wir reden hier aber sicherlich von 4-5 Jahren Entwicklungszeit, da es was komplett neues sein dürfte..

Gipsel

2024-09-18, 18:23:48

Ich glaube dass das mit "royale core" bzw. die Aufgabe von Jim Keller etwas falsch aufgefasst wurde. Jim Kellers Projekte sind nicht deshalb ein Erfolg weil er selbst so gute CPUs designed sondern weil er Organisation in den Laden rein bringt und die anfänglixhe Planung richtig macht. Der Rest läuft denn quasi von alleine.

So wie ich das sehe ist Royale Core nicht ein einzelner Core sondern das Konzept dass die CPU in einzelne Blöcke zerlegt wird und zuerst einmal die Schnittstellen definiert werden.
Danach lassen sich die jeweiligen Teile individuell designen und in verschiedenen Projekten recyclen. Beispiel: Lunar Lake bekommt zwar dieselben P/E Cores aber in der Stromsparausführung mit E Cores ohne L3 Zugang damit man P Cores inkl. Ring/L3 abschalten kann. Bei ARL ist es ein Compute Die und die E Cores haben L3 Zugriff und im Datacenterbereich kann man wieder etwas Anderes machen.

In MTL hat man bisher nur das Chipletkonzeot umgesetzt und auf Intel 4 geshrinked. Mit ARL/Lunar Lake hat man dieses verbessert und einen neuen E Core konstruiert. Der P Core dürfte eine Übergangslösung sein.
Nova Lake macht vermutlich den P Core neu (oder leitet diesen vom E Core Design ab)

Aus Highend Desktop Gamer Sicht ist das alles nicht so spektakulär aber für den deutlich grösßeren Laptopmarkt ist Lunar Lake ein echt wichtiger Schritt. Und Clearwater Forrest hört sich auch so an als würde Intel damit wieder ein konkurrenzfähiges Datacenter Produkt haben.

Laut einem älteren MLID Video gab es 2 parallele Entwicklungen:
a) Rentable Units: Kleinere Kerne ohne SMT bei denen sich 2 den L2 teilen und im ST Betrieb lassen sich 2 davon zu einem Kern zusammenschalten (oder umgekehrt von 1 in 2 aufsplitten je nachdem woe man es sieht).
b) Große Kerne mit SMT4: Das hört sich nach dem Royale Core Design an

In Simulationen hat das SMT4 Design aber so schlecht abgeschnitten dass man es gecanceled hat.

Meine Vermutung: Beast Lake war ein Nachtfolger davon und ist somit "mitgestorben". Die Aussagen, dass es "kein Problem mit dem Design gab" nehme ich ehrlich gesagt nicht wirklich Ernst. Das sind mit Sicherheit frustrierte gekündigte Mitarbeiter die jetzt leaken. Die werden kaum zugeben dass das was sie fabriziert haben nicht gut war.
Ich sagte schon im LunarLake-Thread, daß man sich mal Power9 oder Power10 ansehen sollte.
Da besteht jeder Core aus 4 Slices (bzw. sogar aus 4 Superslices zu je 2 Slices, also insgesamt 8 Slices), die unterschiedlich konfiguriert werden können.
Im einfachsten Fall besteht ein Kern aus 4 Slices mit jeweils eigenen Einheiten. Jeder diese 4 Slices kann quasi wie ein eigener (E-)Kern arbeiten (4 Threads). Es können aber auch nur 2 Threads auf jeweils 2 Slices laufen (M-Kern) oder im Extremfall kann ein einzelner Thread alle 4 Slices nutzen (P-Kern). Und es ist dynamisch im Betrieb umschaltbar (nur die Variante mit den 4 Superslices/8 Slices vs. 4 Slices pro Gesamtkern [Letzteres resultiert dann in doppelter Kernanzahl] legt IBM vor Auslieferung unveränderbar fest [ist aber der physisch identische Chip]).
Ist natürlich nicht Alles rosig dabei. Benötigt eine Operation in einem Slice das Ergebnis aus einem anderen Slice, gibt es eine kleine Verzögerung (result forwarding funktioniert wohl nur innerhalb eines Slices, nicht über alle hinweg, weil das vermutlich Unmengen an Strom saufen würde und/oder den Takt einschränken würde), was der Scheduler möglichst clever ausbügeln muß.
Im Prinzip ist es so eine Art Mittelding zwischen klassischem SMT und CMT. Oder falls man so will, ist es CMT wie es hätte sein sollen. :rolleyes:

Zossel

2024-09-18, 18:34:33

Beispiel: Lunar Lake bekommt zwar dieselben P/E Cores aber in der Stromsparausführung mit E Cores ohne L3 Zugang damit man P Cores inkl. Ring/L3 abschalten kann. Bei ARL ist es ein Compute Die und die E Cores haben L3 Zugriff und im Datacenterbereich kann man wieder etwas Anderes machen.

Statisches CMOS-RAM konnte schon in den 80'ern die Daten mit einer Knopfzelle jahrelang halten, das will man nicht abschalten.
Oder meinst du clockgaten?

Zossel

2024-09-18, 18:51:00

Da besteht jeder Core aus 4 Slices (bzw. sogar aus 4 Superslices zu je 2 Slices, also insgesamt 8 Slices), die unterschiedlich konfiguriert werden können.
Im einfachsten Fall besteht ein Kern aus 4 Slices mit jeweils eigenen Einheiten. Jeder diese 4 Slices kann quasi wie ein eigener (E-)Kern arbeiten (4 Threads). Es können aber auch nur 2 Threads auf jeweils 2 Slices laufen (M-Kern) oder im Extremfall kann ein einzelner Thread alle 4 Slices nutzen (P-Kern). Und es ist dynamisch im Betrieb umschaltbar (nur die Variante mit den 4 Superslices/8 Slices vs. 4 Slices pro Gesamtkern [Letzteres resultiert dann in doppelter Kernanzahl] legt IBM vor Auslieferung unveränderbar fest [ist aber der physisch identische Chip]).

Das könnte erklären warum die AIX-Menschen immer so ein Brimborium um die CPU-Zuweisungen an LPARs machen.

Hier steht etwas, aber leider nicht viel, dazu: https://www.redbooks.ibm.com/redpieces/pdfs/redp5684.pdf

HOT

2024-09-23, 16:23:49

https://videocardz.com/newz/intel-razer-lake-s-codename-leaked-potential-future-desktop-cpu-series
https://wccftech.com/intel-nova-lake-s-desktop-cpu-successor-might-be-called-razer-lake-s/

Und weiter konkretisiert sich die Zukunft.

ARL-S (2 Jahre) Produkt für 25 und 26, launch Ende 24
NVL-S Produkt für 27, launch Ende 26
Razer Lake S ziemlich sicher Produkt für 28 launch Ende 27

NVL-S und RZL-S sollen sich einen Sockel teilen, ich nehme an DDR5 + PCIE6.

y33H@

2024-09-23, 17:05:20

Gilette Lake danach?

Altehardware

2024-09-23, 17:13:18

Keller ging und das ganze Konzept wurde verworfen einzig arrow lake blieb über.
Der intel ceo will mehr e-corer und langfristig nur noch 2 p-cores
Also alle Namen nach luna arrow lake sind cancelt

mocad_tom

2024-09-23, 17:23:59

Achtung Oneraichu ist auf Twitter hinter einem Schloß.

>Oneraichu im Oktober 2023: rapnrt

Was so viel heißt wie (heute hat er es augelöst)

> R=Raptor
> A=Arrow
> P=Panther
> N=Nova
> R=Razer
> T=?

Also was ist der Projektname für T?

Ganz heiße Kandidaten:
Tomato Lake
Tucker Lake
Tuscarora Lake

HOT

2024-09-23, 17:38:05

Gilette Lake danach?
Wilkinson Lake wär doch cool :D.

Zossel

2024-09-23, 19:38:44

Wilkinson Lake wär doch cool :D.

Intel verwirrt sich doch nur selbst mit diesem Wirrwarr.

y33H@

2024-09-23, 20:20:35

Keller ging und das ganze Konzept wurde verworfen einzig arrow lake blieb über.
Der intel ceo will mehr e-corer und langfristig nur noch 2 p-cores
Also alle Namen nach luna arrow lake sind canceltMeine Ignore List und du habt großes Potenzial.

reaperrr

2024-09-23, 20:29:37

Cobra ist tot, nun steht Anaconda an ...
Intel will AMD jetzt also lieber erwürgen und verschlucken statt beißen und vergiften, interessant :D

mocad_tom

2024-09-25, 21:42:08

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

In
Panther Lake kommt Cougar Cove

In
Nova Lake kommt Panther Cove

In
Diamond Rapids kommt Panther Cove-X

ryan

2024-09-26, 00:59:06

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

In
Panther Lake kommt Cougar Cove

In
Nova Lake kommt Panther Cove

In
Diamond Rapids kommt Panther Cove-X

Coyote Cove kommt für Nova Lake: https://videocardz.com/newz/intel-nova-lake-with-coyote-cove-xeon-diamond-rapids-gets-panther-cove-x-cores

HOT

2024-09-26, 09:02:43

Sorung von Katzen zu Hundeartigen? Interessant.

y33H@

2024-09-26, 09:34:48

Vorher hatten wir Dinosaurier :freak:

Badesalz

2024-09-26, 11:35:26

Wobei schon recht irre was da in der Neuzeit für Brimborium aufgezogen wird.

Was kann man sich alles bei AMD merken? Oder, sollte? Zen und Zen-c. Sonst noch was? Ich weiß noch nichtmal wie 3/4 der bisherigen Cores heißen. Bei Intel ist das schon eine Art Gebetsmühle :conf: Soll das DIE Idee sein bei Thema publicity? :|

Wuge

2024-09-26, 12:01:02

Joa, durchnummerierung wäre schon cool...

1st Lake
2nd Lake
3rd Lake für die Chips

1st Cove
2nd Cove für die P Core Arch

1st Mont
2nd Mont für die E Core Arch

Und dann Produktschema Intel 2-1-2 900K

;DDD

Badesalz

2024-09-26, 12:03:48

Aha. Es gab nen Lake für die Chips. Chapeau.

y33H@

2024-09-26, 12:03:54

iamthebear

2024-09-27, 00:09:45

Statisches CMOS-RAM konnte schon in den 80'ern die Daten mit einer Knopfzelle jahrelang halten, das will man nicht abschalten.
Oder meinst du clockgaten?

Das Problem ist nicht der SRAM an sich sondern die Anbindung.
Wenn die CPU komplett schläft ist ja alles OK aber sobald ein E Core etwas zu tun hat taktet nicht nur dieser auf seinen jeweiligen Maximaltakt hoch sondern mit den ganzen Ring und die L3 Anbindung. Es werden zwar wenig Daten übertragen aber die Spannung und Takt alleine reichen schon aus damit der Leerlaufverbrauch in die Höhe geht was man besonders im Modern Standby nicht haben will.
Intels Ansatz: Die E Cores erst gar nicht mit dem L3 verbinden und den Maximaltakt reduzieren sodass diese nicht mit hohen Spannungen hochboosten.

Keller ging und das ganze Konzept wurde verworfen einzig arrow lake blieb über.
Der intel ceo will mehr e-corer und langfristig nur noch 2 p-cores
Also alle Namen nach luna arrow lake sind cancelt

Der Trend geht aktuell genau in die entgegengesetzte Richtung:
Aus 2P8E wurde 4P4E und die E Cores legen massiv an IPC zu und werden den P Cores immer ähnlicher.

Badesalz

2024-09-27, 09:31:15

Für mich ist P/E zusammen auf einem Sockel aus einer temporären Not entstanden und wird dann laaangsaaam wieder eingemottet.

aceCrasher

2024-09-27, 18:54:43

Für mich ist P/E zusammen auf einem Sockel aus einer temporären Not entstanden und wird dann laaangsaaam wieder eingemottet.
Die Frage ist wie der Hybrid-Ansatz eingemottet wird:
- Nur P-Kerne (finde ich persönlich sehr unwarscheinlich, dafür ist das P-Design einfach in jeder Hinsicht zu ineffizient)
- Nur E-Kerne, finde ich persönlich spannander. So weit sind die E-Kerne ja nicht mehr entfernt, wenn sie jetzt noch einen höheren Takt schaffen wären sie nicht so weit davon entfernt die P-Kerne ersetzen zu können.

...oder man bleibt beim Hybrid-Ansatz, es werden auf jeden Fall spannende Jahre :D

Badesalz

2024-09-27, 20:38:10

9700X hat keine c-Kerne und bringt das in 65W was man davor mit 100W brachte. Warum sollten P-Kerne zu ewiger ineffizienz verdammt werden? Wenn wer sagt, weil Intel sie macht, dann halt ich mich da lieber raus, aber es ist keine prinzipielle Sache.

Ggf. Economy für Mobiles und Thins, P für den Rest. Hybrid ist ziemlich uncool. Geht, wenn man wie Apple alles komplett alleine macht und es für Devs auch vernünftiges gibt. Wir reden aber von einem Markt mit 80% Mickeysoft drauf.

Entweder sie gehen wegen ihren Depots also weiter mit Intel ins Bett - Orchestrator + Win11 Kernel vs. Zen5/Zen6 - oder die Hybride sterben doch wieder aus.

Ja. Wirklich spannend :freak:

aceCrasher

2024-09-27, 20:58:31

9700X hat keine c-Kerne und bringt das in 65W was man davor mit 100W brachte. Warum sollten P-Keren zu ewiger ineffizienz verdammt werden? Wenn wer sagt, weil Intel sie macht, dann halt ich mich da lieber raus, aber es ist keine prinzipielle Sache.
Die Frage ist ja: was ist näher an den Zen-Kernen? Intels E-Core oder Intels P-Core? Ich würde ja sagen die E-Cores. Zen setzt eher auf smartes Design, bis einschließlich Zen 4 wurde das Core design nicht verbreitert. Die Philosophy der P-Kerne ist einfach massiv Transistoren in größere Caches, einen breiteren Kern, größere Buffer etc. zu investieren und sich die IPC mit "Masse" zu erkaufen. Sieht man doch wieder wunderbar bei Lion Cove: einfach alles massiv vergrößert.

Wenn Intel einen Kern der beides, IPC *und* Effizienz, kann anstrebt sollten sie eher vom E-Core Design ausgehen denke ich. Ich lasse mich aber auch kerne korrigieren wenn ich hier grob falsch liege.

Badesalz

2024-09-28, 09:07:40

Die Frage ist ja: was ist näher an den Zen-Kernen?Das wird sich genauer nach dem 10.10 einschätzen lassen.

PS:
Was Economy-Cores angeht: Ist zwar nicht Cobra, aber aktuell halt, das große E gegen das kleine c:

Luxx sieht sich in der Lage dicke Eisen testen zu können :rolleyes: DualSocket. Testen 8ch. Intel vs. 12Ch. Epycs. Nach dem Motto also, wer kann der kann.

1. PostgreSQL 16.
144 Kerne (6780E) kommen dabei auf 265W. Ein Epyc 9754 mit 128 4c Kernen, auf 280W (System)
Der Intel läuft - aus der Sicht eines RZ - auf sündhaft teuren DDR5-6400. Der Epyc mit DDR5-4800.
Der Epyc ist 37% schneller.

2. RocksDB 9.
Da lässt der 6780E es krachen. Knapp über 14% schneller. Mit 625W. Der 9754 ist da bei 550W...

3. Blender. Barber-Shop. (es wird auch mal durchgerechnet ;) )
Das Epyc-System direkt mit 615W zugange. 6780E mit 520W. Wow. Das ist ebenfalls signifikant weniger.
Der Epyc ist 52% schneller.

4. Im NAMD sind die E-Cores uneinholbar sparsam. 130W. 9754 mit 225W. Der Epyc ist 376% schneller. (es fehlt kein Punkt...)

Zossel

2024-09-28, 09:23:59

Die Frage ist wie der Hybrid-Ansatz eingemottet wird:
- Nur P-Kerne (finde ich persönlich sehr unwarscheinlich, dafür ist das P-Design einfach in jeder Hinsicht zu ineffizient)
- Nur E-Kerne, finde ich persönlich spannander. So weit sind die E-Kerne ja nicht mehr entfernt, wenn sie jetzt noch einen höheren Takt schaffen wären sie nicht so weit davon entfernt die P-Kerne ersetzen zu können.

...oder man bleibt beim Hybrid-Ansatz, es werden auf jeden Fall spannende Jahre :D

Hier wird an diesem fragwürdigen Ansatz, der lediglich für Medienabspieler wie Telefone taugt, weiter gefrickelt: https://www.phoronix.com/news/Intel-Core-Hybrid-Better-Virt

Badesalz

2024-09-28, 09:41:54

Luxx hat übrigens auch P-Cores nachgereicht (6972P). Nannten es in der Überschrift Intels Comeback.
Für mich sieht das außer bei deren OpenVINO nicht nach einem Comeback aus :freak:

ryan

2024-09-29, 16:58:33

GoldenCove/RaptorCove->RedwoodCove
LionCove->CougarCove
PantherCove is big uarch change with large IPC and APX/AVX10 and more

For Client the 'Lake' names correspond to SoC which is developed orthogonally.
The development cycle for Core and SoC doesn't match, SoC is shorter as result PantherLake SoC featuring non-PantherCove core. Yes, names are confusing :(
https://www.realworldtech.com/forum/?threadid=220199&curpostid=220205

Ich glaube ja, dass Panther Cove und Coyote Cove im Prinzip von der gleichen Architektur stammen. Eventuell mit ein paar Anpassungen speziell für Server, das ist immer möglich. Panther Cove wäre für Client nur verwirrend gewesen wegen Panther Lake, deswegen Coyote Cove für Nova Lake Client.

HOT

2024-09-29, 17:43:57

Ziemlich wahrscheinlich.

Zossel

2024-09-29, 18:47:47

Diese Codenamen haben in der Öffentlichkeit auch eigentlich nix verloren bzw einzig bei der Die Hard Tech Presse - ich für meinen Teile kenne sie für AMD und Intel und weitestgehend auch Qualcomm, einfach weil es präziser ist als die (späteren) Produktnamen.

Als wenn dieser Affentanz den die Hersteller um ihre neuen Produkte aufführen auch nur den Hauch von einem Mehrwert hätte.

Besonders bekloppt ist das bei Autos wo es schon seit Jahrzehnten keine Innovationen mehr gibt.

Platos

2024-09-29, 19:00:01

Gibt doch jedes Jahr ein noch grösseres Display mit Schrott-Navi :D

y33H@

2024-09-29, 21:17:03

Als wenn dieser Affentanz den die Hersteller um ihre neuen Produkte aufführen auch nur den Hauch von einem Mehrwert hätte. Besonders bekloppt ist das bei Autos wo es schon seit Jahrzehnten keine Innovationen mehr gibt.
Was hat dein Post mit dem meinigen zu tun?

ryan

2024-09-30, 21:05:28

Cobra Core wäre wohl Royal v2 geworden, aus den üblichen Quellen kann man das erfahren. Royal ist aber komplett gestrichen, beides kann man aus dem Threadtitel entfernen. Gerüchten zufolge will Intel P+E zusammenlegen, eine vereinte Architektur entwickeln. Sieht eher nach Atom als Grundlage aus. Wäre aber erst was nach Nova Lake, frühestens Razer Lake oder erst Titan Lake. Nova Lake bekommt noch klassisch zwei getrennte Architekturen mit Coyote Cove und Artic Wolf.

Intel has recently begun work on a “unified core” to essentially merge both P and E cores together. Stephen Robinson, the Atom lead, is apparently leading the effort, so the core has a good chance to be based on Atom’s foundation.
https://www.reddit.com/r/Amd/comments/1fqqyg1/comment/lpen9s1/

The decision on what UC is has not been made (or if it has, I haven't heard of it), but the decision that there will only be one core has been, at least nominally. Sounds like all the Atom folk are full-time on UC definition at this point.

I’ve heard rumors that Atom was chosen for UC, I’m just trying to figure out if they had any merit to them. I guess we’ll have to wait and see then.

The Atom folk seem to at least be leading the practical effort. From what I heard, sounds like big core's plan B might just be to ignore it in the hope it goes away. Though I wouldn't yet bet against UC being a big core derivative.
https://www.reddit.com/r/hardware/comments/1fmh2vw/comment/log9gmr/

Undertaker

2024-09-30, 21:33:24

So richtig vorstellen kann ich mir das noch nicht, dafür sind die Anforderungen und Optimierungsziele (ST-Performance, MT-Performance, Energieeffizienz, Flächeneffizienz, Taktbarkeit, ...) mMn einfach zu breit gefächert und bei der Architekturauslegung auch schlicht zu gegensätzlich. Und mittlerweile klappt es ja auch mit dem Scheduling unterschiedlicher Kerne prinzipiell ganz gut.

Was allerdings mMn vorstellbar wäre: Die Kerne bauen nicht mehr auf gänzlich unterschiedlichen Architekturen auf, sondern werden relativ "spät" im Designprozess ohne allzu invasiven Eingriff in das Grunddesign an den Einsatzzweck als P- oder E-Core angepasst. Das bietet zwar nicht ganz die gleiche Bandbreite an Skalierbarkeit bzgl. der jeweiligen Optimierungsziele, aber spart dafür Entwicklungskosten und Zeit. Und viele Errungenschaften der Weiterentwicklung und Innovationen im Kerndesign lohnen sich ja ohnehin für P- und E-Cores gleichermaßen.

ryan

2024-09-30, 22:32:19

So richtig vorstellen kann ich mir das noch nicht, dafür sind die Anforderungen und Optimierungsziele (ST-Performance, MT-Performance, Energieeffizienz, Flächeneffizienz, Taktbarkeit, ...) mMn einfach zu breit gefächert und bei der Architekturauslegung auch schlicht zu gegensätzlich. Und mittlerweile klappt es ja auch mit dem Scheduling unterschiedlicher Kerne prinzipiell ganz gut.

Macht nur kein Sinn, wenn die großen Kerne langsamer sind als die kleinen. In zwei Generationen wäre es soweit, wenn sich der Trend fortsetzt.

Was bleibt noch übrig für die großen Kerne? Taktvorsprung wurde stetig kleiner, bei ARL-S liegt max ca 1 Ghz dazwischen. Mit jeder Generation konnten die Mont höher takten.

Leistung pro Takt Vorteil könnte schon bei Nova Lake aufgebraucht sein. Atom entwickelt sich viel besser und es gibt viel größeren Spielraum, weil die Kerne viel kleiner sind. Langfristig zu wenig, was Intel Israel mit den größeren Kernen macht.

Pirx

2024-10-01, 06:15:28

Unwahrscheinlich daß es so kommt, wäre extrem schlechtes Design

Zossel

2024-10-01, 07:15:30

Unwahrscheinlich daß es so kommt, wäre extrem schlechtes Design

Sind die "C-Cores" von AMD "extrem schlechtes" Design?

Hier die Infos zu den "C-Cores" von AMD: https://www.semianalysis.com/p/zen-4c-amds-response-to-hyperscale

Pirx

2024-10-01, 07:17:59

"wenn die großen Kerne langsamer sind, als die kleinen" meinte ich

Gipsel

2024-10-01, 15:52:06

Undertaker

2024-10-01, 16:32:33

Macht nur kein Sinn, wenn die großen Kerne langsamer sind als die kleinen. In zwei Generationen wäre es soweit, wenn sich der Trend fortsetzt.

Was bleibt noch übrig für die großen Kerne? Taktvorsprung wurde stetig kleiner, bei ARL-S liegt max ca 1 Ghz dazwischen. Mit jeder Generation konnten die Mont höher takten.

Leistung pro Takt Vorteil könnte schon bei Nova Lake aufgebraucht sein. Atom entwickelt sich viel besser und es gibt viel größeren Spielraum, weil die Kerne viel kleiner sind. Langfristig zu wenig, was Intel Israel mit den größeren Kernen macht.

Wobei das ein rein spezifisches Thema der konkreten Implementierung ist, als dem eigentlichen Grundsatz zu widersprechen. Ein einzelnes Kerndesign wird nie in allen genannten Disziplinen und Arbeitspunkten "optimal" sein, da sich die Optimierungsziele wie gesagt teilweise entgegenstehen.

Denke einfach an Zen5. Ein einziges Kerndesign mit einer Konfigurationsoption (512bit oder 256bit Vektoreinheiten), was es in jeweils 2 physischen Designs gibt: Eines auf hohen Maximaltakt optimiert, das andere auf hohe Dichte und etwas mehr Energieeffizienz mit einem niedrigeren Maximaltakt ausgelegt. Warum sollte intel das nicht auch so machen können?

Ich sehe hier eine faktisch unbegrenzte Bandbreite der Möglichkeiten von gänzlich unterschiedlichen Designs bis hin zu marginalen Anpassungen bei Packdichte oder Cachegrößen. Am Ende ist auch das wieder eine Abwägung bzw. Zieloptierung zwischen Aufwand/Kosten (= möglichst minimale Unterschiede) und maximalem Benefit für das spätere Gesamtdesign (= bestmögliche Optimierung beider Kerndesigns für ihren jeweiligen Arbeitspunkt).

Wuge

2024-10-01, 16:58:08

Im Sinne des internen Wettbewerbs kann es schon auch sinnvoll sein, verschiedene Teams an verschiedenen Core Designs arbeiten zu lassen. Überlegene Konzepte übernimmt man ins konkurrierende Design und umgekehrt, auch wenn die Betriebspunkte anders liegen.

HOT

2024-10-01, 17:21:19

Zossel

2024-10-01, 17:54:51

Ich sehe hier eine faktisch unbegrenzte Bandbreite der Möglichkeiten von gänzlich unterschiedlichen Designs bis hin zu marginalen Anpassungen bei Packdichte oder Cachegrößen. Am Ende ist auch das wieder eine Abwägung bzw. Zieloptierung zwischen Aufwand/Kosten (= möglichst minimale Unterschiede) und maximalem Benefit für das spätere Gesamtdesign (= bestmögliche Optimierung beider Kerndesigns für ihren jeweiligen Arbeitspunkt).

Siehst du auch die Kunden die das bezahlen wollen?
Siehst du auch die Shareholder die auf Profite verzichten wollen?

Und ohne /dev/glaskugel wird sich ein Scheduler immer mit sehr unterschiedlichen Cores schwer tun.

Undertaker

2024-10-01, 18:26:29

Das kann man aber auch tun, wenn man nur eine Basis nutzt. Und ich stimme ryan da uneingeschränkt zu, es ist sehr sinnvoll in Zukunft alles auf die effizientere Basisachitektur aufzubauen und im Wettbewerb lässt man ja auch die ineffizientere Architektur fallen.

Wobei man "Effizienz" immer als Funktion des Arbeitspunktes sehen muss, auch Skymont ist am obersten Ende seines Leistungsspektrums weniger effizient als Lion Cove am untersten. Dennoch kann es natürlich Sinn machen, eine Architektur aufgrund mangelnder Entwicklungsperspektive irgendwann ad acta zu legen und mehr Potential in einem anderen Design, beispielsweise dem der aktuellen E-Cores zu sehen. Nur, was dann? mMn wird das nur der Ausgangspunkt für einen neuen Branch sein, wo abgeleitet von dieser Architektur wiederum entsprechend optimierte Derivate mit spezifischen Anpassungen für einen P- oder E-Core Einsatz entstehen. Was ich nicht glaube ist, dass man wieder zum "alten" Ansatz eines komplett homogenen Chipaufbaus mit exakt identischen Kernen geht, jedenfalls nicht im Mobile-Segment mit hohen Anforderungen an Performance und Akkulaufzeit gleichermaßen. In einem Server-Umfeld mit relativ statischem Workload mag das eher gehen.

Siehst du auch die Kunden die das bezahlen wollen?
Siehst du auch die Shareholder die auf Profite verzichten wollen?

Und ohne /dev/glaskugel wird sich ein Scheduler immer mit sehr unterschiedlichen Cores schwer tun.

Vergiss nicht die Vorteile eines heterogenen Core-Designs: Flächenoptimierte E-Cores können dir die gleiche MT-Performance auch bei geringerem Transistor- und Flächeneinsatz ermöglichen, ohne dafür bei der ebenfalls wichtigen ST-Performance Kompromisse (= und damit niedrigere Verkaufspreise) einzugehen. Insofern, wer sagt das dafür zwangsläufig Profite verloren gehen? Und das das Scheduling funktionieren kann, beweisen nicht nur sämtliche ARM-Geräte seit Jahren, sondern letztlich auch x86 seit den ersten Multi-Core CPUs mit SMT.
Das man natürlich trotzdem den Aufwand für die individuellen Anpassungen der P- und E-Cores sinnig abwägen muss, habe ich ja zuvor schon geschrieben.

Badesalz

2024-10-01, 18:58:51

Um Sinnhaftigkeiten enger einzukriesen müsste man sich mit paar Leuten aus den RZs unterhalten und das nicht alleine aus der Sicht des Chipherstellers sehen.

RZs denken sich auch etwas auch und drängen auf entsprechende Lösungen. Die schauen nicht nur zum Himmel ob und was man denen presentiert.
Sie sehen für sich ein Problem und stellen Anfragen ob man das auf die Art lösen könnte wie es denen am sinnvollsten vorkommt.

Das ist nicht so wie bei Autos, wo 3 von 4 Leuten die elektrische Feststellbremse nicht leiden können, aber die Autohersteller das einfach großflächig einführen. Bei 20 solchen Sachen im Auto sieht dann der Automarkt plötzlich eben wie es aussieht. Die IT-Hersteller sind da nicht dermassen oberdämlich. Es findet fortlaufend ein Austausch und eine Diskussion was die zukünftigen Wege angeht.

Vergiss nicht die Vorteile eines heterogenen Core-Designs: Flächenoptimierte E-Cores können dir die gleiche MT-Performance auch bei geringerem Transistor- und Flächeneinsatz ermöglichen, ohne dafür bei der ebenfalls wichtigen ST-Performance Kompromisse (= und damit niedrigere Verkaufspreise) einzugehen.Hä? HÄ? Die Idee gefällt mir zwar, aber ohne die einen und auch ohne der anderen Kompromisse, sind das keine E-Cores mehr, sondern nextgen P-Cores :usweet:

Undertaker

2024-10-01, 19:17:55

Hä? HÄ? Die Idee gefällt mir zwar, aber ohne Kompromisse in ST sind das keine E-Cores mehr, sondern nextgen P-Cores :usweet:

Ich glaube da liegt ein Missverständnis vor: Ich sprach von einem bzgl. CPU-Architektur heterogenen Chip, wo die E-Cores für Flächeneffizienz und MT-Performance und die P-Cores für ST-Performance sorgen. Ein alternativer Chip mit homogenem Ansatz wird in mindestens einer Disziplin konzeptionell im Nachteil sein, was wiederum geringere Verkaufspreise nach sich zieht und damit der These, dass der heterogene Ansatz aus öknomischer Sicht zwangsläufig im Nachteil sei, widerspricht.

fondness

2024-10-01, 19:49:53

Gerüchten zufolge will Intel P+E zusammenlegen, eine vereinte Architektur entwickeln. Sieht eher nach Atom als Grundlage aus. Wäre aber erst was nach Nova Lake, frühestens Razer Lake oder erst Titan Lake. Nova Lake bekommt noch klassisch zwei getrennte Architekturen mit Coyote Cove und Artic Wolf.

https://www.reddit.com/r/Amd/comments/1fqqyg1/comment/lpen9s1/

https://www.reddit.com/r/hardware/comments/1fmh2vw/comment/log9gmr/

Überrascht mich nicht, habe ich hier schon vor Monaten spekuliert ;-). Intel sieht halt auch, dass die eventuellen Vorteile vs. AMD in keinem Verhältnis zum Aufwand stehen parallel 2 Architekturen zu entwickeln. Zumal die E-Cores sehr gut aussehen vs den big cores.

Badesalz

2024-10-01, 20:16:47

@Undertaker
Tatsächlich hab ich das nicht in dieser Tiefe nachvolzihene können. Danke ;)

Das mit dem Ansatz und der ökonomischen Sicht, ist relativ einfach. Jedenfalls außerhalb der Consumer-Welt: Die RZs möchten NICHT diesbezüglich hybride Lösungen. Das ist alles. Sie können damit WOHL keine stabile Leistungsfähigkeit schätzen. Die Planer lehnen das daher einfach ab.

Das ist kein Schuh für Intel. Scheint VORERST prinzipiell. Das wird auch der Grund sein warum AMD damit auch erst garnicht angefangen hat und Intel das bisher als Xeon auch nicht anbietet.
Wenn man hier trickst, verkauft man nicht.

Was die Leistungsfähigkeit der jeweiligen Cores angeht, bin ich von den Voraussetzungen kleinwenig überrascht. Mir ist da als Review der aktuellen Neuware bisher nur das untergekommen und das war halt wie es war :|
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13621885#post13621885

Als nicht grad der waschechte Insider verliere ich zuweilen die Übersicht, ab wann man hier über wenigstens halbwegs reales Zeug redet und ab wann über Intels Folien (Kopfkratz). Die oft in den ..ähh.. Aussagen, steckende Omnipotenz macht die Unterscheidung nicht grad einfach.
Ihr versteht...

PS:
Den Verbrauch bei Stream mochte der Autor bisher imho irgendwie nicht nachreichen :uup:

Zossel

2024-10-01, 20:24:37

Ich glaube da liegt ein Missverständnis vor: Ich sprach von einem bzgl. CPU-Architektur heterogenen Chip, wo die E-Cores für Flächeneffizienz und MT-Performance und die P-Cores für ST-Performance sorgen. Ein alternativer Chip mit homogenem Ansatz wird in mindestens einer Disziplin konzeptionell im Nachteil sein, was wiederum geringere Verkaufspreise nach sich zieht und damit der These, dass der heterogene Ansatz aus öknomischer Sicht zwangsläufig im Nachteil sei, widerspricht.

Gerade auf Servern ist das Scheduling mit gemischten Cores schwierig bis umöglich wenn man halbwegs predictable und konsistente Performance in diesen ganzen lustigen aufeinander gestapelten Middleware Zoos haben will oder braucht. Und gerne sind die Anwendungen einfach schlecht und reagieren überproportional auf Latenzen und ST-Performance (teilweise auch nur in bestimmten Szenarien) weil es keinen Business-Case für eine Anpassung gibt bzw. die Business-Logik-Mausklicker das Problem nicht im Ansatz verstehen. Das will man auch deswegen nicht weil das Troubleshooten dadurch um einiges komplexer wird und Ausfälle sich dadurch eher verlängern. Da hast du ruckzuck ein vielfaches an Kosten die als man durch so einen Ansatz einspart.
Nichts ist widerlicher als eine Umgebung die erratische Performanceprobleme wirft und der Schlüpper vom Kunden immer feuchter wird weil seine Leute nicht arbeiten können oder seine Produktionsmittel rottig laufen.

Und es steht dir komplett frei einen Scheduler zu schreiben der so einen Kram vernünftig ansteuern kann, den das ist das Problem was als erstes zu lösen wäre bevor man weitermacht.

Das eben ist kein Telefon wo jedes gammelige Billigphone ein vielfaches an Cores hat als der User jemals brauchen wird und das OS sobald der Bildschirm aus ist sämtlichen Kram auf die Low-Cores werfen kann.

Zossel

2024-10-01, 20:40:07

Das ist kein Schuh für Intel. Scheint VORERST prinzipiell. Das wird auch der Grund sein warum AMD damit auch erst garnicht angefangen hat und Intel das bisher als Xeon auch nicht anbietet.

Das ist auch kein HW-Problem sondern ein SW-Problem.
Möglicherweise braucht es auch nur einen Stift und ein Blatt Papier um das zu lösen.
Viel Glück dabei, ein Turing-Award oder eine Fields-Medaille sollte dafür drin sein.

Undertaker

2024-10-01, 21:20:13

Lies, was ich in #54 zum Server-Umfeld mit statischem Workload geschrieben habe. Wobei ich persönlich eher den oftmals fehlenden Benefit eines heterogenen Ansatzes, der in erster Linie für eine (hier idR nicht erforderliche) Spreizung des optimalen Betriebsbereiches in die Breite sorgt, als größtes Hindernis für einen Einsatz in diesem Marktsegment sehe.
Im Mobile- und Desktopsegment dagegen, wovon ich die ganze Zeit spreche, sind die P- und E-Cores gekommen und zu bleiben. :wink: Wie artverwandt oder unterschiedlich selbige jedoch in Ihrer Architektur ausfallen und ob ggf. künftig beide von der gleichen Basis abgebrancht werden, mag sich durchaus wandeln. :)

Badesalz

2024-10-02, 06:33:46

Find ich auch. Nichts genaues weiß man nicht =)

Sobald man aber öfters ordentliche Lasten erzeugt stört das anscheinend auch im häuslichen Umfeld. Davon, daß die Gamer die E-Cores auch mal abschalten, das ist schon ne ganze Weile her, daß ich sowas das erste Mal gehört habe.

Zossel

2024-10-02, 06:55:12

Lies, was ich in #54 zum Server-Umfeld mit statischem Workload geschrieben habe.

Was ist ein "statischer Workload"?

Badesalz

2024-10-02, 06:59:17

Ich schätze eine anhaltende, konstante und auch recht hohe Last ;) Einerseits. Andererseits sich in seiner sonstigen Art auch wenig verändernd.

Zossel

2024-10-02, 08:21:24

Ich schätze eine anhaltende, konstante und auch recht hohe Last ;) Einerseits. Andererseits sich in seiner sonstigen Art auch wenig verändernd.

Also HPC/AI-Gedöns (Jobs batchen), und kein Enterprise-Kram?

Badesalz

2024-10-02, 08:27:08

Ich verstehe es ;) aber normalerweise kauft man auch für Datenschieberei eher so ein, daß die Kisten die meisten der 24h gut etwas zu tun haben. Auch da ist der Workload aus der Sicht des Systems eher weniger manigfaltig...

ryan

2024-10-03, 01:40:56

Unwahrscheinlich daß es so kommt, wäre extrem schlechtes Design

Die großen Kerne sind heute schon schlechtes Design. Obwohl Skymont so stark zulegt, ist das immer noch ein 1:3 Verhältnis zu Lion Cove. Da scheint es mehr Sinn zu machen, die Mont aufzubohren.

Skymont: 1.15mm²/1.75mm² mit L2
Lion Cove: 3.43mm²/4.67mm² mit L2

//differentRob

2024-10-03, 07:16:11

Altehardware

2024-10-03, 09:04:09

Dann viel spaß beim portieren der software
ne neue arch design von Grund auf kann keiner durchsetzen das hat intel schonmal versucht 2004 mit eine reinen 64bit cpu und ist gescheitert weil es keine software gab die darauf lief.
Und emulation was einige in den Sinn kommt ist keine Lösung da es oft Probleme mit den Programmiersprachen gibt.
X86-64 (48bit) wird also sehr bald nicht ersetzt werden können außer man schreibt jede software neu
Also wozu dann die cpu in nativen 64bit bauen das bringt nix intel hatte ein team mit ner Idee wie man mehr ipc erreichen kann und wurde vom ceo gefeuert und verworfen da man auf massiv viele thread gehen will da die singlecore Leistung ja reicht.
Das zeigt das intel von egos und kurzsichtigen bw'lern (neoliberal) geleitet wird
Dieser ceo wird aber bald ersetzt werden wenn intel arrow lake kein Erfolg wird und das wird passieren den die Aussicht ist trübe.

Zossel

2024-10-03, 11:39:16

X86-64 (48bit) wird also sehr bald nicht ersetzt werden können außer man schreibt jede software neu

48 Bit?

mboeller

2024-10-03, 11:55:39

48 Bit?

Schulter zuck. Vielleicht ja das hier:
https://stackoverflow.com/questions/6716946/why-do-x86-64-systems-have-only-a-48-bit-virtual-address-space

Altehardware

2024-10-03, 11:56:23

Das liegt an windows da amd x86-64 bit anstatt 64bit windows nur bis 48bit Adressieren kann
Physisch können 64bit cpu auch 64bit abarbeiten bringt aber nix wenn die software das nicht nutzen kann.
Der Grund ist Abwärtskompatibilität den ein reiner 64bit cpu und os muss die software neu geschrieben werden inklusive api's und Programmiersprachen
x86 müsste emuliert werden inklusive api's Programmiersprachen

Für ein Neuanfang wo keine alte software genutzt wird passt dass das aber wird sich nicht durchsetzen.

Zossel

2024-10-03, 13:29:06

Das liegt an windows da amd x86-64 bit anstatt 64bit windows nur bis 48bit Adressieren kann
Seit wann definiert Windows die möglichen Eigenschaften einer CPU?

Woanders ist das schon seit 2017 Geschichte: https://github.com/facebook/folly/issues/712
Für ein Neuanfang wo keine alte software genutzt wird passt dass das aber wird sich nicht durchsetzen.
Schreibst du deine Software so das die nicht funktioniert wenn bestimmte Bits in den Pointern gesetzt sind die du von malloc(3) zurück bekommst?
Falls ja, lass bitte in Zukunft deine Finger von Compilern und Editoren.

ryan

2024-10-03, 18:52:07

Also, dass Intel P/E Cores wieder aufgibt, klingt für mich nicht sonderlich abenteuerlich. Immerhin werkelt Intel doch ohnehin an einer x86S Architektur welche den kompletten alten x86 legacy shit rauskickt.

Dazu kommt noch AVX10 und APX als neue Befehlsatzerweiterung.

x86s wäre mit Royal Core gekommen (angeblich). Das ist aber jetzt Geschichte einschließlich x86s. APX soll mit Panther Cove kommen, hatte ich glaube schon verlinkt.

PantherCove is big uarch change with large IPC and APX/AVX10 and more
https://www.realworldtech.com/forum/?threadid=220199&curpostid=220205

Panther Cove und Coyote Cove ist die gleiche Architektur. Für Client Nova Lake wird es Coyote Cove.

Panther Lake uses the Cougar Cove P core and the Darkmont E core.

Nova Lake uses the Panther Cove/Coyote Cove P core (same core, “Coyote Cove” is just a marketing name to reduce confusion with Panther Lake), and the Arctic Wolf E core.

Diamond Rapids uses Panther Cove.
https://www.reddit.com/r/hardware/comments/1ftrkvq/comment/lpulc5f/

AVX512 soll übrigens in Nova Lake zurückkommen mit AVX10.2. Demnach müssten die E-Kerne erstmalig AVX-512 unterstützen.

And as for AVX-512, that’s coming back to client (in the form of AVX 10.2) with Nova Lake in 2026.
https://www.reddit.com/r/hardware/comments/1ej151l/comment/lgdjtb6/

PTL should have AVX 10.1, but that does not include 512-bit support. NVL gets AVX 10.2, which has full 512-bit support.
https://www.reddit.com/r/intel/comments/1evbrz4/comment/lis5sn3/

//differentRob

2024-10-03, 19:57:35

mczak

2024-10-04, 07:50:39

AVX512 soll übrigens in Nova Lake zurückkommen mit AVX10.2. Demnach müssten die E-Kerne erstmalig AVX-512 unterstützen.

Auch bei AVX 10.2 ist 512 bit Unterstützung optional, und nach dem was in der Spezifikation steht ist nicht zu erwarten dass AVX 10.2-512 auf dem Desktop so bald kommt.

HOT

2024-10-04, 09:07:27

@ryan
Aber Intel hat doch gerade erst Revision 1.2 von x86s veröffentlicht. Generell stelle ich mir gerade die Frage warum das mit RoyalCore in Verbindung gebracht wird.

Mir erscheint x86s als sehr sinnvoll.

Das ist absoluter Quatsch und dient Intel nur um das eigene geistige Eigentum zu sichern. Das wird eh nichts. Rein Objektiv betrachtet hat S nur Nachteile.

Badesalz

2024-10-04, 10:39:45

Mir erscheint x86s als sehr sinnvoll.Schonmal irgendwo was mitbekommen was das an Fläche spart, was an Watt und was es an Leistung bringt?

Exxtreme

2024-10-04, 11:02:01

Auch bei AVX 10.2 ist 512 bit Unterstützung optional, und nach dem was in der Spezifikation steht ist nicht zu erwarten dass AVX 10.2-512 auf dem Desktop so bald kommt.

AFAIR sind bei AVX10.2 die 512-Bit-Register optional. Aber trotzdem kann man alle AVX512-Anweisungen damit ausführen. Bei nicht vorhandenen 512-Bit-Registern muss dann emuliert werden was Performance kostet.

mczak

2024-10-04, 12:35:10

AFAIR sind bei AVX10.2 die 512-Bit-Register optional. Aber trotzdem kann man alle AVX512-Anweisungen damit ausführen. Bei nicht vorhandenen 512-Bit-Registern muss dann emuliert werden was Performance kostet.
Nein da wird nichts emuliert., das geht klar aus der Spezifikation hervor. Da steht z.B. "A “converged” version of Intel AVX10 with vector lengths of at least 256 bits will be supported across all Intel processors." Und in der Tabelle steht klar bei "AVX10.2/256" kein "512-bit vector (ZMM) register support".
Dass da alle AVX512-Befehle ausgeführt werden können bezieht sich allein auf die Befehle an sich, nicht die Vektorlänge (weil ja eben AVX512 beim alten Namensschema nicht nur die Vektorlänge bezeichnet sondern auch das neue EVEX-Encoding).

//differentRob

2024-10-04, 13:02:02

Das ist absoluter Quatsch und dient Intel nur um das eigene geistige Eigentum zu sichern. Das wird eh nichts. Rein Objektiv betrachtet hat S nur Nachteile.

Nachteile die keine wirklich sind oder? Wer lässt heute noch 16bit laufen und braucht dazu ein zeitgemässes System? :freak: Und ausserhalb von Windows Universe, dachte ich immer Dev's sind so r00t :cool:

Bevor wir das als Quatsch abtun, sollten wir den Nutzen abgesteckt haben. Aber ja, kann sein, dass Intel hier komplett Ressourcen verballert :cool:

Schonmal irgendwo was mitbekommen was das an Fläche spart, was an Watt und was es an Leistung bringt?

Die Einsparung an DIE-Size dürfe wohl verschwindend gering sein. Die Frage stellt sich halt, ob es dadurch auch Änderungen am restlichen Design zulässt.

aber da bin ich völlig der Falsche um das einzuschätzen ;-)

HOT

2024-10-04, 13:06:04

Nachteile die keine wirklich sind oder? Wer lässt heute noch 16bit laufen und braucht dazu ein zeitgemässes System? :freak: Und ausserhalb von Windows Universe, dachte ich immer Dev's sind so r00t :cool:

Bevor wir das als Quatsch abtun, sollten wir den Nutzen abgesteckt haben. Aber ja, kann sein, dass Intel hier komplett Ressourcen verballert :cool:

Nenn mir nur einen Vorteil. Ressourcen sparst du damit nämlich nicht, das ist ne glatte Fehlannahme. Das ist nur ein anderer Befehlssatz, also Firmware. 16Bit ist mit X64 schon legacy, können die CPUs nur noch im reinen IA32-Mode. Versuch mal ein 16Bit Programm auf Windows 11 zu starten.

X86S soll nichts weiter tun als X86 für Intel weitere 30 Jahre zu sichern. Alle außer AMD wären damit wieder außen vor, falls der Markt das annehmen würde, tolle Situation für Intel.
Das hat keinerlei technischen Nutzen, das ist einfach nicht korrekt gedacht. Das ist vergleichbar mit dem IA64-Luftschloss.

Badesalz

2024-10-04, 13:08:48

Die Einsparung an DIE-Size dürfe wohl verschwindend gering sein. Die Frage stellt sich halt, ob es dadurch auch Änderungen am restlichen Design zulässt.

aber da bin ich völlig der Falsche um das einzuschätzen ;-)Ja. Ok. Damit aber auch der Falsche um es zu besingen oder?

@all
Ich gebe zu, daß mich das ankotzt. Nachdem wir verschiedenste, bekloppteste SSE-Versionen hatten in dem Intel eine langsam Portionierung der ISA-Erweiterungen als immer mal neue µArch-Advantages zelebrierte, versuchen sie das jetzt auch wieder mit AVX. Die meinen irgendwie die Kundschaft ist einfach nur blöd oder? WAS FÜR EINE ROTZE! :mad:

Wie stellen sie sich diesen Mist diesmal vor? Wie davor? Das gleiche Theater wie davor wo die Entwickler nicht wussten wo sie damit anfangen und wo sie aufhören sollen?
Das ist als wenn (nur ein Beispiel) NV andauernd irgendwelche DX12- oder Vulkan-Erweiterungen in ihre Treiber hinfrimmeln würde. Wer will sowas mitmachen? Das VERLANGSAMT die Verbreitung + Nutzung. Wäre übrigens interessant zu sehen wie DAS Intel schmecken würde :mad:

Jetzt wissen sie nicht mehr wie sie AMD schlagen sollen und fangen wie davor schon wieder mit dem SIMD-Theatre. Nach ein paar Jahren wieder einen halben Sack CPUs wo man wieder ganz genau schauen muss wo die Schnittmengen sind.

AVX 10.x... Das ist echt so ein Müllhaufen geworden :uconf3:

Zossel

2024-10-04, 15:44:44

Seit wann definiert Windows die möglichen Eigenschaften einer CPU?

Woanders ist das schon seit 2017 Geschichte: https://github.com/facebook/folly/issues/712

Schreibst du deine Software so das die nicht funktioniert wenn bestimmte Bits in den Pointern gesetzt sind die du von malloc(3) zurück bekommst?
Falls ja, lass bitte in Zukunft deine Finger von Compilern und Editoren.

Ich wollte mal schauen wie weit man ootb unter Linux kommt: (Wie weit gehen andere OS?)

~$ cat t1.c
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

void err_exit(char *s) {
perror(s);
exit (1);
}

int main() {
int f, i;
long ret;
unsigned long size = 1;
unsigned char *data;

for (i = 1; i <= 20; i++) { size <<= 1; printf("%5d %ld\n", i, size); }

f = open("/mnt/xfs/foo", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if (f == -1) { err_exit("open failed"); }

while (1) {
ret = (long) lseek(f, (off_t)size, SEEK_SET);
if (ret == -1) { err_exit("lseek failed"); }

ret = (long) write(f, &f, 4);
if (ret == -1) { err_exit("write failed"); }

data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, f, 0);
if (data == MAP_FAILED) { err_exit("mmap failed"); }

printf("%5d %ld\n", i, size);
size <<= 1; i++;
}
puts ("Never reached :-)");
}
~$ make t1
cc t1.c -o t1
~$ ./t1
1 2
2 4
3 8
4 16
5 32
6 64
7 128
8 256
9 512
10 1024
11 2048
12 4096
13 8192
14 16384
15 32768
16 65536
17 131072
18 262144
19 524288
20 1048576
21 1048576
22 2097152
23 4194304
24 8388608
25 16777216
26 33554432
27 67108864
28 134217728
29 268435456
30 536870912
31 1073741824
32 2147483648
33 4294967296
34 8589934592
35 17179869184
36 34359738368
37 68719476736
38 137438953472
39 274877906944
40 549755813888
41 1099511627776
42 2199023255552
43 4398046511104
44 8796093022208
45 17592186044416
46 35184372088832
mmap failed: Cannot allocate memory
~$ ls -lh /mnt/xfs/foo
-rw------- 1 xxx xxx 65T Oct 4 15:37 /mnt/xfs/foo
~$

//differentRob

2024-10-04, 16:09:42

Ressourcen sparst du damit nämlich nicht, das ist ne glatte Fehlannahme. Das ist nur ein anderer Befehlssatz, also Firmware. 16Bit ist mit X64 schon legacy, können die CPUs nur noch im reinen IA32-Mode. Versuch mal ein 16Bit Programm auf Windows 11 zu starten.

Da hast du mich falsch verstanden, das mit den Ressourcen war auf das entwickeln von x86s bezogen. Für mich stellt sich aber noch die Frage ob mit x86s AMD tatsächlich out of business wäre. Aber falls ja, dann wird das ziemlich sicher ein Rohrkrepierer.

@badesalz
völlig d'accord, warf das nur ein, da mir das als technikinteressierter Typ sinnvoll erschien, wenn man Transistoren einsparen könnte und design effizienter gestalten könnte? Da ich weder Software- noch Hardwareentwickler bin, kann ich nicht abschätzen ob's da bei Designs Gewinne gäbe oder nicht.

Mich nahm daher wunder was ihr hier dazu meint. Aber bisher bekam ich auch keine begründete Antwort warum das technischer Mumpitz sein soll. Vom ganzen IP gedöns mal aussen vor.

Badesalz

2024-10-05, 12:33:39

Aber bisher bekam ich auch keine begründete Antwort warum das technischer Mumpitz sein soll. Vom ganzen IP gedöns mal aussen vor.Technischer nicht-Mumpitz was auch was bringt steht da drunter auf VC. 20 bis 28% mehr Leistung bei max. 105W TDP in einer Anwendung wo der zusätzliche Cache eher bisschen ausbremst
https://videocardz.com/newz/alleged-ryzen-9000x3d-cinebench-r23-scores-emerge-10-to-28-faster-than-7000x3d

Ja, kleinwenig OT, aber an der Stelle könnte man auch bemerken warum sich viele andere mit all dem untechnischen PR-Kokolores wenig beschäftigen.
Das Chaos des Nebels was sie immer zu veranstalten versuchen, wenn sie nicht mehr wissen wie sie sich sonst zur Schau stellen können NERVT NUR NOCH :mad: Das ist nicht nur AVX 10.x :crazy2:

Sie haben noch nichtmal einen alpha Prototypen ("Technologiestudie") gezeigt mit welchem sie die Vorteile von X86s wenigstens grob presentieren können, aber die Spezifikation dazu hat schon >1.x :freak: Das können sie mehrfach ausdrucken und in Santa Clara in den Shicehauskabinen verteilen.

HOT

2024-10-05, 13:40:38

Da hast du mich falsch verstanden, das mit den Ressourcen war auf das entwickeln von x86s bezogen. Für mich stellt sich aber noch die Frage ob mit x86s AMD tatsächlich out of business wäre. Aber falls ja, dann wird das ziemlich sicher ein Rohrkrepierer.

[...]

AMD nicht, die haben ja ein gerichtlich erzwunges Cross-License-Abkommen, alle x86-Erweiterungen, die einer der Hersteller entwickelt, darf der andere auch nutzen. AMD darf X86S also genauso nutzen, wie AMX, APX usw. Aber alle anderen, insbesondere China, wären außen vor. Es wird aber niemand daran ernsthaftes Interesse haben, weil es niemandem Vorteile bringt außer Intel. Ich halte es für sinnlos, da noch einen Gedanken daran zu verschwinden, X86s ist dead on arrival - oder schon vorher.

reaperrr

2024-10-05, 14:11:51

Es wird aber niemand daran ernsthaftes Interesse haben, weil es niemandem Vorteile bringt außer Intel. Ich halte es für sinnlos, da noch einen Gedanken daran zu verschwinden, X86s ist dead on arrival - oder schon vorher.
Die Logik versteh ich nicht ganz.
AMD könnte davon potentiell genauso profitieren wie Intel, jedenfalls gegenüber ARM.
Und von AVX & Co. hat zu Anfang auch nur Intel profitiert, zumindest im Serverbereich hat es sich trotzdem durchgesetzt (hätte es vmtl. auch im Consumer-Bereich zu gewissem Grad, wenn Intel höchstselbst es nicht durch verquere Produktsegementierungen sabotiert hätten).

Und was die Software-Seite angeht: Die entfernten Legacy-Elemente könnte man grundsätzlich in einem Übergangszeitraum immer noch per Emulation unterstützen, nur halt langsam.
Dann würde noch so ziemlich alles an x86 auch auf X86s laufen, nur manche Asbach-Software nicht mehr so schnell.

basix

2024-10-05, 14:26:22

Vielleicht ist man nichtmal wirklich langsamer. Je nachdem was die Performance limitiert. Packt man 16bit Daten & Instruktionen auf 64bit Werte verteilt, sinkt die Performance erstmal nicht aber der Speicherverbauch steigt um 4x (ineffiziente Speichernutzung). Ich vermute bei sehr alter SW wäre das zu verkraften, da die noch mit deutlich weniger DRAM, Register und Cache konzipiert wurde. Einzig bei den L1-Caches (L1I, L1D) würde es etwas knapp werden, da hatte man früher bereits 32/64 kByte. Intel löst das jetzt aber indirekt mit Lion Cove und dem neuen 192kB "L1.5-Cache" und beim L1I hängt das meiste am uOp-Cache und nicht dem L1I. L2-Caches sind schon lange dem 256kB Zeitalter entwachsen. LLC sind ebenfalls dem 4-8 MByte Zeitalter entwachsen.

Solange man also genug Cache und Register-Slots hat, könnte 16bit -> 64bit ohne grosse Performance-Regression von statten gehen. Die alte SW wird vermutlich eh nur schlecht bis mittelprächtig auf neuen Prozessoren skaliert haben, da man eben schon alles in den Registern und Caches untergebracht kriegt und man keine neuen Befehlssätze nutzt.
mMn wird es nur langsam werden, wenn irgendwelche Instruktionen langsam sind. Das könnte man vermutlich aber im Instruction-Decoder lösen und auf neue / moderne Befehle mappen (wenn das irgendwie sinnvoll geht und das die SW nicht beeinträchtigt).

iamthebear

2024-10-05, 16:26:52

So wie ich das verstanden haben wird bei x86s lediglich mit etwas altem Zeugs aufgeräumt, das sowieso niemand mehr braucht.

Da Windows 11 keine 32 Bit Version mehr hat und Windows 10 Ende 2025 ausläuft wird es wohl sowieso keine 32 Bit Treiber mehr geben. Somit kann man den ganzen Bootvorgang vereinfachen.
32 Bit Anwendungen können natürlich noch ausgeführt werden und (vermutlich) auch noch virtuelle 32 Bit Maschinen.

Das Ganze wird weder einen Performanceboost bringen noch nennenswerte Einsoarungen bei der die size bringen aber es macht das Ganze System etwas einfacher und reduziert somit eventuell die Angriffsfläche für potentielle Sicherheitsprobleme. Auch für diverse UEFI Tools wird es einfacher werden.

Zossel

2024-10-05, 16:43:34

Sie haben noch nichtmal einen alpha Prototypen ("Technologiestudie") gezeigt mit welchem sie die Vorteile con X86s wenigstens grob presentieren können, aber die Spezifikation dazu hat schon >1.x :freak: Das können sie mehrfach ausdrucken und in Santa Clara in den Shicehauskabinen verteilen.

Erwartest du ernsthaft das so ein Ding außerhalb eines Simulators existiert?
Mal eben ein teures Stück Silizium produzieren was keinerlei Erkenntnisse produziert?

Zur Erinnerung: Warum u.a. Intel gerade solche heftigen Probleme hat: https://www.semianalysis.com/p/rebuilding-intel-foundry-vs-idm-decades

Badesalz

2024-10-05, 20:18:13

Die Logik versteh ich nicht ganz.
AMD könnte davon potentiell genauso profitieren wie Intel, jedenfalls gegenüber ARM.Du steigst zu spät ein. Der richtige Zeitpunkt war als wir uns mit diff.Rob gegenseitig gefragt haben was das denn genau reales bringen soll. Oder ist das nicht die Wiederholung dessen? Dann hätte es irgendwie was aufklärendes sein müssen (?) ;)

(hätte es vmtl. auch im Consumer-Bereich zu gewissem Grad, wenn Intel höchstselbst es nicht durch verquere Produktsegementierungen sabotiert hätten).Das. Und asymetrische Fortführung dessen. Wie gesagt, zum Kotzen.

PS:
iamthebear mit der Win-Idee der Woche. 32bit Viren funktionieren nicht mehr :D

Ich weiß nur nicht was das für die Soft noch mehr vereinfachen soll ("uefi" und sonstige Ideen...), gegenüber dem Fall, daß all diese Soft sich eben von alleine und selbst nicht mehr um 16bit/32bit kümmern würde. Was macht es da noch einfacher, wenn die CPU das nicht mehr kann was die Software nicht mehr tut?

Ah ja. Die letzte Version von ELKS ist 11 Tage her... Nicht alles immer durch die A++ Gamerbrille sehen.

ryan

2024-10-10, 03:54:20

They liquidated Royal, killed the future Atom roadmap, and put the Atom team in charge of UC. I'd say about 50/50 they kill the separate UC effort entirely and just leverage the P-core line, and that's probably what the P-core team is banking on. It worked for "dealing with" Royal, after all.

And one thing about Intel's history is that you should never bet against the Core team's ability to win political fights. Because that's ultimately what this is. If it was a question of engineering merit, P-core would have been killed by now.
https://www.reddit.com/r/hardware/comments/1fz4xxw/comment/lr1lhas/

Wenn sie den UC auch noch killen und stattdessen mit dem P-core alleinig weitermachen, wäre das der worst case. Aber noch ist es nicht soweit.

Wenn ich sowas hier lese....

More or less, yeah. Though the idea seems that P-core owns the roadmap for the next few years, then gives way to UC, at which point they're truly merged. But what if the P-core team offers an alternative and uses that as leverage to smother UC in the crib?

It doesn't even need to be credible. They just need to say it'll exist, and management will believe them, and kill the Atom team just as they did Royal. Once that's accomplished, they'll go back to being the only core team at Intel that matters, just like the Skylake days. We all saw how that worked out.

Wann kommt Intel endlich mal zur Vernunft. Das Management ist entweder richtig inkompetent oder es ist richtig viel Politik im Spiel.

fondness

2024-10-10, 08:12:01

https://www.reddit.com/r/hardware/comments/1fz4xxw/comment/lr1lhas/

Wenn sie den UC auch noch killen und stattdessen mit dem P-core alleinig weitermachen, wäre das der worst case. Aber noch ist es nicht soweit.

Wenn ich sowas hier lese....

Wann kommt Intel endlich mal zur Vernunft. Das Management ist entweder richtig inkompetent oder es ist richtig viel Politik im Spiel.

Der CEO gehört weg, da gibt es überhaupt keine Diskussion mehr. Wenn der so weiter macht ruiniert er den Konzern noch völlig. Das mit Politik zu begründen ist absurd. Es wird doch eine Person bei Intel geben, die anhand von technischen Fakten entscheiden kann? Offensichtlich nicht wenn man das so ließt. Dann wäre es noch immer die Aufgabe des CEO den Laden aufzuräumen, was er offensichtlich nicht schafft. Alleine schon das jemand wie Jim Keller, ein begnadeter CPU engineer Intel verlässt wegen internen Streitigkeiten zeigt ja schon das es an der Struktur krankt. Wenn jetzt wirklich das p core Team, das ja von den Konkurrenz von AMD und Apple in der Vergangenheit einfach nur stehen gelassen wurde intern mehr Macht bekommt spricht das Bände

HOT

2024-10-10, 08:43:12

Ich glaube das ist zu spät. Pat hat es versäumt 22/23 die Weichen richtig zu stellen oder überhaupt Weichen zu stellen.

Wenn die jetzt von p-Cores sprechen, dann meinen die aber nicht Lion Cove oder Raptor Cove, sondern Coyote-Cove und danach. Panther Cove ist mMn auch so ein Dinosaurier, den meinen die auch nicht, ich halte Panther Cove für einen Golden Cove und Redwood Cove-Nachfolger in 18A mit 4 Threads pro Kern statt 2 und AMX+AVX10. Wir wissen nicht, wie gut Coyote gegen Arctic Wolf abschneidet, vielleicht ist der sogar effizienter. Am Ende scheint jedenfalls nur noch ein Design pro Periode zu stehen.

iamthebear

2024-10-11, 02:54:19

Desktop Gaming ist eine kleine Nische. Was zählt sind Laptop, Tablet, Smartphone und der Datacenterbereich.

Bei Laptop/Tablet hat man mit Lunar Lake ein echt gutes Produkt am Start. Datacenter ist man mit Clearwater Forrest auch auf einem sehr guten Weg. Den Qualcomm Angriff hat man auch erfolgreich abgewehrt.

Die Felder waren vor 2 Jahren noch ein komplettes Drama und man hatte nur Glück dass AMD großteils noch Zen2/3 Laptop CPUs verkauft hat.

Das große Problem das bleibt sind die Fabs.

Was die Sache mit Jim Keller angeht: Das war nich vor der Gelsinger Zeit und wäre mit ihm auch kaum passiert.

fondness

2024-10-11, 09:59:48

Ja genau und für das einzig erfolgreiche Produkt, nämlich LNL gibt es keinen Nachfolger - der nächste Management-Fail. Das mit dem Server-Bereich hat sich mit dem gestrigen Launch von Turin auch stark relativiert.

Die Fabs sind ein großes Problem ja, da gebe ich dir Recht. Aber mindestens ein ebenso großer Problem ist es, dass Intel mit der Entwicklungsgeschwindigkeit der Konkurrenz immer schlechter mithalten zu können scheint. Und das trotz erheblich mehr Ressourcen. Als AMD damals mit Zen bzw. Zen2 kam, war es für mich nur eine Frage der Zeit, bis der Intel-Train wieder fahrt aufnimmt und drüber walzt. Davon ist nichts zu sehen.

Zossel

2024-10-11, 17:58:53

Als AMD damals mit Zen bzw. Zen2 kam, war es für mich nur eine Frage der Zeit, bis der Intel-Train wieder fahrt aufnimmt und drüber walzt. Davon ist nichts zu sehen.

Das Fabs immer teurer werden und man hohe Stückzahlen braucht und Intel deswegen Drittkunden braucht und immer Wafer für Handys produziert werden hatte ja auch Intel schon recht früh erkannt, so um 2014 rum.

Aber dafür hätte man den Laden ganz anders aufziehen müssen und Intel wollte ja unbedingt X86 auf Handys bringen, was auch eine völlige Schnapsidee war den welcher OEM will sich ohne Not in die Hände eines Monopollieferanten begeben der für fragwürdige Vertriebsmethoden bekannt ist.

Das Drama um Intel hat sich schon viel früher angekündigt.

Und mittlerweile ist der Laden so runter gerockt das der CEO schon alleine wegen der Kosten auch Projekte eingestampft die einen zu langen ROI haben.
Das kann funktionieren muss aber nicht.

Zossel

2024-10-11, 18:12:28

Der CEO gehört weg, da gibt es überhaupt keine Diskussion mehr. Wenn der so weiter macht ruiniert er den Konzern noch völlig. Das mit Politik zu begründen ist absurd. Es wird doch eine Person bei Intel geben, die anhand von technischen Fakten entscheiden kann?

Man braucht dafür auch Kohle, wenn Intel keine Kohle hat und niemand als Investor da Kohle rein schießt bleibt dir nichts anderes übrig. So ist eben Kapitalismus.

Hast du noch in einem Laden gearbeitet der gerade saniert wird?

fondness

2024-10-13, 11:08:00

Das Fabs immer teurer werden und man hohe Stückzahlen braucht und Intel deswegen Drittkunden braucht und immer Wafer für Handys produziert werden hatte ja auch Intel schon recht früh erkannt, so um 2014 rum.

Ja erkannt hatte Intel eh viel, nur die Execution war häufig eine Katastrophe. Sie haben auch früh erkannt, dass sie eine HPC-Beschleuniger brauchen. 2012 kam Larrabee. Grauenhaftes Produkt. Selbst 12(!) Jahre später hinken sie noch immer hinterher, und das wo Intel lange Geld wie Heu hatte. Das ist unfassbar schlechte Execution. Dasselbe mit den Fabs, wenn ich es seit 10 Jahren weiß aber zu inkompetent bin um Kunden anzuwerben, dann muss ich es entweder schaffen die Bedenken der Kunden auszuräumen oder ohne Fabs planen. Was Intel jetzt macht ist mit den Fabs unterzugehen.

Aber dafür hätte man den Laden ganz anders aufziehen müssen und Intel wollte ja unbedingt X86 auf Handys bringen, was auch eine völlige Schnapsidee war den welcher OEM will sich ohne Not in die Hände eines Monopollieferanten begeben der für fragwürdige Vertriebsmethoden bekannt ist.

Bitte? Apple wollte einen Intel-SoC fürs iPhone! Das dümmste Management aller Zeiten hat abgelehnt.

Und mittlerweile ist der Laden so runter gerockt das der CEO schon alleine wegen der Kosten auch Projekte eingestampft die einen zu langen ROI haben.
Das kann funktionieren muss aber nicht.

Naja ich sag mal AMD hat es aus einer weit kritischeren Lagen noch heraus geschafft, also möglich ist das schon. Aber nur wenn sie es schaffen ihre internen Probleme in den Griff zu bekommen.

fondness

2024-10-13, 11:10:52

Man braucht dafür auch Kohle, wenn Intel keine Kohle hat und niemand als Investor da Kohle rein schießt bleibt dir nichts anderes übrig. So ist eben Kapitalismus.

Ach bitte da ist noch mehr als genug Substanz da. Sie müssen sich halt auf ihre Kernmärkte fokussieren und unnötiges Zeug das eh nur Verluste macht abdrehen. Auch haben sie unfassbar viele Mitarbeiter in Relation zur Konkurrenz. Wenn ich es mit noch immer ~75% Server-/Mobile-/Desktop-Marktanteil nicht schaffe profitabel zu sein habe ich ein Ausgabenproblem.

Hast du noch in einem Laden gearbeitet der gerade saniert wird?

Nope, da hab ich mich immer aus dem Staub gemacht. :D

Zossel

2024-10-13, 14:36:28

Bitte? Apple wollte einen Intel-SoC fürs iPhone! Das dümmste Management aller Zeiten hat abgelehnt.

Der war nicht X86, sondern Strongarm, also eigentlich DEC. Der Versuch mit X86 kam später.

Und das war noch vor dem ersten iphone, das hätte auch ein Rohrkrepierer werden können. Bitte keine Mythten und Legendenbildung.

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

fondness

2024-10-13, 14:45:43

Der war nicht X86, sondern Strongarm, also eigentlich DEC. Der Versuch mit X86 kam später.

Und das war noch vor dem ersten iphone, das hätte auch ein Rohrkrepierer werden können. Bitte keine Mythten und Legendenbildung.

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

Warum hätte das ein rohrkrepierer werden sollen? Das iPhone wurde doch nicht wegen dem SoC oder der ISA gekauft. Es wäre der ultimative Einstieg ins Smartphone Geschäft gewesen. Erst der Verzicht von Intel hat den Aufstieg von ARM eingeleitet. Wenn ich ein Monopol halte und das behalten will muss ich alles anbieten, das ist absolutes Basiswissen. Hier abzulehnen war an Dummheit kaum zu überbieten.

Zossel

2024-10-13, 14:52:51

Warum hätte das ein rohrkrepierer werden sollen? Das iPhone wurde doch nicht wegen dem SoC oder der ISA gekauft. Es wäre der ultimative Einstieg ins Smartphone Geschäft gewesen. Erst der Verzicht von Intel hat den Aufstieg von ARM eingeleitet. Wenn ich ein Monopol halte und das behalten will muss ich alles anbieten, das ist absolutes Basiswissen. Hier abzulehnen war an Dummheit kaum zu überbieten.

Genau genommen war es das erste Telefon mit einem kapazitiven Touchscreen.
Und wie ich bereits schrub wollte Apple einen arm von Intel.

basix

2024-10-13, 16:07:35

Hinter dem Smartphone oder generell Mobiltelefon war damals bei weitem nicht der selbe Business Case dahinter. Das wurde erst durch das iPhone und alles was danach kam geschaffen.

fondness

2024-10-13, 16:12:17

Hinter dem Smartphone oder generell Mobiltelefon war damals bei weitem nicht der selbe Business Case dahinter. Das wurde erst durch das iPhone und alles was danach kam geschaffen.

Das ist schon klar. Aber wie gesagt als Monopolist muss ich jede Nische besetzen, das ist absolutes Basis-BWL-Wissen. Gerade bei einem potentiellen Zukunftsmarkt wie dem Smartphone. Aber dem MBA-CEO war eben sein Gehaltscheck, der an den kurzfristigen Gewinn gekoppelt war wichtiger als die langfristige Perspektive des Unternehmens.

HOT

2024-10-17, 08:47:16

Ich weiss nicht ob das schon bekannt war, aber im neuesten MLID ist der "ELLC" erwähnt worden, "extended last level cache" für Nova Lake.

Badesalz

2024-10-17, 08:50:28

Ja. Wenn sie das V-Cache nennen würden wäre das bisschen doof ;) Das ist aber 2026+. AMD wird bis dahin nicht pennen...

iamthebear

2024-10-20, 01:38:41

Das Fehlen von VCache ist aktuell für Intel sicher ein Nachteil aber das ist bei Intel ja nicht das Hauptproblem. Auch Raptor Lake kam schon mit 36MB L3 (plus einiges in den L2 Caches der Cores) ganz gut zu Recht.
Das Problem ist das Fehlen von IPC Verbesserungen der P Cores und zwar in sämtlichen Workloads.

Intel muss einen Weg finden bei Nova Lake deutlich IPC drauf zu legen aber ehrlich gesagt deuten die bisherigen Leaks eher in die gegensätzliche Richtung.

Zossel

2024-10-20, 08:26:39

Auch Raptor Lake kam schon mit 36MB L3 (plus einiges in den L2 Caches der Cores) ganz gut zu Recht.

Das "plus" wäre nur bei einer exklusiven Cache-Hierachie gerechtfertigt.

Wuge

2024-10-21, 09:15:40

Die Caches sind nahezu exklusiv.

mocad_tom

2024-10-28, 11:29:49

https://x.com/kopite7kimi/status/1850012915069563168

Was kopite7kimi mal eben so an einem Samstag raushaut:

Although PTL will reintegrate IMC into the compute die, NVL will once again separate and optimize it.

Nova Lake dann mit Foveros Direct?

Und dadurch dann schnellere Die-2-Die-Interfaces?
Und dadurch dann der IMC schneller an den Compute Tile angebunden?

HOT

2024-10-28, 11:34:56

Ich nehme aber an, dass Intel da auch einfach Probleme mit der Integration iherer Topologie hatten. Wie gesagt, bei AMD geht das über einen furznormales MCM-Package trotzdem schnell.
Ich denke eher, dass NVL hier ein paar Dinge deutlich anders macht.

ryan

2024-10-28, 17:26:04

https://x.com/kopite7kimi/status/1850012915069563168

Was kopite7kimi mal eben so an einem Samstag raushaut:

Nova Lake dann mit Foveros Direct?

Und dadurch dann schnellere Die-2-Die-Interfaces?
Und dadurch dann der IMC schneller an den Compute Tile angebunden?

Ja irgendwie wird das schneller angebunden, siehe Exist50. Nach Nova Lake soll noch eine weitere letzte Generation mit P+E Kernen folgen und das wäre Razor Lake im gleichen Sockel. Wobei Razor Lake wohl ein Tick sein wird von Nova Lake. Wenn alles klappt, könnte danach der unified Atom alles übernehmen.

Yes. PTL, NVL, RZL, etc are all derivatives of the LNL SoC. So when NVL eventually arrives to desktop, it should provide a disproportionately large gaming boost vs ARL, even if the core improvements are mid.

Note, however, that I'm not talking about the die-die cutlines. More the SoC-die fabric and equivalent.

Correct, but they fix the fabric. That's the most important part.
https://www.reddit.com/r/hardware/comments/1gb4spc/comment/ltvcfjl/?context=3

davidzo

2024-10-28, 18:17:43

https://x.com/kopite7kimi/status/1850012915069563168

Was kopite7kimi mal eben so an einem Samstag raushaut:

Nova Lake dann mit Foveros Direct?

Und dadurch dann schnellere Die-2-Die-Interfaces?
Und dadurch dann der IMC schneller an den Compute Tile angebunden?

Ohne Frage ist MTL mit 36µm eher Foveros Omni zuzuordnen und nicht Foveros Direct.

Bei Arrowlake scheint Intel der Presse aber was von Foveros Direct und 9µm erzählt zu haben.
https://www.hardwareluxx.de/index.php/artikel/hardware/prozessoren/64714-intel-core-ultra-200s-im-test-der-pfeil-findet-sein-ziel-nicht.html
Btw, rein zufälligerweise identisch zum 9µm Pitch bei AMDs 3D Vcache der auch von TSMC stammt und direkt gebondet wird.

Entweder Intels Marketing erzählt quark während das weiterhin 36µm microbumps sind, oder der Base-Tile in 22FDX hat wirklich zwei verschiedene Pitches für den CPU Tile (9µm) und die restlichen Tiles (36µm).

In letzterem Fall wäre es eine große Leistung von Intels inhouse Packaging zwei verschiedene Bondingprozesse auf demselben Carrier DIE durchzuführen, wobei die µbums sicher auch mehr Z-Höhe haben und die DIEs nachher wohl alle noch angeglichen werden müssen.

Wenn das schon Foveros direct war, dann tut das aber nicht viel helfen.

Zossel

2024-10-28, 18:22:12

Wenn das schon Foveros direct war, dann tut das aber nicht viel helfen.

Und diese hohen Kosten bei der Produktion und die daraus resultieren niedrigen Margen.
Intel wird sicherlich 5-10 Jahre brauchen bis der Tanker wieder auf Kurs ist.

davidzo

2024-10-28, 18:33:53

Und diese hohen Kosten bei der Produktion und die daraus resultieren niedrigen Margen.
Intel wird sicherlich 5-10 Jahre brauchen bis der Tanker wieder auf Kurs ist.

Ich glaube nicht dass es Foveros direct ist. Da haben die Marketing Schwurbler was durcheinander bekommen, möglicher weise weil man den Interconnect bei Meteorlake mit dem schwungvollen Namen "FDI = Foveros direct Interconnect" betitelt hat. Da kommt man dann schnell auf die Idee dass das nicht Foveros Omni basiert ist sondern Foveros Direct.

In den Arrowlake Folien werden eindeutig kleiner solderbumps zwischen den DIEs zeigt:
https://www.hardwareluxx.de/images/cdn02/uploads/2024/Oct/elated_lithium_n6/intel-core-ultra-200s-briefing-009_680px.jpeg

Wie die auf 9µm kommen weiß ich nicht, aber ich meine das neben Hwlxx auch woanders gelesen zu haben.

mocad_tom

2024-10-28, 18:43:49

Arrow Lake ist 30µm und Microbumps.

Und mit Meteor und Arrow hat Intel auch zwei volumenstarke Prozessorengenerationen, die 36µm und 30µm Foveros verwendet.

Die müssten bei Advanced Packaging aktuell was Volumen betrifft führend sein.

Das was Intels Packaging-Abteilung volumenmäßig ausspuckt ist ziemlich beeindruckend und sie hatten bei Meteor Lake sogar Lieferengpässe.

Ja ich weiß schon, das Hybrid-Bonding bei AMD Instinct und beim 3d-Cache ist rein von den PicoJoule her nochmal besser, aber sie können gerade nicht mehr Volumen liefern.

Sonst würde AMD im Laptop nicht auf monolithische Dies setzen.

davidzo

2024-10-28, 20:30:05

Arrow Lake ist 30µm und Microbumps.

Und mit Meteor und Arrow hat Intel auch zwei volumenstarke Prozessorengenerationen, die 36µm und 30µm Foveros verwendet.

Oh, noch eine dritte Zahl, 30µm.
- Nicht wenn das i/o DIE tatsächlich das gleiche ist wie bei MTL, denn das hatte 36µm laut den Folien.
Den µbump Pitch minimal zu ändern wird wohl schwer gehen ohne Respin vom i/o DIE und für die ganzen RDL layer neue Masken nimmt.

So ein Schildbürgerstreich würde aber zu Intel passen und erklärt dann auch die time to market.
Das hat man schließlich bei Intel Sockeln auch schon immer so gemacht.

Das was Intels Packaging-Abteilung volumenmäßig ausspuckt ist ziemlich beeindruckend und sie hatten bei Meteor Lake sogar Lieferengpässe.

Das wundert mich in der Tat, denn so berauschend fand ich MTL jetzt nicht dass man sich da genötigt sieht zuzugreifen.

Das erklärt aber auch wieso der 285K so eine lahme Ente ist.
- Das löst für Intel immerhin das Problem der Fertigungskapazität weil den 285k in diesem Zustand eh keiner kaufen will :ulol3:

mocad_tom

2024-10-28, 22:13:12

https://x.com/GPUsAreMagic/status/1848749030009937965

Es wird nur das I/O-Tile (darin sitzt Thundebolt & PCIe) wiederverwendet.

Das SOC-Tile zwischen MTL und ARL ist wie man auf den Bildern erkennen kann ziemlich unterschiedlich.

Kann auch sein, dass sie das 30µm Raster nur unter dem CPU Tile und hin zum SOC-Tile so nutzen.

Sie mussten ein Raster finden, dass sowohl mit Intel 20A kompatibel ist als auch mit TSMC N3B.

Ich suche bloß gerade, wo ich das gelesen habe.

Und Arrow braucht noch ein bisschen, der hat aber noch ein paar Prozent Punkte im Tank, die aber noch nicht gehoben sind.

Gipsel

2024-10-28, 23:18:19

Arrow Lake ist recht sicher 36µm Pitch und das "normale" Foveros (weder omni noch direct). So wurde das von intel zumindest im Vorfeld auf der Hotchips-Konferenz behauptet. Die nächste Evolutionsstufe ist dann angeblich 25µm Pitch.

davidzo

2024-10-29, 00:07:55

Ja ich denke auch es ist wahrscheinlicher dass das ein Fehler von Andreas Schilling ist. Woanders habe ich das nicht wieder gefunden.

Btw, Lunarlake ist 25µm, das ist also schon die nächste generation, aber immer noch mit µBumps und nicht direkt gebondet.

ryan

2024-11-04, 15:20:15

Von Tigerick:

Higher NGU (new term for NoC of SoC tile) and ring clocks should fix the memory latency issues

The top-end SKU of NVL-S / NVL-HX will integrate V-cache similar to AMD's X3D. My source can't confirm the amount of L3 cache but the recent leaks about 144MB seems valid. This is going to be fourth tile on top (or bottom?) of current three-tile SoC.

Currently, NVL platform will support up to 128-bit DDR5-7200, the same memory speed AMD would support for upcoming Zen6.

Both Intel's NVL and AMD's Zen6 are targeting for Q4-2026 release.
https://forums.anandtech.com/threads/intel-nova-lake-in-2026-discussion-threads.2623246/

Das V-Cache Gegenstück könnte allerdings noch gestrichen werden, Intel muss sparen. Nach Nova Lake soll eine letzte Generation mit der alten P-Kern Architektur erscheinen. Das soll Razor Lake mit Griffin Cove sein. Wobei Razor Lake ein Tick von Nova Lake im gleichen Sockel sein sollte. Macht ja auch Sinn. Danach übernimmt Intels Atom Architektur.

Zusammenfassend:

Panther Lake = Cougar Cove+Darkmont
Nova Lake = Coyote Cove/Panther Cove+Arctic Wolf (Coyote für Client)
Razor Lake = Griffin Cove+Golden Eagle
Titan Lake = Unified Kern auf Basis der Atom Architektur

Bei Titan Lake bin ich mir nicht sicher, ob sie den Namen beibehalten.

Platos

2024-11-04, 19:28:05

Ah nice, also möglicherweise "Gaming"-Cache auch bei Intel endlich. Wie viel hat AMD nochmals momentan? Ich hoffe, das kommt dann nicht nur für den i9 sondern für alle K-CPUs (oder wie sie jetzt neu heissen).

Und bezüglich unified Kern: Ist damit Rentable Unit gemeint? Also ein Kern, der sich dann quasi mittels Rentable Unit auf viele kleine Aufteilen kann (oder so ähnlich)? Oder was ist damit gemeint? Und was heisst Atom-Architektur? Das hat nichts mit den Intel Atom-CPUs zu tun oder :D ?

ryan

2024-11-04, 22:14:12

Atom sind die E-Kerne, aktuell Skymont. Unified Kern bedeutet erstmal, dass Intel nur noch auf eine Architektur setzt. Im Moment setzen sie auf zwei Architekturen. Der vereinigte Kern basiert auf der Atom Architektur. Das ist jetzt der Plan.

fondness

2024-11-05, 09:08:00

Von Tigerick:

https://forums.anandtech.com/threads/intel-nova-lake-in-2026-discussion-threads.2623246/

Das V-Cache Gegenstück könnte allerdings noch gestrichen werden, Intel muss sparen. Nach Nova Lake soll eine letzte Generation mit der alten P-Kern Architektur erscheinen. Das soll Razor Lake mit Griffin Cove sein. Wobei Razor Lake ein Tick von Nova Lake im gleichen Sockel sein sollte. Macht ja auch Sinn. Danach übernimmt Intels Atom Architektur.

Zusammenfassend:

Panther Lake = Cougar Cove+Darkmont
Nova Lake = Coyote Cove/Panther Cove+Arctic Wolf (Coyote für Client)
Razor Lake = Griffin Cove+Golden Eagle
Titan Lake = Unified Kern auf Basis der Atom Architektur

Bei Titan Lake bin ich mir nicht sicher, ob sie den Namen beibehalten.

Puh, das dauert ja alles noch sehr sehr lange. Klingt, als wäre die Entscheidung erst vor kurzem gefallen. Hoffentlich ist das alles nicht zu spät. Man hat das Gefühl Intel reagiert immer erst um 5 nach 12. Da sind wir ja fast bei 2030 bis die Unified-Architektur übernimmt und bis dahin will man die verkorkste P-Core-Architektur mitschleppen? Und das Zeug von Jim Keller war wirklich alles so ein Schrott, dass man das nicht bringen konnte? Naja sie wissen hoffentlich was sie tun.

Zossel

2024-11-05, 09:17:32

fondness

2024-11-05, 09:21:33

Was hast du erwartet?

Ich hatte gedacht nach Panther Lake übernimmt die Unified Architektur. Die eCores sind ja schon relativ weit, und wenn man schon das Ding von Jim Keller streicht sollte man was in der Hinterhand haben.

Zossel

2024-11-05, 09:34:01

Ich hatte gedacht nach Panther Lake übernimmt die Unified Architektur. Die eCores sind ja schon relativ weit, und wenn man schon das Ding von Jim Keller streicht sollte man was in der Hinterhand haben.

Das Team wurde gestrichen und die führenden Köpfe machen was anderes. Da gab es eine Meldung zu.

Ansonsten dürfte Intel gerade seine Entwicklungsorganisation und seine internen Roadmaps heftigst umstellen.

HOT

2024-11-05, 10:21:13

Von Tigerick:

https://forums.anandtech.com/threads/intel-nova-lake-in-2026-discussion-threads.2623246/

Das V-Cache Gegenstück könnte allerdings noch gestrichen werden, Intel muss sparen. Nach Nova Lake soll eine letzte Generation mit der alten P-Kern Architektur erscheinen. Das soll Razor Lake mit Griffin Cove sein. Wobei Razor Lake ein Tick von Nova Lake im gleichen Sockel sein sollte. Macht ja auch Sinn. Danach übernimmt Intels Atom Architektur.

Zusammenfassend:

Panther Lake = Cougar Cove+Darkmont
Nova Lake = Coyote Cove/Panther Cove+Arctic Wolf (Coyote für Client)
Razor Lake = Griffin Cove+Golden Eagle
Titan Lake = Unified Kern auf Basis der Atom Architektur

Bei Titan Lake bin ich mir nicht sicher, ob sie den Namen beibehalten.

Super Zusammenstellung, da geh ich voll mit. :up:

Ich denke auch, Zen6 wird erst Ende 26 erscheinen, weil es ja noch relativ heftige Architekturänderungen geben soll, die vorher nicht eingeplant worden sind. Das dürfte 1/2 Jahr Verzögerung erklären.
Titan Lake könnte auch Titan Core sein. Ich weiss, dass der Codename schon länger herumgeistert, aber in der Scene gibts auch schonmal stille Post.
Man darf das nicht alles so heiß essen, wie es gekocht wird. Auch diese Planungen dürfte es Intel intern schon länger geben, das ist nicht alles auf einmal umgestoßen worden. Intel ist oft 2- oder mehrgleisig gefahren und hat ein Design wieder verworfen, ich vermute, das kann und möchte man sich so einfach nicht mehr leisten. Die Konzentration auf die .mont-Architektur wird auch richtig sein, weil das einfach der modernere Ansatz ist, der einfach mehr Erfolg langfristig verspricht, vor allem, da die Fertigungsprozesse die ausufernde Kerngröße nicht mehr unbedingt auffangen können.

Zossel

2024-11-05, 10:47:21

Ich denke auch, Zen6 wird erst Ende 26 erscheinen, weil es ja noch relativ heftige Architekturänderungen geben soll, die vorher nicht eingeplant worden sind. Das dürfte 1/2 Jahr Verzögerung erklären.
Welcher Youtube-Onkel hat das erzählt?

ryan

2024-11-05, 12:58:18

Puh, das dauert ja alles noch sehr sehr lange. Klingt, als wäre die Entscheidung erst vor kurzem gefallen. Hoffentlich ist das alles nicht zu spät. Man hat das Gefühl Intel reagiert immer erst um 5 nach 12. Da sind wir ja fast bei 2030 bis die Unified-Architektur übernimmt und bis dahin will man die verkorkste P-Core-Architektur mitschleppen? Und das Zeug von Jim Keller war wirklich alles so ein Schrott, dass man das nicht bringen konnte? Naja sie wissen hoffentlich was sie tun.

Nova Lake ist schon lange P+E. Mit einem besseren Chiplet Design und besseren Latenzen wäre das halb so schlimm gewesen mit Arrow Lake. Der Cove ist zwar flächenmäßig ineffizient, was uns aber erstmal egal sein könnte. Für Nova Lake stehen die Zeichen besser und für mobile schon mit Panther Lake.

Bei dem unified auf Atom Basis müssen sie das Rad nicht neu erfinden. Im Prinzip müssen sie nur das Golden Eagle Design nehmen und etwas mehr in Fläche investieren und hochskalieren als wenn sie den Nachfolger als E only bringen würden. Wie stark sie den umbauen wird man dann sehen.

Das Risiko ist lange so hoch wie beim äußerst ambitionierten Royal Projekt, welcher noch Jahre vor der Fertigstellung stand. Das Risiko konnte Intel nicht länger eingehen. Jim Keller soll nichts mit Royal zu tun gehabt haben.

fondness

2024-11-05, 13:08:39

Nova Lake ist schon lange P+E. Mit einem besseren Chiplet Design und besseren Latenzen wäre das halb so schlimm gewesen mit Arrow Lake. Der Cove ist zwar flächenmäßig ineffizient, was uns aber erstmal egal sein könnte. Für Nova Lake stehen die Zeichen besser und für mobile schon mit Panther Lake.

Der Cove ist nicht nur flächenmäßig ineffizient, sondern auch Energieineffizient. Sieht man immer dann, wenn die P-Cores wirklich gefordert werden. Deshalb braucht man auch trotz 3nm immer noch 250W TDP. Sie haben zwar ein sehr gutes Powermanagement, dass im Teillastbetrieb viel hilft, aber bei maximaler Last saufen die Dinger viel zu viel.

Das Risiko ist lange so hoch wie beim äußerst ambitionierten Royal Projekt, welcher noch Jahre vor der Fertigstellung stand. Das Risiko konnte Intel nicht länger eingehen. Jim Keller soll nichts mit Royal zu tun gehabt haben.

Also später als 2030 wäre das Royal Projekt sicher auch nicht gekommen. Und warum konnte Intel das Risiko nicht länger eingehen? Wenn das wirklich nichts geworden wäre hätte man noch immer auf die eCores setzen können.

HOT

2024-11-05, 13:16:45

Welcher Youtube-Onkel hat das erzählt?

Gar keiner, das ist meine Vermutung. MLID erzählte von einer seiner Quellen, dass es bei Zen6 recht spät im Projekt noch ein paar wichtige Änderungen gegeben haben soll und der Leaker spricht jetzt von Ende 26, das passt halt zusammen.

Wuge

2024-11-05, 14:53:53

Der Cove ist nicht nur flächenmäßig ineffizient, sondern auch Energieineffizient. Sieht man immer dann, wenn die P-Cores wirklich gefordert werden. Deshalb braucht man auch trotz 3nm immer noch 250W TDP. Sie haben zwar ein sehr gutes Powermanagement, dass im Teillastbetrieb viel hilft, aber bei maximaler Last saufen die Dinger viel zu viel.

Sie saufen nur wenn sie ausgelutscht werden. Wenn ich hier am Raptor Lake benches mache mit 0.95V Spannung, dann sind die 8 P Cores in etwa genauso effizient wie die 16 E Cores. Bei ycruncher sogar nahezu gleicher Stromverbrauch bei gleicher Leistung.

Nur wenn es an Single Thread Performance geht, ziehen die P cores einfach ab. Zwar nicht so effizient aber eben sehr schnell, da kommen die E Cores noch lange nicht hin, egal wie viel Power man gibt. Und solange das so ist, macht hybrides Design schon Sinn. Vielleicht irgendwann mit 2 großen, ineffizienten aber sehr schnellen P Cores und einer Menge effizienter E Cores.

Ich glaube auch nicht, dass die E Cores - wennman sie weiter aufbläst - am Ende viel Effizienzter die Leistung der P Cores bringen können. Abnehmender Grenzertrag - irgendwann wird jedes Prozent IPC teuer, evtl. erst ab 10% unter der aktuellen P Core Performance aber dann gehts los.

ryan

2024-11-05, 14:59:14

Raichu hält +20% IPC für Artic Wolf zu Darkmont für realistisch. Für Darkmont zu Skymont beziffert er +3-5%. https://x.com/OneRaichu/status/1852716602846003388

iamthebear

2024-11-05, 21:55:13

Zum Thema P vs. E Core Effizienz habe ich mit meinem 12700H einen Praxistest mit Cinebench gemacht:
a) 4E Cores auf vollem Takt (3.5GHz)
b) 4P Cores mit deaktiviertem Turbo (waren glaube ich um die 2.3GHz)

Beide Varianten waren ca. gleich schnell aber die P Cores haben nur ca. die Hälfte verbraucht.

Mit Skymont dürfte das deutlich besser aussehen aber leider habe ich bisher noch nicht viele Tests dazu gefunden (Lunar Lake konnte man nicht vergleichen mangels L3 Zugang

Und bezüglich unified Kern: Ist damit Rentable Unit gemeint? Also ein Kern, der sich dann quasi mittels Rentable Unit auf viele kleine Aufteilen kann (oder so ähnlich)? Oder was ist damit gemeint? Und was heisst Atom-Architektur? Das hat nichts mit den Intel Atom-CPUs zu tun oder :D ?

Da hat sich MLID in seinem Kopf woeder mal irgendetwas zusammengeträumt. Einen Kern "aufzuspalten" gibt es nun schon seit 20 Jahren. Das nennt sich SMT.

Bisher gibt es:
.) 1 P Core mit privatem L2 und eigenem Ringzugang
.) 4 E Cores, die sich L2 und Ringzugang teilen auf der Fläche eines P Cores (in der Praxis etwas größer)

Was Nova Lake angeht habe ich das so verstanden, dass die Kerne eine Mischung aus P+E Core sind:
.) 2 P Cores teilen sich einen L2 und Ringzugang
Wenn von den 2 Kernen nur einer aktiv ist, so ist es dem andereren Möglich gewisse Ressourcen des anderen Kerns zu "mieten". Im Prinzip ist das derselbe Gedanke wie bei SMT nur von der anderen Seite her gedacht.
Statt 8 P Cores gibt es dadurch dann 16 was die MT Leistung deutlich erhöhen sollte während man von den ST Performance in etwa auf Gleichstand mit den alten P Cores sein sollte.

MLID hat vor einiger Zeit einmal geleaked:
Intel hat beide Konzepte parallel entwickelt. Ein Design mit großen Kernen und SMT4 und eines ohne SMT aber mit Rentable Units. Das SMT4 Design hat aber deutlich schlechter performed.

Meine Spekulation: "Beast Lake" wäre eine Weiterentwicklung des SMT4 Designs gewesen. Das wurde dann aber mit eingestampft.

HOT

2025-01-31, 17:03:48

https://videocardz.com/newz/intel-nova-lake-s-for-desktops-rumored-to-feature-2x8p16e-configuration

Offenbar sind die NVL P-Cores sehr effizient. NVL-U soll nur noch 4 P-Cores haben. Im Desktop möchte man offenbar auch 2-Die-Konfigurationen wie bei AMD anbieten, also 2x 8+16 in Intels Fall, während das bei AMD dann 2x 12 Kerne sind.

NVL-U -> 4+0
NVL-S/H -> 4+8
NVL-SK/HX -> 8+16 bis zu 2 Dies

Im Maximum wäre das dann 16+32 Threads von Intel vs. 48 SMT-Threads seitens AMD.

Wenn man unterschiedliche L3-Configs anbieten möchte, muss es ja eigentlich auch 2 8+16-Dies geben, eines mit extrem viel Cache und eines mit weniger - dafür sind davon dann 2 möglich? Alternativ könnte der L3$ auch ins SoC-Die wandern und es gibt davon 2, mal sehen, wie das final aussieht.

fondness

2025-01-31, 17:05:49

Wenn Intel weiter Kerne gegen SMT stellen muss, wäre das nicht gerade eine Glanzleistung.

HOT

2025-01-31, 17:19:43

Wie schnell was ist sehen wir ja dann ;).
Kann ja sein, dass Intels Lösung 50% schneller wird.

ryan

2025-02-01, 16:33:20

https://videocardz.com/newz/intel-nova-lake-s-for-desktops-rumored-to-feature-2x8p16e-configuration

Offenbar sind die NVL P-Cores sehr effizient. NVL-U soll nur noch 4 P-Cores haben. Im Desktop möchte man offenbar auch 2-Die-Konfigurationen wie bei AMD anbieten, also 2x 8+16 in Intels Fall, während das bei AMD dann 2x 12 Kerne sind.

NVL-U -> 4+0
NVL-S/H -> 4+8
NVL-SK/HX -> 8+16 bis zu 2 Dies

Die LPE Kerne fehlen in der Auflistung. Falls das so stimmt, wäre vermutlich 4+0+4 korrekt. Das wäre identisch zu PTL-U. Das gleiche für NVL-H 4+8+4.

HOT

2025-02-01, 17:59:03

Die LPE Kerne fehlen in der Auflistung. Falls das so stimmt, wäre vermutlich 4+0+4 korrekt. Das wäre identisch zu PTL-U. Das gleiche für NVL-H 4+8+4.

Das ergibt sicherlich Sinn, also muss man das wohl aufteilen:

NVL-U -> 4+0+4
NVL-H -> 4+8+4
NVL-S -> 4+8
NVL-HX/SP -> 8+16
NVL-SP -> 2x 8+16 (oder 1x 8+16+144MB L3$?)

iamthebear

2025-02-01, 20:16:12

Gerade beim Gaming bin ich da nicht so optimistisch:

a) Mit den 2 Compute Tiles (8+16) wird Intel wohl dieselben Probleme haben wie AMD mit ihren 2 CCDs.

b) Jeweils 2 P Cores teilen sich nun einen Ringbus Stop und den L2 d.h. man hat nur bis zu 4 Threads die volle Performance. Danach wird es vermutlich einen Einbruch geben.
Jetzt nutzen die meisten Spiele heute bereits 8 Threads oder mehr.
Ich hätte ehrlich gesagt mit 16 P Cores gerechnet

c) Ob die 144MB L3 denselben Performanceschub bringen wie der VCache bei AMD daran habe ich meine Zweifel. Das Hauptproblem bei ARL scheint der lahme Ringbus zu sein wo schon die 36MB on Tile L3 langsamer ist als der VCache bei AMD. Wenn die 144MB jetzt auch noch auf einem anderen Tile sind dann gute Nacht.

HOT

2025-02-01, 20:22:52

Wieso sollte das ein Problem sein? Nehmen wir an, dass es ein eigenes Compute Tile mit 144MB gibt, dass dann mit 8+16 Kernen eingesetzt wird, das wär für Gaming doch ideal. Das würde selbst die höhere Speicherlatenz des SoC-Tiles maskieren.
Ich bin eher gespannt, ob AMD dann bei ihren 12-Kernern noch 64MB drunterstapelt oder ob es dann 96MB werden, das wären dann witzigerweise genau 144MB ;D.
Bei Intel ist das dann 12MB L3$ pro p-Kern/e-Cluster und bei AMD wären das dann 48MB L3$+ 96MB L3-Stack-$.

reaperrr

2025-02-01, 20:55:37

Ich bin eher gespannt, ob AMD dann bei ihren 12-Kernern noch 64MB drunterstapelt oder ob es dann 96MB werden, das wären dann witzigerweise genau 144MB ;D.
Die Frage stellt sich doch gar nicht, natürlich werden das 96 MB.
VCache besteht grundsätzlich aus zwei Schichten mit der jeweils gleichen Kapazität wie der L3 im CCD, damit man die vertikal gut verbinden und die Latenz gleichhalten kann.
Bei monolithischem 12C-CCD wäre alles andere als 48 MB L3 im CCD und 96 MB VCache ne Überraschung.

HOT

2025-02-07, 15:28:08

Gipsel

2025-02-07, 15:47:55

VCache besteht grundsätzlich aus zwei Schichten mit der jeweils gleichen Kapazität wie der L3 im CCD, damit man die vertikal gut verbinden und die Latenz gleichhalten kann.Ähm, nein. 32MB im CCD + 64MB in einer Lage im VCache-Die.

Zossel

2025-02-07, 17:01:12

Die Frage stellt sich doch gar nicht, natürlich werden das 96 MB.
VCache besteht grundsätzlich aus zwei Schichten mit der jeweils gleichen Kapazität wie der L3 im CCD, damit man die vertikal gut verbinden und die Latenz gleichhalten kann.
Bei monolithischem 12C-CCD wäre alles andere als 48 MB L3 im CCD und 96 MB VCache ne Überraschung.

Da hast du dir was an den Haaren herbei gezogen.

iamthebear

2025-02-08, 00:53:06

Wieso sollte das ein Problem sein? Nehmen wir an, dass es ein eigenes Compute Tile mit 144MB gibt, dass dann mit 8+16 Kernen eingesetzt wird, das wär für Gaming doch ideal. Das würde selbst die höhere Speicherlatenz des SoC-Tiles maskieren.

Intel 18A ist schweineteuer. Das wird Intel wohl kaum dafür verschwenden um SRAM zu produzieren der nicht skaliert.
Ich denke eher es gibt 36MB plus den Rest darauf/darunter/daneben in einem günstigeren Node.

Bei monolithischem 12C-CCD wäre alles andere als 48 MB L3 im CCD und 96 MB VCache ne Überraschung.

SRAM skaliert nicht mehr von N4 zu N3, Logik aber schon.
Ich hätte eher vermutet:
.) Gleiche Anzahl Transistoren pro Kern. Durch den neuen Node ca. 2/3 der Fläche
.) 50% mehr Kerne, somit bleibt die Gesamtfläche für die Kwrne ca. gleich
.) L3 bleibt bei 32MB da er nicht skaliert
.) Wieder 64MB oben drauf. Das hat sich schon bewährt.

KarlKastor

2025-02-08, 08:04:21

Drunter. ;)

basix

2025-02-08, 09:59:15

SRAM skaliert nicht mehr von N4 zu N3, Logik aber schon.
Ich hätte eher vermutet:
.) Gleiche Anzahl Transistoren pro Kern. Durch den neuen Node ca. 2/3 der Fläche
.) 50% mehr Kerne, somit bleibt die Gesamtfläche für die Kwrne ca. gleich
.) L3 bleibt bei 32MB da er nicht skaliert
.) Wieder 64MB oben drauf. Das hat sich schon bewährt.

32MB bei 12 Kernen wird sehr wahrscheinlich nicht passieren. Wenn dann vielleicht 36MB, das ist durch 12 teilbar ;)

Aber ich wäre auch bei 48MB L3$ bei 12 Kernen sowie 96MByte V-Cache:
- 32MB bei Zen 5 sind gerade mal ~15mm gross
- Du wirst sehen, das wird in N3P noch etwas kleiner werden. Versprochen ;)
- 4MB/Core hat man nun seit Ewigkeiten (z.B. SW-Optimierungen?)
- 48MB würden es erlauben, sich in Gaming von Standard Zen 5 abzusetzen
- Auf dem V-Cache Die von Zen 5 hat es noch viel Platz für mehr Cache. Und wenn man von N6 auf N4C umschwenken sollte noch mehr.
- Und ja, bei Zen 5 liegt das V-Cache Die unter dem CCD
- Beim 12C Die soll es sich um Client only handeln (Desktop und APUs), welche vermutlich die AVX-Unit abgestrippt haben werden. Evtl. ist es sogar ein Mix aus Big und Dense Cores, wer weiss. Damit spart man sich (bei Consumern unterausgelastete) Chipfläche

fondness

2025-02-08, 10:53:47

https://videocardz.com/newz/intel-nova-lake-preliminary-desktop-specs-list-52-cores-16p32e4lp-configuration

Offenbar bekommen auch die Desktop-Varianten 4 LP-Cores, das scheint jetzt über die gesamte Generation zu gehen - spart natürlich separate SoC-Tiles.
Die 16+32 Threads sind ja zwei Compute-Tiles, das wissen wir ja schon.

Zumindest scheint Intel endlich mal aufgewacht zu sein. Wenn ich schon Single-Threaded nicht mit kann, muss ich zumindest mehr Kerne liefern. So hat AMD mit Zen1 auch angefangen.

dildo4u

2025-02-08, 10:57:26

Intel hat doch Single Thread Gameing Kackt wegen Latenz ab über 80ns selbst mit allen Updates.

JSQ2pwhKyzA

Zossel

2025-02-08, 10:58:05

32MB bei 12 Kernen wird sehr wahrscheinlich nicht passieren. Wenn dann vielleicht 36MB, das ist durch 12 teilbar ;)
Der L3 bei den ZENs hat keine bevorzugten Bereiche für einzelne Cores daher ist es komplett latte ob da irgendwas durch was anderes natürlich teilbar ist.

Daher ist diese Aussage auch so allgemein nicht tragbar:
- 4MB/Core hat man nun seit Ewigkeiten (z.B. SW-Optimierungen?)

HOT

2025-02-08, 12:39:26

Es ist natrülich leichter, schon rein aufteilungstechnisch, wenn das CCD 48MB bekommt und genau das wird auch passieren. Ich denke 48+96MB ist die mit Abstand wahrscheinlichste Variante.

w0mbat

2025-02-08, 13:13:21

Zumal der L3$ mit Zen 5 auch viel dichter gepackt wurde. Vielleicht sogar in Vorbereitung von Zen 6 mit mehr L3$. Die Frage ist aber, ob X3D dann noch so viel bringt. 48MB L3$ wäre schon viel.

HOT

2025-02-11, 18:39:46

MLID leakte grad, dass sehr sicher das Top-NVL-Die nicht 18A ist sondern N2. Es gibt aber auch Gerüchte, dass alle NVL-Compute-Dies N2 sein sollen und dass die CPUs 100% TSMC-Fertigung sind. Das würde überhaupt nichts gutes für Intels Fertigung bedeuten.

reaperrr

2025-02-11, 18:48:10

MLID leakte grad, dass auf jeden Fall das Top-NVL-Die nicht 18A ist sondern N2. Es gibt aber auch Gerüchte, dass alle NVL-Compute-Dies N2 sein sollen und dass die CPUs 100% TSMC-Fertigung sind. Das würde überhaupt nichts gutes für Intels Fertigung bedeuten.
Jup, ne bessere Bestätigung dafür, dass 18A nicht auf Augenhöhe mit N2 ist, kann Intel gar nicht liefern...

Denn wegen ~10% Unterschied bei Kosten und/oder Perf/Effizienz würden sie das nicht machen.

Sie gehen nur so konsequent zu TSMC, wenn N2 ne ganze Kategorie besser ist und sie wissen, dass sie mit 18A gegen AMD chancenlos wären.

Edith: Ich würde sogar so weit gehen, dass es nach dieser News unsicher ist, ob 18A überhaupt N3E/P Paroli bieten kann, jedenfalls was Ausbeute und maximale Taktraten angeht.
Denn der Client-12C-Z6-CCD kommt wahrscheinlich "nur" in N3P.

HOT

2025-02-11, 18:51:43

Und/Oder dass 18A derart teuer ist, dass das schlichtweg nicht konkurrenzfähig ist.

fondness

2025-02-11, 18:54:53

Inhouse ist mit Sicherheit nicht teurer, denn sie müssen dann auch noch die Verluste der Foundry zahlen. Wenn man trotzdem zu TSMC geht sieht das ganz schlecht aus für 18A.

basix

2025-02-11, 19:12:46

Der L3 bei den ZENs hat keine bevorzugten Bereiche für einzelne Cores daher ist es komplett latte ob da irgendwas durch was anderes natürlich teilbar ist.

Bei einem teildeaktivierten Chip ist es vielleicht egal (6C an 32MB gehen auch), aber man wird aus rein designtechnischen und praktischen Gründen ein "symmetrisches" Design anstreben. Das heisst, eine 12C CPU wird 12x Anbindungen an den L3$ haben. Und dass man bei 12x Anbindungen sowie Cache-Controllern dann 12x Slices macht ist dann auch naheliegend. Und 12x Slices sind dann durch 12x teilbar. Ob dann 2, 2.5, 3, 4, 12MByte pro Core ist nicht relevant, es bleibt durch 12 teilbar. Geht man auf 10C / 8C salvage runter sind halt nur noch 8x Cache-Anbindungen aktiv aber da der Cache Unified ist, können auch eine reduzierte Anzahl Cores auf den ganzen Cache zugreifen. Also alles ganz normal und logisch.

Von dem her: Du bringst ein Argument, welches der Belastungsprobe nicht wirklich standhält ;)

Daher ist diese Aussage auch so allgemein nicht tragbar:
4MB/Core im Maximalausbau sind schön. >4MByte noch schöner ;) SW skaliert mit mehr Cache nicht plötzlich schlechter (z.B. wenn man von 8C auf 6C salvaged). Mit weniger Cache unter Umständen schon. Sieht man auch gut an den APUs, welche weniger Cache pro Core mitbringen. Die performen schlicht schlechter.

Ob SW nun sensitiv darauf reagiert ist ein anderes Thema. Da der L3$ ein unified Victim-LLC ist, ist es vermutlich nur halb so schlimm (L2$ wäre deutlich schlimmer). Zumindest in Consumer Anwendungen. Bei Server-Zeugs könnte es eher relevant sein (z.B. mehrere VMs mit 1C/4MB Slice vs. Noisy Neighbour Problem). Da das 12C CCD laut Gerüchten Client-Only sein könnte, wäre hier eine Anpassung der Cache-Grösse wahrscheinlicher als im Server-Bereich. Eine Grössenänderung ist nie unmöglich, aber bei Server hat man potentiell mehr Seiteneffekte da sehr oft mehrere Sachen parallel laufen.

reaperrr

2025-02-11, 20:12:26

SRAM skaliert nicht mehr von N4 zu N3, Logik aber schon.
Ich weiß.
Logik skaliert aber in N3E um immerhin 64-85%, je nach Anzahl Fins, und in N3P um nochmal 4%.

Der Logik-Anteil beim Zen5-CCD liegt bei grob 40-45 von 69mm².
Wenn man ne Skalierung von ~1.7x auf 40mm² Logik annimmt (Worst-Case), spart man mindestens 16mm² durch den Shrink.
Ein 8C-Zen5-CCD in N3P wäre also trotz identischer SRAM-Zellen nur noch ~53mm². Selbst wenn jetzt alles veranderthalbfacht wird, landen wir bei ~79mm².

Und oh Zufall, im Bereich 75-80mm² soll der Zen6-CCD liegen.

Dann gibt's halt diesmal weniger Transistor-kostende Verbesserungen am Kern selbst, oder Client bekommt nur noch 256bit-FPUs wie schon Strix Point.
Kommen die Leistungssteigerungen halt hauptsächlich vom größeren monolithischen L3 und höheren Taktraten, sowie Aufbohrungen im INT-Bereich, die nicht so teuer sind.

Inhouse ist mit Sicherheit nicht teurer, denn sie müssen dann auch noch die Verluste der Foundry zahlen. Wenn man trotzdem zu TSMC geht sieht das ganz schlecht aus für 18A.
Und stärken die härteste Foundry-Konkurrenz finanziell weiter.
Beides für wahrscheinlich mindestens weitere 2 Jahre.

Das grenzt schon an Kapitulation.

Kann fast nur heißen, dass sie eh planen die Intel Foundry endgültig auszugliedern.
Was für den Westen strategisch ne Katastrophe wäre, denn die Kostenstruktur von Intel Foundry kann man nicht mit GloFo vergleichen.
Wenn die nicht irgendwoher sowohl nen kompetenten CEO als auch ne fette Kapital-Spritze bekommen, werden die wahrscheinlich die Hälfte der Fabs einstampfen müssen, oder in einigen Jahren ganz eingehen.

stinki

2025-02-21, 14:17:46

Ich frage mich wieviel Watt diese 2*(8P+16E) Nova Lake CPU verbrauchen soll.
Und wie sie diese Watt-Zahl mit einem Backside Power Delivery Prozess in Intel 18A kühlen wollen.
Der Intel 18A Prozess muss ja phänomenal sein, wenn sie sich solch ein Produkt zutrauen.

Edit: Ich hatte die letzten Posts bezüglich N2 Gerücht gar nicht gelesen, sorry. Da macht N2 für Nova Lake für mich auf jeden Fall Sinn.

Undertaker

2025-02-21, 15:39:24

Ich frage mich wieviel Watt diese 2*(8P+16E) Nova Lake CPU verbrauchen soll.
Und wie sie diese Watt-Zahl mit einem Backside Power Delivery Prozess in Intel 18A kühlen wollen.

Das ist doch generell einzig und allein eine Frage des Arbeitspunktes, den ich bei MT beliebig nach unten skalieren kann - und dennoch bis zu einem gewissen Punkt immer Perf/Watt gewinne. Ein >250 Watt 14900K läuft auch super als 14900T bei 35 Watt mit phänomenaler Effizienz; die Frage ist wie immer nur, wie viele Transistoren und damit Geld ich investieren möchte.

dildo4u

2025-02-21, 15:42:00

iamthebear

2025-02-21, 18:45:29

Nach dem Intel 4/MTL Desaster (wo ja auch wunderbare Slides erstellt wurden) glaube ich Intelk Slides überhaupt nicht mehr solange es nicht fertige Produkte gibt.

y33H@

2025-02-21, 21:49:22

Welches Die in einer 18A oder N2 oder whatever Variante kommt, ist nicht einzig daran gekoppelt was der Node kostet oder wie er performt bzw wie effizient er ist. Alle drei Faktoren sind freilich relevant, es gilt aber den Kontext zu berücksichtigen - also welches Die für welches Segment zu welchem Zeitpunkt mit welchem Volumen zu welchem ASP benötigt wird ... für die K-SKUs etwa willst du den höchsten Takt und zuletzt kamen die immer zuerst, für die H-SKUs brauchst du vorrangig Perf/Watt und tendenziell mehr Volumen und sie erscheinen üblicherweise ein Quartal später.

Zossel

2025-02-22, 13:28:24

iamthebear

2025-02-22, 14:09:59

Kurz bzw. Mittelfristig macht es keinen Sinn 18A Kosten zu vergleichen.
Die Fabs stehen bereits. Intel hat die Kapazität, die sie haben und es geht darum diese bestmöglich zu nutzen. Ob Nova Lake nun in N2 oder 18A gefertigt wird hängt lediglich davon ab ob die eigene 18A Fertigung aisreicht oder nicht.

Das Thema "Kosten" wird erst relevant wenn es darum geht ob neue Fabs gebaut werden sollen oder nicht.

ChaosTM

2025-02-22, 14:15:13

Mir fällt dazu ein Lied aus meiner Jugend ein:

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

Auch ein alter Sack wie ich..

ich hoffe wirklich das Intel ihren "shit together" kriegt..
Wäre so wichtig für uns alle.

Zossel

2025-02-22, 14:23:03

y33H@

2025-02-22, 14:43:14

Apple hat das in der Vergangenheit bereits getan, Intel auch - wo ist das Problem?

iamthebear

2025-02-22, 20:08:47

Grundsätzlich schon aber vielleicht hat Intel hier andere Verträge bekommen, da TSMC sowieso davon ausgeht, dass firmenintern Dinge leaken und vorn herein nicht so viele Informationen teilt.

Zossel

2025-02-22, 21:24:13

ich hoffe wirklich das Intel ihren "shit together" kriegt..
Wäre so wichtig für uns alle.

Wenn Intel jetzt noch nicht weiß auf welchen Prozess eine CPU für 2026 gefertigt wird gehe ich davon das es noch länger dauern wird bis Intel seinen "shit together" kriegt.

y33H@

2025-02-23, 09:05:41

Und warum sollte Intel das noch nicht wissen? sollte das der Fall sein, dann würde NVL nicht 2026 erscheinen.

HOT

2025-02-23, 09:50:52

Das Design ist ja vor Jahren gestartet und das könnte auch erklären, warum N2 zum Einsatz kommen könnte, denn als der Designprozess begann konnte man mMn sich ja nicht darauf verlassen, dass 18A in dem großen Umfang zur Verfügung steht, der dafür benötigt wird. Anders als PTL, der ja auch durch ein Refresh zur Not hätte ersetzt werden können, ist NVL essenziell für Intel.

dildo4u

2025-02-23, 09:54:12

Könnten nicht die X86 Kerne von Intel kommen und die IGP von TSMC?
Panther Lake soll 18A nutzen aber die GPU kommt von TSMC.

ryan

2025-02-23, 10:01:52

fondness

2025-02-23, 10:47:41

Zossel

2025-02-23, 11:14:49

Ja heißt auf jeden Fall mal, dass der tsmc Prozess zumindest in gewissen Bereichen erhebliche Vorteile hat. Ansonsten würde sie nicht die eigenen Fab verhungern lassen und damit den gesamtkonzern gefährden. Wie gesagt der Gang zu tsmc ist hochgradig kontraproduktiv, der einzige Grund dafür kann nur ein erheblich bessere Ergebnis sein.

Und perspektivisch wird Intel nicht durch einen einzigen guten Prozess vor dem totalen Untergang gerettet werden, da ist konstante Execution (auf Neudeutsch) gefragt.

Der Cowboy der uns im allerletzten Moment rettet und danach in den Sonnenuntergang reitet ist eher was für Hollywood anstatt für eine Managementstrategie für eine Halbleiterbutze.
Und dann ist da noch die Versessenheit der Amis auf diese Monats- und Quartals-Berichte die für diese Branche eher kontraproduktiv wirkt, möglicherweise ist die USA einfach kein gutes Ökosystem für Halbleiterbutzen.

ryan

2025-02-23, 11:23:20

Ja heißt auf jeden Fall mal, dass der tsmc Prozess zumindest in gewissen Bereichen erhebliche Vorteile hat. Ansonsten würde sie nicht die eigenen Fab verhungern lassen und damit den gesamtkonzern gefährden.

Sie müssen Kapazitäten für Kunden freihalten, die können nicht sofort alles selber in 18A fertigen. In ein paar Jahren vielleicht.

fondness

2025-02-23, 11:27:13

Sie müssen Kapazitäten für Kunden freihalten, die können nicht sofort alles selber in 18A fertigen. In ein paar Jahren vielleicht.

Die fabs sind aktuell stark unterausgelastet. Man hat auch nicht ohne Grund alle Investitionen in höhere Kapazitäten wie das Werk in D gestrichen. Zumal man von Kunden aktuell nichts positives hört.

y33H@

2025-02-23, 13:28:29

Es gibt diverse Fabs und die allerwenigsten davon sind für 18A gerüstet, die Aussage ist also nicht wirklich haltbar. Der angesprochene erhebliche Vorteil von TSMC könnte ergo schlicht Kapazität zu einem bestimmten Zeitpunkt sein, aber nicht zwingend der "bessere" Node. Einer der öffentlichen Kunden für 18A ist übrigens Ericsson.

mocad_tom

2025-02-23, 15:10:18

Du kannst in die alten Fabs keine EUV Litho Maschinen reinparken.
Die neuen Fabs benötigen höhere Deckenhöhen.
Intel baut seit 2014 nur noch Fabs mit hohen Deckenhöhen.

So bei z.B. Arizona Chandler Fab 42 Baustart 2014.
Dann haben sie die Hülle eingemottet.
Damals haben sich Leute aufgeregt, dass man eine Fabhülle mit Steuergelder finanziert hat, um sie danach einzumotten.
2020 wurde sie als 10nm DUV-Fab in betrieb genommen, kann aber auf EUV umgerüstet werden.

Arizona wird jetzt dann mächtig:
Fab52 / Fab 62 mit EUV bestückt und Fab42 vorbereitet für EUV

gleichzeitig gibt es in Arizona
Fab 12 / Fab 22 / Fab 32 alle mit zu niedriger Deckenhöhe, also nur DUV
Aber mit Reinraum-Förderbänder miteinander verbunden.

In den EUV Prozessen werden nur 20% bis 25% der Layer mit EUV Maschinen belichtet.

Die anderen Layer werden mit DUV Maschinen belichtet.

Ich sage es mal ganz gerade heraus:
Parkt man in Irland, Arizona, Oregon in die Fabs 34 / 42 / 52 / 62 / D1X genug EUV Litho Maschinen rein, dann können die nebendranstehenden DUV-Fabs mit dazu helfen.
Damit kann man 30% der leading Edge Kapazität aus TSMC rauslotsen und zu Intel hinsteuern(plus Intels eigener Kapazitätsanforderungen).

An der Reinraumfläche mit genügend Deckenhöhe wird es nicht scheitern.

An der Fab in Ohio wird auch schon fleißig gebaut
Jhwjnrz4Hm8

Baufortschritt google maps in Ohio
google maps (https://www.google.de/maps/place/New+Albany,+Ohio,+USA/@40.1183885,-82.709406,1401m/data=!3m1!1e3!4m6!3m5!1s0x88385df8bc51c9b9:0xc7aba56b9dcb49dc!8m2!3d40.0821602!4 d-82.8100923!16zL20vMHl3emo?entry=ttu&g_ep=EgoyMDI1MDIxOS4xIKXMDSoASAFQAw%3D%3D)