Northstar2710
Admiral
- Registriert
- Aug. 2019
- Beiträge
- 7.431
Dann wird HT jetzt durch kleine Cores ersetzt?!. Nette Idee um eine Sicherheitslücke zu schließen
News Intel-CPU-Gerüchte: Alder Lake-S mit 16 Kernen nach big.LITTLE-Prinzip
- Ersteller Volker
- Erstellt am
- Zur News: Intel-CPU-Gerüchte: Alder Lake-S mit 16 Kernen nach big.LITTLE-Prinzip
- Registriert
- Juni 2019
- Beiträge
- 8.358
Eben da sehe ich halt das Problem. Deshalb fürchte ich dass es genau so kommen wird.
Aber sicher können wir natürlich erst sein wenn wir die Dinger vor uns liegen haben bzw die ersten Laptops damit kommen.
Bin gespannt was die Anbieter auf die werbeanzeigen schreiben. Ich ahne Chaos.
Aber sicher können wir natürlich erst sein wenn wir die Dinger vor uns liegen haben bzw die ersten Laptops damit kommen.
Bin gespannt was die Anbieter auf die werbeanzeigen schreiben. Ich ahne Chaos.
pipip
Fleet Admiral
- Registriert
- Jan. 2011
- Beiträge
- 11.420
AMD und TSMC befindet sich mit Zen2 auf einer Vorstufe zu dem was du beschreibst.xexex schrieb:
https://www.tsmc.com/english/dedicatedFoundry/technology/SoIC.htm
&
https://www.tsmc.com/english/dedicatedFoundry/services/cowos.htm
&
https://www.anandtech.com/show/1559...ckaging-for-future-products-hybrid-25d-and-3d
Über letzteres wird wohl erst zu "AMD Architecture Day " erzählt.
Eher sehe ich das als aktuelle Chip Entwicklung und das wird nicht nur Intel und AMD oder gar NV betreffen, sondern ARM und andere.
Aus diesem Grund betone ich bei Zen immer den IF-Bus. Denn ohne dem, wäre Zen nur ein Quadcore geworden und mit Zen 3 dann zu einem Octa Core.
FSB => Hypertransport => IF-Bus. War erstes nur eine Verbindung, ist es mittlerweile ein universell einsetzbarer Bus mit verschiedensten Protokolle. Das sieht man allein dadurch, dass auch die GPUs IF-Bus nützen und dass dieser Bus sowohl im Chip, Chip to Chip und Socket to Socket einsetzbar ist und mit unterschiedlichen Chips, siehe kommende Super Computer die CPU und GPUs zu einer virtuellen APU über IF kombiniert.
Und wenn man genau ist, konnte man solche Ansätze bereits in XBOX 360 Slim, Nintendo Wii U ect sehen. Deshalb empfinde ich Konsolen Hardware immer als interessant, weil es potentiell Hinweise auf die Zukunft geben kann. So wie die genutzten Ansätze mit der SSD in der PS5. Und das auch nur deshalb, weil Konsolen von der Software ihr eigenes Ding drehen können und nicht immer kompatibel zu alten Software sein müssen.
Zuletzt bearbeitet:
pipip schrieb:
Das was du zeigst ist aber eher Intels Foveros (Stapelung), was man eben bei der Lakefield CPU einsetzt. Bei EMIB wird es darum gehen.
bad_sign schrieb:
Technisch waren es bei Bulldozer auch 8 Cores. Es geht nicht darum wie viele auf dem Papier vorhanden sind, sondern wie sie vermarktet werden und was der Kunde denkt dabei zu kaufen.
Bei 8+8 sehe ich kein Problem, da erkennt man einfach, dass es wohl Unterschiede gibt. Würde man es wie bei den Smartphones als 8C verkaufen obwohl es 4+4 sind, sehe ich ein Problem, weil woher soll der Kunde wissen was er bekommt? 48 kleine Kerne und 16 große, sind eben keine 64 Kerne.
Aktuell wird es bei den Smartphones ja noch komplizierter.
Das ist so als würde ich sagen, "Hey ich habe hier ein Kilo Orangen aller erster Güte", dabei verkaufe ich dir dann eine wirklich gute und der Rest ist eher zweite Klasse.
Zuletzt bearbeitet:
- Registriert
- Aug. 2004
- Beiträge
- 11.699
Krautmaster schrieb:
Du hast doch schon häufig selbst vorgerechnet wie gering der Anteil der Rechenkerne gegenüber der iGPU oder den Caches sind, und wie wenig das letztlich zur Kosteneffizienz beiträgt, die Kerne zu verkleinern, no?
Zwei Möglichkeiten: Golden Cove wird entweder kein HT haben oder die bisher bei HT bekannten Sicherheitslücken hat Intel in dieser kommenden Architektur gefixt.Northstar2710 schrieb:
Weitere Optionen: Sowohl Gracemont als auch Golden Cove werden HT haben, oder beide kein HT.
Gracemont könnte als erste "Atom" Architektur AVX unterstützen. Vector Perf. wird bei Gracemont (auf der Präsentationsfolie von Intel) jedenfalls erwähnt.
Was ich mich allerdings frage ist wie die Verwaltung der Kerne bewerkstelligt wird. Also welche Workloads den kleinen Kernen und welche den großen Kernen zugewiesen werden.
CPU kontrolliert oder vom Betriebsystem kontrolliert? Ist ja beides denkbar.
Shoryuken94
Admiral
- Registriert
- Feb. 2012
- Beiträge
- 8.861
xexex schrieb:
Sehe ich etwas anders. Wenn alle Kerne simultan an einem Task arbeiten können, dann ist auch eine CPU mit 8 großen und 8 kleinen kernen eine 16 Kern CPU. Es sind physisch 16 Kerne auf dem Chip vorhanden, die ich auch wie ein 16 Kerner verwenden kann. Es ist nur nicht jeder Kern gleich. Beim AMD Bulldozer war das schon schwieriger, da eben nicht 8 vollwertige Kerne vorhanden waren. Bei den ersten Little Big CPUs konnte immer nir ein Cluster aktiv sein. bei den aktuellen Designs können alle Kerne gleichzeitig genutzt werden, damit sind die Smartphone Chips in meinen Augen auch echte Octacores.
Nur weil ich Octacore auf die Packung schreibe heißt es noch lange nicht, dass alle Kerne gleich sind. Dann müsste man bei Ryzen theoretisch auch meckern. Dort werden auch X Kerne mit Y GHz verkauft. Unter realer Last schwanken die Taktraten der kerne aber und auch da ist dann nicht jeder kern gleich schnell.
Sollten bei der Intel Lösung nicht alle Kerne gleichzeitig aktiv sein, dann wäre 8+8 die richtige Angabe. Wenn beide gleichzeitig aktiv sein können, dann wäre 8+8 ein fairer Hinweis auf die unterschiedlichen Cluster. Aber es wäre formal auch nicht falsch 16 Kerne auf die Packung zu schreiben
0xffffffff schrieb:Stark vereinfachtes Beispiel: Du hast eine CPU die wahlweise mit 1 oder 2 GHz laufen kann. Dann ist es idR. stromsparender wenn deine Excel-Berechnung 500ms auf 2 GHz berechnet wird anstatt 1000ms auf 1 GHz zu laufen.
Ein Auto verbraucht auch nicht beliebig wenig auf 100km, indem ich einfach beliebig langsamer fahre.
Der vergleich hinkt etwas, da der verbrauch hier mit der Leistungsaufnahme gleichzusetzen ist. Hier ist stark die Effizienz zu beachten. Denn Verbrauch und Leistung skalieren nicht 1 zu 1. Nicht beim Auto und auch nicht bei der CPU
Um beim Autobeispiel zu bleiben, es ist nicht unbedingt effizienter, wenn du die Aufgabe möglichst schnell erfüllst. Ich kann mein Auto z.B. mit 7 Litern fahren (140 km/h) oder auch mit 20+ Liter (250kmh).
Bei 250km/h habe ich die Strecke zwar schneller erledigt, aber unter dem Strich mehr Ressourcen verbraucht. Bei Halbleitern ist es ähnlich. Gewisse Leistungen verlangen nach einer gewissen Energiemenge. Die Kunst liegt in der Effizienz. Sprich wie gestalte und konfiguriere ich den Chip, damit er zum einen schnell und zum anderen auch effizient ist.
Lautet die Aufgabe komme schnellstmöglich von A nach B, dann nehme ich trotzdem variante 2. Aber das ist halt nicht immer die Aufgabe. Auch nicht beim Rechner. Es gibt genug dauerhafte Anwendungen und Dienste, die kontinuierlich mit Daten gefüttert werden wollen, solange die Abwendung läuft. Und es gibt Aufgaben, die möglichst schnell abgearbeitet werden sollen.
Und hier kann Big little das beste aus beiden Welten verbinden. Ein effizienter Cluster, der einfache Tasks ausreichend schnell erledigen kann und ein Cluster der zwar ziemlich Energie kostet, aber dafür Dinge unglaublich beschleunigen kann, wenn es drauf ankommt. Hier liegt dann die Kunst in der Entwicklung, die gegebenen Ressorucen richtig zu verteilen. Und das geht natürlich nicht von heute auf Morgen, wenn so eine CPU erscheint, hat aber einiges an Potential, besonders wenn man das nicht nur nutzt, um den Chip zu verkleinern, sondern das freie Transistorbudget auch in erweiterte kerne investiert.
Zumal wir ja nicht die genaue Auslegung der Cluster kennen. Mit einem angepassten Kerndesign kann man schon einiges an Energie sparen, aber trotzdem einiges an Leistung liefern.
Das möglichst schnell nicht immer so effizient ist, zeigt ja Intel selbst mit Comet Lake. 250 Watt für eine gewisse zeit sind zwar die doppelte TDP, aber man schafft damit nur einige hundert Megahertz mehr. Energiebedarf und Leistung skalieren halt nicht 1 zu 1.
Ned Flanders schrieb:
Er schreibt doch auch nicht, dass man damit Fläche sparen soll, sondern das man auf gleicher Fläche mehr Kerne unterbringen kann.
Einfaches Beispiel.
Chip 1 und Chip 2. Beide sind gleich groß.
Chip 1 hat 4 große kerne, Chip 2 hat 5 Kleinere Kerne. Die Kerne von Chip 1 sind 15% schneller, als die von Chip 2. Dann leistet Chip 2 trotz weniger Leistung pro Kern und mehr Kernen mehr, als Chip1. Damit ist er pro Fläche effizienter. Das ist nur in fiktives Beispiel, aber so verstehe ich seine Aussage.
Zuletzt bearbeitet:
Müritzer
Commodore
- Registriert
- März 2017
- Beiträge
- 4.786
Zuletzt bearbeitet:
0xffffffff
Lt. Commander
- Registriert
- Dez. 2007
- Beiträge
- 1.834
Shoryuken94 schrieb:
Ohman, ich hab darauf gewartet dass das kommt. Ja, wenn man den Takt zu hoch prügelt steigt auch der Energiebedarf, soweit nix neues. Wichtig ist, dass der Umkehrschluss nicht gilt: Wenn ich mit 140 km/h 7l brauche und mit 250 km/h 20l, heißt das nicht, dass ich mit 10 km/h dann z.B. 0,2l benötige, es gibt auch eine untere Grenze.
Mir fehlt gerade die Muße das weiter auszuführen, es gibt gute Gründe für die "Race-To-Sleep"-Strategie und durch die heutige dynamische Taktung in modernen CPUs können sich auch die "big"-Kerne quasi zu "little"-Kernen wandeln.
Das Thema ist sehr komplex, zum einen sind die Anforderungen an Prozessoren in Mobiltelefonen und Tablets andere als für Notebooks und Desktop-Rechner, und zum anderen sind die Voraussetzungen auch völlig verschieden. Das Little/Big-Prinzip lässt sich nicht einfach übertragen ohne dabei nicht auch achitektonisch einiges umzuwälzen.
Shoryuken94
Admiral
- Registriert
- Feb. 2012
- Beiträge
- 8.861
0xffffffff schrieb:
Ich habe auch nicht behauptet, dass man beliebig wenig verbrauchen kann! Nicht in einem Wort. Nur das die maximale Geschwindigkeit nicht immer der effizienteste Weg ist. So wie ein CPU kerne auch nicht beliebig wenig verbrauchen kann. Bei unterschiedlichen Architekturen liegt hier das Level auf einem unterschiedlichen Niveau.
0xffffffff schrieb:
Little Big schließt das Prinzip nicht aus. Genau das ist ja der Trugschluss. Du führst mit zwei verschiedenen Kernen nur eine weitere Ebene ein. jeder einzelne kern kann weiterhin nach dem Prinzip arbeiten. Nur macht es nicht bei jedem Prozess Sinn, dass man den Kern dafür in einen recht ineffizienten bereich bringt. Jeder Kern soll weiterhin möglichst lange im niedrigsten Powerstate verbringen, nur kann man mit verschiedenen Kernen die Tasks auch entsprechend auf eine besser geeignete Architektur verlagern.
Du kannst durch den takt einen großen Kern nur bedingt zu einem kleinen Kern machen. Du sagst es ja selbst, du kannst einen gewissen Energieaufwand nicht unterschreiten.
0xffffffff schrieb:
Auch das hat niemand behauptet, dass unterstellst du nur jedem, schließt aber kategorisch aus, dass sich hier in den nächsten Jahen etwas tut. Noch wesentlich interessanter als für Desktop und Notebook könnte das ganze auch im Serverbereich sein. Wir haben bisher keinerlei Informationen zu der Umsetzung, trotzdem wird einfach etwas angenommen.
aldaric schrieb:
Richtig, es gibt keine allgemeingültige Definition und du kannst dir als Hersteller da ausdenken, was du möchtest. Nur teile ich da auch die Ansicht des Gerichts, nicht jeder von AMD bezeichnete Kern kann vollständig und voll umfänglich eigenständig genutzt werden.
Auch eine GTX970 hat formal 4GB aber auch die können nicht im vollen Umfang gleichermaßen genutzt werden. Auch da war Nvidia der Meinung, dass dass so ist, aber auch die Ansicht haben nicht unbedingt alle geteilt.
Alles teils Ansichtssache, in meinen Augen haben sowohl AMD als auch Nvidia zurecht vor Gericht verloren. Das kann jeder sehen, wie er möchte.
Krautmaster
Fleet Admiral
- Registriert
- Feb. 2007
- Beiträge
- 24.306
0xffffffff schrieb:Joa, hast Du dir mal angeschaut wie moderne Android-Scheduler ihren Job machen? Die suspenden oder killen deine Anwendung bzw. Task einfach nach x-Zeiteinheiten... so wird da "effizient" Strom gespart. Stichwort: Race-To-Sleep
das ist bei dem Big Core Prinzip bei Apple noch viel krasser als bei Android. Weiter hat Race to Sleep doch 0 mit der Verteilung Bug / Litte zu tun...
Weiter denke ich dass es neben Effizienz in erster Linie auch um Leistungsdichte geht.
Ergänzung ()
sehe ich genauso.Shoryuken94 schrieb:
Ergänzung ()
das ist richtig, in dem angesprochenen DieShot von Lakefield absolut. Aber ich meine dass da ja noch weit größere Modelle kommen sollten, mit 16 und mehr Kernen.Ned Flanders schrieb:
Diese Tremont-Kerne dürften auch vergleichsweise schnell sein, Intel bohrt diese ja auch mit jeder Gen wieder auf und sie sind Core gar nicht unähnlich.
Ich finde den Vergleich zu einem kleinen CCX gar nicht so uninteressant. gerade bei diesem Lakefield Die Shot.
Ob das letztendlich unterm Strich ne gute Lösung ist wird sich zeigen.
https://www.hardwareluxx.de/index.p...s-die-interface-und-dem-was-danach-kommt.html
Siehe auch das Foveros. Sehe zum ersten mal dass man hier Die stacked. Klingt interessant.
Rein vom Die Shot her hätte ich also gesagt dass ein Tremont etwa 20-25% der Fläche für 70% der Leistung braucht. Da bin ich gar nicht so weit von meiner 20/80 Regel entfernt
Denkbar ist da vieles und wenn es gut modular umgesetzt ist kann Intel auch so zb statt ggf 8 Sunny-Cove-Kernen auch 32 Tremont Kerne an den Ring hängen.
Die Richtung die Intel hier geht finde ich jedenfalls spannend, gerade auch wenn es zb irgendwann ggf drum geht mehrere Die zusammen zu schalten, über einen aktiven Interposer.
Zuletzt bearbeitet:
Diefläche verschwenden für ein paar Watt weniger im Idle, hmm.
Andererseits könnte man auch weniger intensive Programme generell auf den kleinen Cores laufen lassen, das würde auch im Desktop halbwegs Sinn machen.
Wenn es nur um dicke Zahlen auf der Packung geht, können sie eigentlich auch einfach die Cores ihrer iGPUs mitzählen.
Andererseits könnte man auch weniger intensive Programme generell auf den kleinen Cores laufen lassen, das würde auch im Desktop halbwegs Sinn machen.
Wenn es nur um dicke Zahlen auf der Packung geht, können sie eigentlich auch einfach die Cores ihrer iGPUs mitzählen.
Shoryuken94
Admiral
- Registriert
- Feb. 2012
- Beiträge
- 8.861
Krautmaster schrieb:Rein vom Die Shot her hätte ich also gesagt dass ein Tremont etwa 20-25% der Fläche für 70% der Leistung braucht. Da bin ich gar nicht so weit von meiner 20/80 regel entfernt
Wenn das wirklich in etwa hinkommen sollte, dann hat das sogar richtig Potrntial für große CPUs. Denn dann könnte man eine ziemlich krasse Multithreadingleistung liefern, bei gleichzeitig hoher Singlethread Leistung.
Gerade für HEDT CPUs könnte das spannend sein. Wenn man sich in etwa den aktuellen 18 Kerner ansieht, dann könnte man Beispielsweise 32 kleine Kerne mit 8 großen Kombinieren (falls vom Layout möglich). Im Grunde Xeon Phi 2.0 als gesockelte CPU.
Das sind jetzt einfach nur paar gedanken zu den theoretischen Möglichkeiten und es heißt nicht, dass es sowas geben könnte. Aber zumindest rein theoretisch könnte man damit sicher für den einen oder anderen Bereich sehr interessante CPU bauen.
Krautmaster
Fleet Admiral
- Registriert
- Feb. 2007
- Beiträge
- 24.306
https://mobile.twitter.com/GPUsAreMagic
da gibst auch echt interessante Die Shots mit Annotation, zb Renoir
@Shoryuken94
bei Alder Lake sind ja im selben Konzept zumindest schon von 8 Big + 8 Small die Rede. Wobei das Gesamtkonstrukt dann wohl etwa so groß wird wie ein 10 Big.
Interessanter wirds in meinen Augen aber erst wenn man sowas dann wie du sagst wirklich Richtung HEDT pushed, wobei man das ja auch schon hatte. Also wenns um wirklich reine Multithread Power geht komme ich ja quasi ganz weg von Big Kernen. Wir hatten ja schon Xeon Phi die ja in 45nm schon zig "Atom Kerne" beherbergten und wenn man weiter geht dann ist man irgendwann weg von X86 bei einer klassischen GPU mit noch viel mehr Kernen.
Es ist immer ein jonglieren aus Single Thread Performance bis hin zu hochparallelen Aufgaben wie CPU Rendering / Grafik.
Offensichtlich versucht man mit Big Little ja beides unter einen Hut zu bekommen. Zumindest Low Thread bis Mid Threaded Workloads. Auf jeden Fall erhöht man mit den Little Kernen die Leistungsdichte recht massiv. Deswegen haben GPU ja auch eine brutale Leistungsdichte vergleichen mit CPU.
Potential hat es in jeder Hinsicht. Kann aufgehen, kann aber auch das Bulldozer Schicksal erleiden
da gibst auch echt interessante Die Shots mit Annotation, zb Renoir
@Shoryuken94
bei Alder Lake sind ja im selben Konzept zumindest schon von 8 Big + 8 Small die Rede. Wobei das Gesamtkonstrukt dann wohl etwa so groß wird wie ein 10 Big.
Interessanter wirds in meinen Augen aber erst wenn man sowas dann wie du sagst wirklich Richtung HEDT pushed, wobei man das ja auch schon hatte. Also wenns um wirklich reine Multithread Power geht komme ich ja quasi ganz weg von Big Kernen. Wir hatten ja schon Xeon Phi die ja in 45nm schon zig "Atom Kerne" beherbergten und wenn man weiter geht dann ist man irgendwann weg von X86 bei einer klassischen GPU mit noch viel mehr Kernen.
Es ist immer ein jonglieren aus Single Thread Performance bis hin zu hochparallelen Aufgaben wie CPU Rendering / Grafik.
Offensichtlich versucht man mit Big Little ja beides unter einen Hut zu bekommen. Zumindest Low Thread bis Mid Threaded Workloads. Auf jeden Fall erhöht man mit den Little Kernen die Leistungsdichte recht massiv. Deswegen haben GPU ja auch eine brutale Leistungsdichte vergleichen mit CPU.
Potential hat es in jeder Hinsicht. Kann aufgehen, kann aber auch das Bulldozer Schicksal erleiden
Ähnliche Themen
