News Intel-CPU-Gerüchte: Alder Lake-S mit 16 Kernen nach big.LITTLE-Prinzip

[Jesterfox]

Wieso sollte das SMT ersetzen? Das hat doch eine völlig andere Zielsetzung.

 

[xexex]

Wieso sollte das SMT ersetzen? Das hat doch eine völlig andere Zielsetzung.

Die Zielsetzung ist identisch! Zusätzliche Leistung und eine bessere Auslastung der CPU mit einem geringen Bedarf an zusätzlicher Chipfläche.

Wieso es SMT ersetzen wird? Weil man die Probleme mit ZombieLoad und Co. nicht anders 100% in den Griff bekommt ohne dabei Leistung einzubüßen. Sobald sich zwei Kerne den selben Cache teilen, gibt es ein Sicherheitsproblem und wenn sich zwei komplett unterschiedliche Tasks einen Kern teilen, verliert man oft Leistung statt welche dazu zu
gewinnen.

According to a November 2009 analysis by Intel, performance impacts of hyper-threading result in increased overall latency in case the execution of threads does not result in significant overall throughput gains, which vary[20] by the application. In other words, overall processing latency is significantly increased due to hyper-threading, with the negative effects becoming smaller as there are more simultaneous threads that can effectively use the additional hardware resource utilization provided by hyper-threading.[23] A similar performance analysis is available for the effects of hyper-threading when used to handle tasks related to managing network traffic, such as for processing interrupt requests generated by network interface controllers (NICs).[24] Another paper claims no performance improvements when hyper-threading is used for interrupt handling.[25]
https://en.wikipedia.org/wiki/Hyper-threading

Es gibt nicht umsonst oftmals die Empfehlung HT komplett abzuschalten, sei es aus Leistungsgründen oder Sicherheitsgründen und wenn man sich die CPUs anschaut, braucht man hier auch nicht weiter zu spekulieren.

Das sind die identischen Konfigurationen wie Intel sie seit längerem einsetzt.

Man könnte auch meinen Intel bezeichnet schlichtweg HT anders und so abwegig das klingen mag, unmöglich wäre es nicht einmal.
i9-9900K - 8+8+1
i7-9700F - 6+0+0

Wieso nicht?

 

[Jesterfox]

Öhm... das Ziel von big.LITTLE ist nicht mehr Leistung sondern weniger Stromverbrauch. Üblicherweise ist doch auch immer nur einer der beiden Cluster aktiv, oder?

Und Zombieload ist doch ein reines Intel-Problem das weder AMD noch andere CPU Hersteller (die teilweise sogar mehr als 2 Threads auf einem Core haben) haben.

 

[Teralios]

Gerade da ist es mitunter ratsam, Hyperthreading auszuschalten ... oder zumindest war das so, als ich mich zuletzt damit auseinander gesetzt habe.

Wenn wir ehrlich sind, ergibt es auch aktuell noch durchaus Sinn in bestimmten Szenarien SMT zu deaktivieren, wenn man die maximale Leistung haben möchte, da ja mehr Threads als vorher sich den Kern im gleichen Slice teilen müssen.

SMT dient weiterhin primär der besseren Auslastung der Kerne, wenn ein Thread jedoch entsprechende Ressourcen braucht, ist es immer besser, wenn er den Kern auch während seines Slices für sich hat.

Daher meine Skepsis.

Der Nutzen von Big.Little steht und fällt mit dem Scheduler sowie der Firmware des Prozessors. Skeptisch kann man hier durchaus sein, ändert aber nichts daran, dass das Konzept als ganzes nicht unbedingt schlecht ist.

Bis Heute ist der MS Scheduler bzgl SMT/HT oder "alternativen" Ansätzen wie ZEN 1 (Uma/Numa plus Speicheranbindung) eher bescheiden oder Müll.

Kommt bei dir auch mehr als nur Halbwissen und Spekulationen, oder bleibt es auf diesem schwachen inhaltlichem Niveau nach diesem sinnfreien Seitenhieb?

Den Absatz deines Vorposters @Teralios in Sachen MS Scheduler ist an Schönschreiberei kaum zu überbieten.

Anscheinend aber nicht, wenn man sich dann folgendes durch ließt:

Man möge sich die Frage stellen, warum AMD nach ZEN 1, nichts eiligeres zu tu hatte als mit ZEN 2 wieder wegzukommen von der "Abhängigkeit" eines guten Schedulers?

Selbst unter Linux ist Zen 1 mit seinem NUMA-Aufbau alles andere als optimal gewesen, auch wenn der Scheduler dort mit NUMA relativ gut umgehen kann. Aber auch das hat einige Jahre an Entwicklung benötigt, bis der Scheduler es brauchbar konnte. Du kannst dir ja mal die Patches für den Scheduler ansehen, die über die letzten Jahre eingepflegt wurden.

Der Aufbau von Zen 1 in den Epyc-Prozessoren ist auch nicht in diese Richtung hingeändert worden, weil der MS-Scheduler schlecht war/ist, sondern weil der Aufbau von Zen 1 allgemein einige Nachteile hatte, egal wie gut der Scheduler damit umgehen kann. Die NUMA-Komplexität mit Zen 1 bei 2 Sockeln ist mit 8 NUMA-Domains (Nodes) und 3 Distance (Sprüngen) selbst im Serverbereich alles andere als wirklich prall gewesen.

Egal wie gut der Scheduler ist, es gibt hier Unschönheiten, vor denen der Scheduler nicht schützt. Gerade wenn benötigte Daten im RAM eines anderen Nodes liegen, mussten entsprechend einige Sprünge ausgeführt werden, bis man die Daten anfordern konnte. Zen 1 war einfach sehr Komplex.

Aber wie gesagt, bis auf viel Halbwissen und plakative Aussagen hast du hier nicht abgeliefert. Wenn du schon meinst Seitenhiebe zu verteilen, dann mache es bitte fachlich Kompetent, statt auf so einer plumpen und platten Ebene.

Ich habe nämlich nur eines geschrieben: Dass der Windows Scheduler immer besser wird. Nicht mehr nicht weniger und das wiederum ist eine Tatsache, da auch Microsoft entsprechend Erfahrung sammelt und ihren Scheduler an neue Gegebenheiten anpassen muss.

Und hier kommen wir halt nun zu einem wichtigen Punkt: Windows hat einen ganz gewaltigen Nachteil, weswegen man da über gewisse Szenarien kaum nachdenken musste bisher: Die "Verbreitung". Windows läuft in der Regel auf Endanwenderrechner und auf relativ einfachen Servern, alles, was komplexer wird, fährt auf einer *nix-Instanz, sei es BSD, Linux oder andere Derviate und entsprechend sind dort die Scheduler auch auf entsprechende Aufgaben hin optimiert.

MS steht hier einfach auch was Erfahrung angeht hinten an. Aber selbst unter Linux läuft das alles nicht SO reibungslos, wie man es nun hier hinstellt. Auch dort musste der Scheduler an die Eigenheiten von Zen 1 damals angepasst werden. Hier merkt man halt, dass man im OpenSource-Bereich auch mal schneller auf solche Eigenheiten reagieren kann.

Selbst der Linux-Scheduler wird also, sollte Intel entsprechend das Big.Little-Konzept bringen, ihren Scheduler anpassen müssen. Hier ist halt der Vorteil, dass mit Android eine gewisse Vorarbeit geleistet wurde. MS reagiert hier leider immer nur, wenn das Kind schon in den Brunnen gefallen ist, wobei hier auch die Frage ist, in wieweit AMD und Intel mit MS zusammen arbeiten. Hier könnte auch mal wieder das Problem sein, dass AMD zu wenig Ressourcen hat MS direkt zu unterstützen oder es nicht direkt von Anfang an macht.

Der Linux-Scheduler profitiert massiv davon, dass hier die HPC-Entwickler und den ganzen SuperComputern einfach viel mehr Erfahrung vorhanden ist.

Wie geschrieben, wenn du schon Seitenhiebe verteilen willst, mach es bitte richtig, statt mit soviel Halbwissen und plakativen Aussagen, die nur ein Teil der Problme darlegen, nur damit du irgendwas erwidert hast. Danke!

Ja, nur warum braucht man dann für Office 8 langsame Kerne, da reichen auch 4. Siehe Atom.

In dem Fall kommt es darauf an, welchen Weg Intel für ihr Big.Little-System wählen will. Wählen sie Weg 1 oder 2, so sieht man nach Außen nur "8"-Kerne und die CPU selbst entscheidet dann anhand des Workloads fließend, ob nun noch der Little-Kern reicht oder ob man zum Big-Kern wechselt.

