Bericht Lakefield: Intels gestapelte Hybrid-CPU bietet 5 Kerne bei 7 Watt TDP

[Rockstar85]

@yummycandy
Nur ist Foveros stand heute eine Prozessarchitektur... Also Kann ich mir schon vorstellen, dass Intel die Compute Core Stapeln wird, aber Big.Litte macht da eben keinen Sinn..Dafür müsste Intel auch mal eben 90% des Softwaremarktes umstellen, und der Processsheduler in Windows endlich nicht mehr auf Stand 2000 sein xD (Okay Billy, er ist nicht ganz so schlecht, aber fast)

 

[Qarrr³]

Auf dem einen läuft halt ARM optimierte Software, auf dem anderen x86.

Ein Handy, das man am Monitor angeschlossen auch als PC verwenden könnte?

Aber warum muss das in einem package sein? Da kannst du doch auch zwei einzelne chips nehmen.

 

[Chismon]

Das - also in stromsparendem Stapel-/Foveros-Design und mit zwei unterschiedlichen Kerngruppen in einer CPU gepaart - koennte mitunter auch fuer Handheld-Konsolen in potenterer Ausgabe sehr interessant werden, bspw. als mittelfristige Alternative zu nVidia Tegras, wenn denn Nintendo (oder gar Sony) sich darauf einlassen wuerde.

Schoen zu sehen, dass Intel endlich 'mal wieder etwas innovatives bringt … so kann es gerne weiter gehen, 'mal schauen was die Tiger Lake APUs koennen werden und ich bin schon maechtig gespannt auf deren (grosse) dGPUs und wo man dort in den Markt erstmalig einsteigen wird (im Vergleich zur Konkurrenz von nVidia und AMD/RTG), zumal bei Ponte Vecchio auch Foveros zum Zuge kommen wird.

Each MCM GPU will be connected to high-density HBM DRAM packages through EMIB & will additionally feature a faster Rambo Cache close to them which will be connected through Foveros.

 

[LamaMitHut]

Aber warum muss das in einem package sein? Da kannst du doch auch zwei einzelne chips nehmen.

Können die sich dann auch so einfach den gleichen RAM / Grafikeinheit verwenden, oder in Sonderfällen als Co-Prozessor arbeiten?

 

[yummycandy]

@yummycandy
Dafür müsste Intel auch mal eben 90% des Softwaremarktes umstellen, und der Processsheduler in Windows endlich nicht mehr auf Stand 2000 sein xD (Okay Billy, er ist nicht ganz so schlecht, aber fast)

Genau das ist das Problem! Der Scheduler hat sich seit Win2000 nicht groß ändern müssen. Letztendlich sollten das MS und Intel aber hinbekommen, insofern sie denn wollen.

 

[andi_sco]

Mal ne andere Frage: wäre ein SoC mit 4 ARM + 4 x86 Kernen + GPU möglich / sinnvoll?

Hat AMD versucht und fallen gelassen:
Golem.de

...
Ein Handy, das man am Monitor angeschlossen auch als PC verwenden könnte?

Windows Continuum und Samsung Dex - beides leider nicht weit verbreitet, obwohl gerade Windows da eine Menge Potential hatte.
Leider hat MS den Support schnell eingestellt, so das nach einem Jahr keiner mehr da war, der sich um die 2 Jährige Garantie der Continuum Box gekümmert hat.

 

[LamaMitHut]

Hat AMD versucht und fallen gelassen:
Golem.de



Windows Continuum und Samsung Dex - beides leider nicht weit verbreitet, obwohl gerade Windows da eine Menge Potential hatte.
Leider hat MS den Support schnell eingestellt, so das nach einem Jahr keiner mehr da war, der sich um die 2 Jährige Garantie der Continuum Box gekümmert hat.

Danke dafür. Wär schon cool, wenn AMD das irgendwie wiederbelebt.

 

[qappVI]

Hat AMD versucht und fallen gelassen:
Golem.de