In Variante 1 und 2 wäre zudem der Software-Scheduler erst mal raus, erst beim 3. Weg entscheidet das Betriebssystem, welcher Kern genutzt wird.

Der MS Sheduler ist auch meiner Meinung nach nicht immer der schnellste, wenn es darum geht sich an neue Hardware anzupassen, Beispiele nennst du ja selber. Ich würde aber nicht ausschließen, dass mit neuer Hardware und mehr Kompatibilität seitens MS hier ein Umdenken einsetzt und man künftig schneller und besser reagieren will.

MS wird in Zukunft wohl umdenken müssen, besonders wenn sie auch weiherhin Windows on ARM verfolgen wollen.

Man merkt hier halt, das MS die Erfahrung aus dem HPC-Markt fehlt. Linux hat hier halt echt massive Vorteile, weil viele Firmen, die SuperComputer bauen, aber auch Betreiber ihre Patches am Scheduler nach und nach eingepflegt haben über die letzten Jahrzehnte.

Windows ist da einfach ins Hintertreffen geraten.

Wenn ich das richtig sehe, gibt es Szenarien, wo der little Verbund mit 4 Kernen effizienter ist, als der eine BIG Core.

Die gibt es auf jeden Fall und je nach Konzept ist halt der Software-Scheduler erst mal aus dem Schneider, man wird hier aber abwarten müssen.

 

[xexex]

Üblicherweise ist doch auch immer nur einer der beiden Cluster aktiv, oder?

Nein! Es ist nur eine der Möglichkeiten eine solche Lösung anzusprechen, die aber kaum unter Windows zum Einsatz kommen wird. Ziemlich sicher werden wir stattdessen sowas sehen.

https://en.wikipedia.org/wiki/ARM_big.LITTLE#Heterogeneous_multi-processing_(global_task_scheduling)

Und Zombieload ist doch ein reines Intel-Problem das weder AMD noch andere CPU Hersteller (die teilweise sogar mehr als 2 Threads auf einem Core haben) haben.

Auch nein! Die Nutzung von gemeinsamen Caches in den CPUs, ist eine tickende Zeitbombe die eigentlich alle CPU Hersteller betrifft, davor gewarnt wurde schon seit fast 20 Jahren und ist nicht exclusiv auf Intel und auch nicht exklusiv auf x86 Prozessoren beschränkt.
https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final79.pdf
https://www.blackhat.com/docs/eu-16...ks-Software-Level-Security-And-Privacy-wp.pdf

Diese Attacken wird es immer geben und die Gegenmaßnahmen führen letztlich dazu, dass der geringe Leistungsvorteil von HT am Ende noch geringer wird. Wieso nicht dann gleich etwas mehr Chipfläche wie aktuell bei HT "opfern" und dafür mehr Leistung ohne die Sicherheitsprobleme bekommen?

Schaut man sich Lakefield an, brauchen vier "little" Dies ungefähr genauso viel Platz wie ein "big" Die.

Wenn man damit 50% mehr Leistung bekommt, statt den optimistichen 25% bei HT, so kann man diese Lösung durchaus sehr gut vertreten.

Rechnerisch gesehen kommen dann halt für jeden großen Kern, 25% an Chipfläche für die kleinen Kerne dazu, statt den 5-10% für Hyper-Threading.

 

[Palomino]

Wen juckt der Stromverbrauch im Rechner. Lieber 16 schnelle Kerne als so ein Handyprozessor.

Wahrscheinlich mehr Menschen als man glauben mag, besonders in Firmen/Rechenzentren ist der Stromverbrauch nicht unwichtig. Und dann ist der Preis auch nicht ganz unwichtig. Wozu als Gamer einen Ryzen 3950 kaufen, wenn Du mit dem 3700 die gleiche Leistung erzielst?


Einen Punkt wurde aus meiner Sicht hier nocht nicht wirklich mit in Betracht gezogen: Die Kosten für den Prozessor. 8/8 dürfte wohl günstiger in der Herstellung sein als 16 große Kerne. Und so kann man auch den Ausschuss in der Produktion deutlich verringern.

 

[andi_sco]

...
Üblicherweise ist doch auch immer nur einer der beiden Cluster aktiv, oder?
...

Wird sich zeigen, was intel da auftischt

 

[latiose88]

Die Zielsetzung ist identisch! Zusätzliche Leistung und eine bessere Auslastung der CPU mit einem geringen Bedarf an zusätzlicher Chipfläche.

Wieso es SMT ersetzen wird? Weil man die Probleme mit ZombieLoad und Co. nicht anders 100% in den Griff bekommt ohne dabei Leistung einzubüßen. Sobald sich zwei Kerne den selben Cache teilen, gibt es ein Sicherheitsproblem und wenn sich zwei komplett unterschiedliche Tasks einen Kern teilen, verliert man oft Leistung statt welche dazu zu
gewinnen.


Es gibt nicht umsonst oftmals die Empfehlung HT komplett abzuschalten, sei es aus Leistungsgründen oder Sicherheitsgründen und wenn man sich die CPUs anschaut, braucht man hier auch nicht weiter zu spekulieren.
Anhang anzeigen 886140

Das sind die identischen Konfigurationen wie Intel sie seit längerem einsetzt.
Anhang anzeigen 886141

Man könnte auch meinen Intel bezeichnet schlichtweg HT anders und so abwegig das klingen mag, unmöglich wäre es nicht einmal.
i9-9900K - 8+8+1
i7-9700F - 6+0+0

Wieso nicht?

Ah OK gut zu wissen. Das erklärt auch warum beim smt abschalten beim threadripper 2970wx,2990wx und auch beim 3960x Leistung kostet beim videoumwandeln ist wohl genau dieser Fall eingetreten. Wird wohl auch beim 3970x ebenfalls mit seinen 32 Kernen der Fall sein. Aber wie kommt es das es Leistung kostet bei so vielen threads und bei ner Halbierung es dann Leistung ergibt. Warum bremsen zwei Instanzen auf einem Kern so dermaßen die Leistung? Ich hoffe du kannst mir da ne Erklärung davon geben. Es handelt sich um das Programm xmedia recode beim H264 umwandeln von kleinen Aufnahmen, keinen hochauflösenden. Sogar full HD sehe ich beim Video als hochaufend an.

 

[xexex]

Warum bremsen zwei Instanzen auf einem Kern so dermaßen die Leistung?

Gründe für all deine Fragen sind durchaus unterschiedlich, aber das Hauptproblem von HT ist leicht zu erklären, es teilen sich nun mal zwei parallel laufende Prozesse die gleichen Ressourcen.

Der Vorteil von HT ist, Daten die von dem einen Prozess angefordert werden, liegen im Optimalfall für den zweiten Prozess bereits im Cache. Da der Zugriff auf den Speicher die CPU immer am stärksten ausbremst, ergeben sich hierzu Geschwindigkeitsvorteile. Umgekehrt sieht es jedoch aus, wenn auf dem geteilten Kern zwei komplett unterschiedliche Prozesse laufen, dann "klauen" sich die Prozesse letztlich gegenseitig die Ressourcen.

Bei einer Anwendung wie Videobearbeitung sollte das eigentlich unkritisch sein, bei dir kommt ein ganz anderes Problem ins Spiel, ich behaupte dafür gab es explizit einen Artikel bei Computerbase.
https://www.computerbase.de/2018-08...hnitt_32_kerne_machen_im_alltag_noch_probleme
https://www.computerbase.de/2020-02...nitt_in_windows_2__64_threads_in_zwei_gruppen

 

[McLovin14]

Wenn ich das richtig verstanden habe erhoffen sich viele hier davon eine Reduzierung der Leistungsaufnahme in wenig anspruchsvollen Anwendungen. Als Vergleich wäre ja mal interessant, was ein aktueller Top-Prozessor, wie der i9-9900k oder auch ein Ryzen R9 3900, in Office Anwendungen oder beim Surfen verbrauchen. Hat da jemand genaue Werte? Davon ausgehend könnte man ja grob ein Potential abschätzen.

 

[latiose88]

Gründe für all deine Fragen sind durchaus unterschiedlich, aber das Hauptproblem von HT ist leicht zu erklären, es teilen sich nun mal zwei parallel laufende Prozesse die gleichen Ressourcen.

Der Vorteil von HT ist, Daten die von dem einen Prozess angefordert werden, liegen im Optimalfall für den zweiten Prozess bereits im Cache. Da der Zugriff auf den Speicher die CPU immer am stärksten ausbremst, ergeben sich hierzu Geschwindigkeitsvorteile. Umgekehrt sieht es jedoch aus, wenn auf dem geteilten Kern zwei komplett unterschiedliche Prozesse laufen, dann "klauen" sich die Prozesse letztlich gegenseitig die Ressourcen.

Bei einer Anwendung wie Videobearbeitung sollte das eigentlich unkritisch sein, bei dir kommt ein ganz anderes Problem ins Spiel, ich behaupte dafür gab es explizit einen Artikel bei Computerbase.
https://www.computerbase.de/2018-08...hnitt_32_kerne_machen_im_alltag_noch_probleme
https://www.computerbase.de/2020-02...nitt_in_windows_2__64_threads_in_zwei_gruppen

Nun ich hand mir zwar die links noch nicht angeschaut, werde ich ja noch nachholen. Das Problem was ich habe ist, daß diese Anwendung nicht vom Arbeitsspeicher profitiert. Ich starte darum auch ne zweite Instanz also sprich 2x xmedia recode und wandle dann mit diese Software dann gleichzeitig um. Und das zwei unterschiedliche aufnamen. Ich wusste ja nicht das da ht bzw smt solch hohe Auswirkung haben würde.

 

[xexex]

Das Problem was ich habe ist, daß diese Anwendung nicht vom Arbeitsspeicher profitiert. Ich starte darum auch ne zweite Instanz also sprich 2x xmedia recode und wandle dann mit diese Software dann gleichzeitig um.

Stelle dir einfach mal vor du hast 16 physikalische und 32 virtuelle Kerne. Applikation A schnappt sich nun die "ersten" 16 und bekommt vom System jeweils den virtuellen Kern 0 von jedem physikalischen Kern zugewiesen, die Applikation B nimmt sich nun auch 16 Kerne und bekommt den virtuellen Kern 1 von jedem physikalischen Kern zugewiesen.

Wenn nun Applikation A Daten in den Cache anfordert um sie zu bearbeiten, muss sie warten bis sie mit der Arbeit beginnen kann, Wenn danach Applikation B etwas bearbeiten will, wirft sie die Daten der Applikation A aus dem Cache, wartet ebenfalls und kann erst dann selbst was tun.

Das wäre ein "worst case" der so eigentlich nicht auftreten sollte, durchaus aber je nach eingesetzter Software auftreten kann. Von mir dann aber genug OT an dieser Stelle, es gibt genug Threads hier im Forum, wo du bessere Hilfe zu dem Problem bekommst.

Ergänzung (9. März 2020)

Wenn ich das richtig verstanden habe erhoffen sich viele hier davon eine Reduzierung der Leistungsaufnahme in wenig anspruchsvollen Anwendungen.

Das ist nur eines der Vorteile, die für eine solche CPU sprechen und in meinen Augen auch der geringste Vorteil, bei einer CPU die rein für den Desktop entwickelt wurde.

Das Hauptproblem aktueller CPUs ist schlichtweg das Power Budget, was ihnen bei Vollast zur Verfügung steht, weshalb zum Beispiel ein 3950X bei Vollast niedriger taktet als ein 3800X und die hohen Boostraten nicht einmal im Ansatz bei Last auf vielen Kernen gehalten werden können.

Das Problem dabei ist jetzt, du verbaust in einer solchen CPU 16 gleichwertige Kerne, die gleich viel kosten, gleich viel Strom verbrachen und gleich viel Flache "verschwenden", obwohl du weiß, dass du nie die volle Leistung, die du mit einem Kern bei 4,7Ghz erreichen würdest auf allen Kernen abrufen kannst.

Die Frage die sich da als erstes stellt, wieso dann überhaupt den Platz verschwenden? AMD könnte hier jetzt einfach ein gutes Die mit Kernen die 4,7Ghz erreichen und ein schlechtes Die mit Kernen die nur 4Ghz erreichen kombinieren (was sie so ähnlich auch machen) und niemand würde es merken. Sie würden dadurch aber weder Platz sparen noch den Energiebedarf senken.

Nun nehmen wir uns mal die Grafiken von vorhin nochmal zu Brust.

Man kann statt 16 gleichwertigen Kernen auch 8 grosse und 8 kleine verbauen. Die kleinen leisten zwar nur 50-60% der grossen, verbrauchen aber nur 25% der Fläche und weniger Energie. Wenn die CPU dadurch dann nicht mehr von 4,7Ghz auf 3,5Ghz abgebremst werden muss um den Strombedarf im Rahmen zu halten, hat man praktisch gleiche Leistung trotz reduzierter Kosten und zusätzliche Vorteile bei Szenarien mit wenig Last.

Gehen wir noch weiter diesen Weg, wird die "Verschwendung" noch größer!

Ein Threadripper 3990X fährt trotz einer TDP von 280W auf allen Kernen "nur noch" 2,9Ghz, unter Vollast wird also gut 40% der potentiellen Leistung jedes einzelnen Kerns nicht genutzt. Theoretisch gesehen könnte AMD hier also vier "richtige" Zen Dies und einen Zen "mini" Die mit 32 "little" Kernen einsetzen ohne Leistungsverlust aber bei stark reduzierten Kosten.

Wenn sich das Gerücht bestätigt, wird Intel in der Zukunft genau diesen Weg gehen und im Notebook, PC und höchstwahrscheinlich auch im Serversegment darauf setzen. Man hat ja auch mit Foveros und Co-EMIB ja massiv in Richtung "zusammengefügter" CPUs entwickelt und so könnte man wunderbar unterschiedliche Kerne oder gar Fertigungsprozesse miteinander kombinieren.

 

[Krautmaster]

Wenn wir ehrlich sind,...

Guter Post. Danke dafür.

Ich finde Big Little kann je nach Szenario sicher noch mehr Vorteile haben, aber es macht das Wesen CPU auch sehr komplex.
ZB Games haben auch oft Threads die weniger stark belastet und und die ganzen Parallelität hängt letztlich an einem Threads der alle anderen ausbremst. Da könnte die Aufgabe genauso schnell laufen wenn auch die kleinen Kerne mitrechen solange der limitierende Thread auf dem richtigen Core liegt. Ist auch beim Szenarien wie FFMPEG so, nicht alles benötigt gleich schnelle Kerne.

Generell dürfe die Leistungsdichte bei kleinen Kernen bei perfekter Auslastung um ein Vielfaches höher sein. Doppelter Cache usw bringt ja nur wenig mehr Power. Für hochparallele Aufgaben ist also ein 100C little Core CPU sicher kleiner, schneller und effizienter als ein 28C BigCore CPU.

Dennoch Frage ich mich ob dieser Aufwand bei Intel wirklich lohnt. Denke es wäre zielführender die Homogenität beizubehalten, von ultra Low Power Szenarien Mal abgesehen. Dann lieber ein intelligentes Multi Chip Design, ggf im Mesh, Perfekt skalar.

Zum Thema Scheduler. Der muss immer mehr überwachend agieren, zB Performance und Verbrauch monitoren und dann verschiedene Prozesse zuweisen. Das wird schnell sehr komplex. Das geht sicher sogar soweit dass schon ich als Entwickler ggf sagen kann ob ich meinen Prozess auf Big für little laufen lassen will, also meine SW schon auf die CPU optimiere.

 

[SirSilent]

Alder, Intel fällt wohl nichts besseres mehr ein..

 

[Chismon]

Erst einmal warten wie gut Lakefield wird, welches sicherlich auch Prioritaet hat, da der auf Effizienz ausgerichtete Mobil-PC Markt dort doch deutlich groesser sein duerfte als beim Desktopbereich.
Eventuell waere das interessant fuer SoCs, aber im klassischen Desktopbereich, vielleicht im Einstiegsbereich (wenn es dann irgendwann billig genug herstellbar wird) oder als zukuenftige Alternative zu Lower Power ARM-Servern?.

Wenn Lakefield etwas wird, gehoert Foveros (und daran angelegten Stapelarchitekturen) aber sicherlich die Zukunft und so gesehen finde ich es schon gut, dass Intel in dem Bereich forscht/investiert, denn irgendwie muss es ja architekturtechnisch weitergehen, ewig mehr Kerne (wenn ein Grossteil der Software diese nicht ansatzweise ausreizt) bringt ja auch nichts und der Nodenspielraum wird auch zunehmend kleiner.

 

[WinnieW2]

Ich spekuliere mir mal was zusammen.

Da Alder Lake wohl erst 2022 auf den Markt kommen wird, und Intel seine CPU-Architekturen-Roadmap nicht mehr ändert,
dann wird Alder Lake auf den CPU-Architekturen Golden Cove (Big) und Gracemont (Little) basieren.

Könnte es sein dass Intel bei Golden Cove auf Hyperthreading verzichtet und stattdessen die Single Thread IPC hochschraubt? Dürfte zwar recht aufwendig werden, aber wenn die Chips im 7 nm Verfahren gefertigt werden dann sollte sich die Chipfläche bei 8 Golden Cove und 8 Gracemont + GPU zumindest noch in erträglichem Rahmen bleiben, wobei die GPU und der L3 Cache auf einem separaten Chip "ausgelagert" werden könnten.

Ich kann es ohnehin kaum nachvollziehen wie das mit der Threadumschaltung funktionieren soll falls die Big Cores SMT haben, die Little-Cores aber nicht.
Das ist das was mich auch bei Lakefield wundert. Weshalb hat Intel bei dem einzelnen Sunny Cove Kern das Hyperthreading nicht aktiviert? Eine Unvereinbarkeit mit dem Threadscheduler, evt.?

Wäre es praktikabel und sinnvoll die Little Cores und die Big Cores auf separaten Dies zu platzieren und diese per ultraschnellen Datenlinks zu verbinden?

 

[andi_sco]

...
Anhang anzeigen 886198

Man kann statt 16 gleichwertigen Kernen auch 8 grosse und 8 kleine verbauen. Die kleinen leisten zwar nur 50-60% der grossen, verbrauchen aber nur 25% der Fläche und weniger Energie. ...

So sieht es aus, wenn ein Pentium N gegen einen i5 antritt, wobei hier die Schwierigkeit besteht, ob der Pentium wirklich nur 6W TDP hat oder Asus dauerhaft 10W zulässt, dafür hat der i5 -0,025V gegenüber Standard:

Der i5 wurde mit Hilfe des XTU auf -0,025V und einmal 18W und einmal 8W eingestellt.
Es trifft hier auch 22nm (i5) gegen 14nm (Pentium).
Zum Vergleich wurde noch ein Ryzen 5 2500U auf 1,6GHz gedrosselt und mit 4Threrads durch den CineBench gejagt.

Fazit: der Little Core kann Vorteile bringen, die aber schnell dahin schwinden, sobald ein paar W an höherer TDP erlaubt sind.
Und ja, mir ist bewusst, das es ein schwieriger Vergleich ist!

 

[Hayda Ministral]

Worin soll der Sinn liegen, starke und schwache Kerne zu kombinieren?
Rein logisch ist der Versuch zum Scheitern verurteilt, oder möchte Intel AMDs Bulldozer Design neu auflegen?

Da verwechselst Du was. Bulldozer kombinierte 8 schwache Kerne mit einer extrem hohen Leistungsaufnahme und ergab in Summe eine passable Fußheizung mit der Performance eines Tastaturprozessors.

 

[Shrimpy]

Sehe nicht was ich mit 8 kleinen Kernen am Desktop soll.
16+2 oder 4 kann ich noch nachvollziehen wenn die kleinen Cores die Windows Dienste und Hintergrundprozesse bedien ggf. Desktop betrieb, dafür muss das parallel laufen, ansonsten greif ich mir gleich lieber 16 richtige Cores am Desktop.

8 kleine und 8 große kommt für mich eher so rüber wie;
wie melken wir die User am besten mit "16" Cores...
Das 4Cores sind genug geblubber vergesse ich nicht so schnell.

@Hayda
Blabla, der 8350 war in Sachen P/L passabel mit allen Threads angesprochen, bis zur i7 4000er Serie.
Aber ja miese Gaming CPU, wobei er jetzt besser da steht als die 4cores von damals.
Als Zocker PC hats sich natürlich trotzdem nicht gelohnt.

 

[andi_sco]

...
Das ist das was mich auch bei Lakefield wundert. Weshalb hat Intel bei dem einzelnen Sunny Cove Kern das Hyperthreading nicht aktiviert?
...

Sicher, das er kein HT unterstützt? Man findet auch Quellen, wo HT angegeben ist.