Android/Windows Dualboot? (Wenn's irgendwann vielleicht wiederkommt..)

 

[Kolu]

Wieso unterstützen die Mobile CPUS von AMD und Intel nie den neuesten RAM-Standard? LPDDR5 RAM ist schon lange verfügbar und würde vor allem bei Lakefield unglaublich viel Sinn machen. Ist die Entwicklungszeit einfach so unglaublich lang oder ist es einfach zu aufwendig im Nachhinein ein neuen RAM Standard zu integrieren?

 

[Krautmaster]

Dafür müsste Intel auch mal eben 90% des Softwaremarktes umstellen, und der Processsheduler in Windows endlich nicht mehr auf Stand 2000 sein

Nicht unbedingt. Am einfachsten wäre ja zB einfach die App im Vordergrund auf die High Performance Kerne zu legen. Schon hast fast jedem Task abgedeckt.

Der Wechsel selbst geht ja so fix, davon merkt der Anwender nichts.

Ggf kann die CPU auch selbst mitentscheiden was man worauf legt.

 

[Rockstar85]

Der Wechsel selbst geht ja so fix, davon merkt der Anwender nichts.

Ggf kann die CPU auch selbst mitentscheiden was man worauf legt.

Dafür brauchst du aber ein Co Processing. Aber für Idee fände ich schon nicht Schlecht. Wobei auch der Markt langsam in die breite geht. Ich sehe im Bereich Desktop und Server wenig, bis keinen Sinn.

Sehr wohl aber in Stacked Compute Cores

 

[Krautmaster]

Wie meinst du in die Breite geht?

Wenn der Markt zunehmend gen Multicore geht hast du von dem Ansatz der Little Cores ja eben noch mehr da du weit mehr Kerne in ein System bei gleicher Fläche und Energie integrieren kannst.
Je höher der Grad der Parallelität, umso kleiner kann man die Kerne machen. Hier reden wir von X86, abseits davon bist du bei enorm höher Parallelität dann wieder näher an der GPU als CPU.

Stand jetzt ist es immer ein Jonglieren aus hoher Leistung pro Thread und möglichst vielen Threads pro System.

Dass der Bedarf an Servern mit 1000 Atom Kernen ohne AVX mit nur 10% der Big Cores Leistung eher klein ist, da bin ich bei dir. Aber wenn die Atom Kerne / Little Kerne 70 oder 80% der Leistung der Big Cores erreichen wird's schon interessant. Gerade auch wenn man zB bei AVX Bedarf dann dynamisch auf den Big Core zurückgreifen kann.

 

[Piktogramm]

Das ist richtig, aber es kommt etwas ggf die Hirachie an. Wenn man versucht jeden Kern 100% gleich schnell an alle anderen anzubinden entsteht schnell overengineering.

Bei AMD funktioniert der CCX Ansatz ja auch gut.

Die kleinen Cluster aus 4 Atom Kerne die Intel hier nutzt muss man nicht so gut anbinden wie die einzelnen Big Cores am Ring. AMD hat von CCX zu CCX und Die zu Die auch sehr hohe Latenzen, aber man hat gelernt dass es bei Tasks wie Rendern quasi irrelevant ist da alles im Cache abläuft oder jeder Kern sein Set unabhängig von anderen rechnen kann. L3 federt das gut ab.

"Es kommt drauf an" ist immer eine gute Antwort
Ob es sinnvoll ist alle Kerne gleich anzubinden oder zu clustern hängt ja immer vom Anwendungsfall ab. Bei Aufgaben die viel Daten zwischen Threads austauschen müssen, ist ein gleichberechtigter Anbindung aller Cores sinnvoll. Bei Aufgaben die dies eher weniger benötigen kann man um so besser Clustern, ohne dass Leistung kostet. Sollte jedoch ein Job mit viel Interprozesskommunikation auf einem geclusterten System laufen, frisst das ganz massiv Leistung und/oder benötigt merklich Overhead beim Sheduling seitens des Betriebssystems.

Neu ist das alles nicht, bei Aufgaben die vergleichsweise wenig zufällige Speicherzugriffe und weniger Interprozesskommunikation benötigen landet man irgendwann bei Konstrukten die aussehen wie Intels Xeon Phi bzw. gleich GPUs und das andere Extrem hat Intel auch mit ihrem Interconnect als Grid und AMD baut clustert als Lösung irgendwo dazwischen.

Wenn Intel als zB das Mesh nicht auf einzelne Atom Kerne durchzieht und zb sie AMD 4er Cluster eine Ebene Darunter platziert die über den L3 reden dann hält man den Overhead klein, bindet statt einem Big die immer 4 kleine bei quasi gleicher Infrastruktur an.

Das bleibt ineffizient für Server. Da ist es im Zweifelsfall schlauer statt 4x µOpCache, Decoder, 16x 128bit SSE Register etc. pp. lieber einen dicken Core zu nehmen der möglichst gleich 16 256bit oder gar 5125bit Register mitbringt (AVX2 bzw AVX512) und dann richtig Durchsatz schafft wenn es ein einzelner Thread benötigt. Genauso kann ein dicker Core mit zeitmultiplexing auch 4 kleine Threads so gut abwickeln wie es 4 kleine Cores könnten (dank SMT beim dicken Core oft sogar besser).

 

[Krautmaster]

@Piktogramm

Schwer abzuschätzen. Ich denke AMD fährt ja gerade deshalb so gut da sie nicht diesem homogenen Ansatz von Intel verfolgen.

Es gibt eben wenig einzelne Anwendungsfälle die über 100 Threads am selben Workset mit hoher InterCore Kommunikation arbeiten.

Intels Best Case war soweit ich sehe lange die Datenbank die alles in dem homogenen L3 abfackeln.

Alles was Rednern, Virtualisierung usw angeht liegt aber schnell dem AMD Ansatz besser, da quasi vieles auf einzelne Numa Ebene innerhalb eines CCX / Chiplets ablaufen kann.

Ergänzung (10. Juni 2020)

Genauso kann ein dicker Core mit zeitmultiplexing auch 4 kleine Threads so gut abwickeln wie es 4 kleine Cores könnten (dank SMT beim dicken Core oft sogar besser).

Ist dem so? Gibt's da Quellen dazu?
Wenn Intel jetzt hier angibt dass die 4 Kerne die etwa so groß sind sie der 1 Big Core und etwa 80% leisten... Weiß nicht ob das SMT und ein großer Kern wirklich ausgleichen kann.

Das mag ggf vor Jahren so gewesen sein als der Big Core noch deutlich stärker war. Aber jede Iteration bringt weniger, doppelt so viel Cache bringt nur wenige % usw...

Denke die Peak Performance ist kleinen Einheiten immer besser. Deswegen hat ne GPU ja auch was Flops abgeht weit mehr auf dem Kasten und ist bei vielen Aktionen deutlich fixer als ne CPU aus noch so großen Kernen.

Ergänzung (10. Juni 2020)

Kann mir auch vorstellen dass man zB mit wenig Kernen bei AVX klar kommt, bei anderen Tasks aber eher mehr kleine Kerne ohne AVX vorteilhaft wäre.

 

[estros]

Welch Präzision erforderlich ist für diese Konstrukte, unglaublich. Das wird die Zukunft der Mikroprozessoren. Ganz klar, früher flippte man schon aus, dass der Chipsatz integriert ist, aber iGPU und Dram ist schon extrem geil. Für die Hersteller der Endgeräte wird es mit einem Sprung so viel einfacher.

Der Ram wird ja extern zugekauft, umso beeindruckender, dass das möglich ist.

 

[nazgul77]

interessant wird auch, wie PCs mit den unterschiedlich schnellen Kernen umgehen.

In der intel Fanboy-Welt ist offensichtlich noch nicht angekommen, dass es seit über neun Jahren Hardware mit dem Prinzip verschieden schneller Kerne gibt. Und der Linux-Scheduler hat sich der Thematik angenommen.

 

[Simon]

Was mich ja schon ein wenig wundert, dass es so wenig Launch-Produkte mit Lakefield gibt, angesichts der doch besonderen technischen Eigenschaften für eine x86-Architektur. Entweder läuft das Teil sehr bescheiden oder die OEMs sehen effektiv kaum einen Markt dafür.

Hätte Intel mal selbst zum Start wenigstens ne Compute Card damit bringen können oder sogar ein ultra-sparsames NUC-System als Alternative zu den Pentium Silver Modellen. Mit verlöteter SSD könnte man sich bei 7 Watt so ein Ding sogar fast im Zigarettenschachtelformat (Big Pack) passiv gekühlt vorstellen.

 

[andi_sco]

Wieso unterstützen die Mobile CPUS von AMD und Intel nie den neuesten RAM-Standard? ...

Gute Frage, der i7-8500Y von August 2018 unterstützt auch gerade mal LPDDR3/DDR3L
Bei Lakefield kommt noch hinzu, das es nur 64Bit sind, die zum Speicher führen.

Ergänzung (11. Juni 2020)

,,,,
Ist dem so? Gibt's da Quellen dazu?
Wenn Intel jetzt hier angibt dass die 4 Kerne die etwa so groß sind sie der 1 Big Core und etwa 80% leisten... Weiß nicht ob das SMT und ein großer Kern wirklich ausgleichen kann.
...

Hatte ich schon mal gepostet:

Beim Ryzen extra nur 4 Threads genutzt, damit es bei allen gleich ist. Beim Takt wurde es etwas schwieriger.

 

[Beitrag]

Aber warum muss das in einem package sein? Da kannst du doch auch zwei einzelne chips nehmen.

Hier kann man nicht nur von einem einzelnem Package reden, sondern sogar von einem einzelnem Chip. Stapeln ist generell eine gute Idee. Hast du zwei separate Chips, musst du Leitungen zwischen diesen verlegen und die sorgen für Verzögerungen. Hast du einen einzelnen Die oder direkt aufeinander gestapelte, dann hast du viel kürzere Verbindungen und so einen Latenzvorteil.
Außerdem sparst du natürlich enorm viel Platz, wenn du mehrere flächige Chips aufeinanderstapelst und Platz ist insbesondere für Mobilgeräte wichtig. Auch Speicher lebt davon - so viel, wie man da heute stapelt wären einzelne nicht gestapelte Dies vermutlich kaum noch sinnvoll bei dem Platzverbrauch und Verdrahtungsaufwand.
Nachteilhaft ist eigentlich nur, dass es eben teilweise technisch aufwändiger ist und dass man durch Stapeln schnell ein Temperaturproblem bekommen würde, wenn man das bei stromhungrigeren ICs versuchen würde. Aber im einstelligen Wattbereich ist das harmlos.

 

[andi_sco]

Zum Thema AVX: