News Zukünftige Prozessoren: big.LITTLE-CPU-Patent für AMD ausgestellt

[latiose88]

Dann musst halt Intel auf der Verpackung 8 kleine und 8 große Kerne stehen haben, dann weiß der Kunde das es keine 16 normale Kerne sind sondern 8 davon beschnitten sind. Dann ist Intel fein raus und hat es klar kommuniziert, dann passt es wieder. Was am Ende dann bei der Leistung raus kommt das andere.

Ergänzung (10. August 2020)

@latiose88 Du gehst auch zum Lachen in den Keller?
Würde mich jedenfalls nicht wundern.

Na was soll denn das, na das soll nicht witzig sein. Ich kann halt mit dem Wort nix anfangen. Dann Habe ich es gegoogelt und dann kam das als Ergebnis raus. Sollte ich mich geirrt haben und du einem damit etwas anderes sagen wollen, dann sag es doch direkt. Erkläre es mir dann halt richtig wenn es falsch ist OK?
Achja zum lachen muss ich nicht in den Keller gehen, denn das mache ich dann schon vor dem Laptop. Denn manche schreiben echt coole Sachen, da kann man nicht anders als zu schmunzeln oder zu lachen, ist doch nicht schlimm. Also ich finde es gut so,weiter so.

 

[Wadenbeisser]

Der Verlust kommt daher dass es weniger Big Cores gibt.

Warum sollte das der Fall sein?
So wie ich das sehe wird jedem big core ein little core zur Seite gestellt und beide zusammen erscheinen nach außen hin als ein Kern. Warum auch nicht? der little Core wäre am Ende nur eine internen Stromspar Krücke die nach außen hin keinen interessiert weil nicht gleichzeitig ansprechbar.
Ist ja nicht wie bei SMT wo ein Kern nach außen so tut als wären es 2.

 

[PS828]

Das wäre okay, allerdings weiß ich nicht ob das so passiert. Wo ist die Platzersparnis wenn man einfach 1:1 groß und klein nimmt.

Evtl habe ich das auch Falsch verstanden und Platzsparend war nicht angedacht aber generell ist hier das Verhältnis wichtig und entscheidet Zukünftig über den Erfolg dieses Prinzip

 

[tom1111]

Das die allgemein unter aller Kajüte ist?
Und die Netzteilverluste manchmal sogar über dem eigentlichen Verbrauch der verbauten Technik liegen?

Ähm, ein Wirkungsgrad von über 90% ist nicht unter aller Kanone. Das ist ziemlich viel, wenn Mann ein bischen Ahnung von Physik hat.

 

[Wadenbeisser]

@PS828

Warum gehst du beim Gesammtkonstrukt von einer Platzersparnis aus?
Der big Core kann etwas kleiner ausfallen weil einige power gating Mechanismen dadurch überflüssig werden und durch das Teilen der Register und des L2 Cache wird hier bereits Platz für den little Core gespart. Sollte es dann auch noch so sein das beim little Core die FPU fehlt entfällt einer der größten Platzfresser überhaupt. Damit könnte das Design kaum größer sein als ein normaler Kern.

Ich sehe hier den Schwerpunkt bei der Energieersparnis und da das gleiche Kern Design in den Produkten aller Marktbereiche zum Einsatz kommen dürfte ist es auch ziemlich egal ob man das fürd en Desktop Bereich rentiert oder nicht. Im mobilen Bereich dürfte das definitiv sinnvoll sein und dann bekommt es der Desktop Bereich eben gleich mit.

Ergänzung (10. August 2020)

@tom1111

Nicht den Eigenverbrauch des Netzteils für die Regelelektronik usw. vergessen, ich glaube darauf wurde angespielt. Pico PSUs sind nicht umsonst in den geringeren Leistungsklassen oftmals effizienter.

 

[PS828]

Ursprünglich dachte ich: kleinere Kerne, kleinere Caches bei vielen und da spart man viel Wafer Fläche da fallen wenige große nicht ins Gewicht weil der SRAM sowieso den meisten Platz nimmt wenn keine GPU drauf ist. Daher die Annahme.

Beim Stromverbrauch muss man halt sehen. Ich denke immernoch dass es wenig bringt da Sachen wie das Display und andere Komponenten gibt die hier mehr Ziehen auf Dauer. In Summe viele kleine verbraucher machen da auch viel aus. Evtl kann man Dort ansetzen

 

[Wadenbeisser]

@PS828

Ich denke das die Kerne schon jetzt klein genug sind.
Wie groß ist denn aktuell so ein 8 Kern Chiplet? Gute 150 mm²? Das wären dann ca. 19 mm² pro Kern und das inkl, dem ganzen Uncore Anteil der nicht dazu gehört.

Schaue ich mir dann auch noch diesen Artiken von PCGH an: https://www.pcgameshardware.de/Mati...ls/Zen-2-Ryzen-3000-Die-Shot-Analyse-1339786/

L2 und L3 schlucken davon schonmal ca. 2/3 des Platzes und vom Rest die FPU wohl nochmal ca. 1/3.
Rechnen wir wegen dem Uncore Anteil also mit ca. 18 mm² pro Kern, dann entfallen davon ca. 12 mm² für den L2 und L3 Cache und zieht man von den letzten 6 mm² nochmal 1/3 für die FPU ab dann landen wir bei grob 4 mm² für den Rest des Kerns inkl. L1 Cache. Wird der ebenfalls noch ein Stück zusammengestaucht könnte der little Core bei ca. 2-3 mm² zusätzliche Platzbedarf landen. Mit weiteren optimierungen und Shrinks dürfte das nochmal ein gutes Stück weniger werden.

Ergänzung (10. August 2020)

lt. der englischen Wikipedia Seite hat das 7nm Chiplet lediglich ca. 80mm².
https://en.wikipedia.org/wiki/Zen_2

Entsprechend schrumpft der Platzbedarf eines Kerns auf ca. 9 mm², ohne L2 und L3 bleiben dann nur noch 3 mm² und ihne den FPU Part reden wir dann nur noch über 2 mm² für den Rest des Kerns um den es hier am Ende geht.

 

[Hallo32]

@Wadenbeisser

Ob es wirklich effektiv ist die FPU bei den Little Core zu entfernen? Im Prinzip stecken heute doch überall im Code FPU Operatione und wegen jeder kleinen FPU Operation den Big Core zu wecken ist auch nicht effektiv. Das Balancing zwischen den Kernen muss stimmen.

 

[Caradhras]

@Volker:
Ich weiß nicht, ob es schon jemand erwähnt hat, aber big.LITTLE ist keinesfalls ein Fachbegriff, sondern der Markenname (Trademark) für eine ARM-Architektur. Einen neutralen Gegenbegriff zu SMP wäre dementsprechend AMP.

Aber bei SMT reden ja auch meistens alle von Hyperthreading. 🤪

 

[Wadenbeisser]

@Hallo32

Das ist die große Preisfrage denn es sind ja sonst keine Details weiter hinterlegt.
Die Frage ist eben ab wann umgeschaltet wird und was dann typischer weise für Code zum Einsatz kommt.

Meine Überlegung beruhte auf den Ansatz des Bulldozer Designs das man damals wohl entwickelt hatte weil der überwiegende Code integer lastig wäre und die FPU einer der größten Stromfresser des Kerns sein dürfte. Kommt FPU Code könnte man ja wie bisher auf dem big Core wechseln und der Rest bei wenig Last auf dem little Core ausgelagert werden. Natürlich könnte man dem little Core auch eine kleine FPU verpassen aber dann wäre die Preisfrage was mit der "high-feature Prozessor" - "low-feature prozessor" Unterscheidung gemeint war. Vielleicht nur grundlegene FPU und SSE Funktionen und ab AVX wird der big core geweckt? man weiss es leider nicht aber angesichts der bisherigen ca. 3 mm² dürften aber so oder so 1-2 mm² für den little Core beim aktuell genutzten Fertigungsprozess drin sein. Rechnet man dann aber mit ca. 4-5 Jahren seit Einreichtung des Patents (grober Anhaltspunkt = Zen Entwicklungszeit) rechne ich mit entsprechenden Produkten frühestens 2021 oder 2022 und da r.eden wir dann höchst warscheinlich schon über 5 nm.

 

[latiose88]

Meint ihr also wirklich das nur AVX zwischen den kleinen und großen Cores Unterscheiden würde.
Die wo dann Anwendung nutzen die garkeine AVX nutzen,hätten dann am ende weniger Leistung.Das kann ich mir nicht vorstellen.Da wird es gewiss wohl noch andere Unterschiede geben,denn sonst nutzen die Anwender ja nur die kleinen cores ohne die großen Cores zu nutzen.
Also das sich die kleinen und großen Cores sich die Caches teilen.Wird da denn dann die Leistung nicht schlechter dann? Oder teilen sich HT sowie SMT also auch Hypertrading ebenso die Caches?
Das sich also 2 Threads eines Kernes ebenso die Caches Teilen?
Ich gehe davon aus ,das sich da noch was anderes dahinter stecken wird.

 

[Hallo32]

@Wadenbeisser

Viele Fragen werden bis zur möglichen Umsetzung offenbleiben.

Die FPU und auch viele andere Einheiten lassen sich in der Anzahl und deren Performance anpassen und somit für einen kleinen Kern optimieren. Dieses bedeutet in der Regel, weniger Operation werden parallel ausgeführt und die Anzahl an Takte pro Operation steigt.

Wenn die kleinen Kerne keine FPU haben sollten, müssten die großen Kerne selbst dann aktiv sein, wenn im Hintergrund eine MP3 Datei abgespielt wird oder ähnlich triviale Aufgaben im Hintergrund laufen.

Das Design der FPU und dessen Auswirkung auf die Performance der Bulldozer Architektur wäre bestimmt ein spannendes Thema, welches einmal genauer betrachtet werden könnte.

 

[Wadenbeisser]

@Hallo32

Ich bin auch gespannt was dabei am Ende raus kommt.
Beim Bulldozer Design halte ich inzwischen das weit reichende Shared Design für den größten Fehler denn es würde mich nicht wundern wenn es mit zusätzlichen Latenzen belastet war die nicht zuletzt beim L1 Cache die Performance den Bach runter gehen lassen. Mich würde mal interessieren was dabei rausgekommen wäre wenn nur ein Teil die komplette FPU bekommen hätte.
Vielleicht war das Design ja ein Opfer des ursprünglichen SSE5 Ansatzes, sowie von Intels ursprünglicher AVX Fassung zu der anfangs auch FMA4 gehörte?
Bei FMA4 konnte das Design ja recht gut aufdrehen aber mangels letztendlicher Umsetzung in der Software blieb davon eben nichts übrig. Dazu noch die mehr als mangelhafte Verbreitung von Multicore Software und das Debakel war perfekt weil so ziemlich alle Entwicklungsschwerpunkte gegen die Wand fuhren.

 

[smalM]

Wenn du alle Funktionen zum Little Core hinzufügst, dann ist es ganz schnell wieder ein Big Core.

Du verwechselst Funktionsumfang mit Leistungsfähigkeit.

Exakt der gleiche Funktionsumfang, aber einer von den beiden ist 3-6 Mal schneller als der andere.
Welcher das wohl sein mag?

 

[Hallo32]

Du verwechselst Funktionsumfang mit Leistungsfähigkeit.

Nein, denn auch die Implementierung von Funktionen benötigt die dazugehörige Logik und somit Chipfläche.
Dass die Performance ein weitere unabhängige Größe ist, die die Chipfläche beeinflusst, sollte klar sein.

 

[smalM]

@Hallo32
Hätte der kleine Core nicht den vollen Funktionsumfang des großen Cores, er wäre nicht wesentlich kleiner.
Ein Tempest-Core ist deshalb so groß wie er ist, nicht weil er den Funktionsumfang des Vortex-Cores bietet, sondern weil die Architektur so leistungsfähig wie die eines Cortex-A75 ist, der ja Arm als Big-Core diente. Apple hätte den Tempest-Core, wenn das das Ziel gewesen wäre, bei gleichem Funktionsumfang noch deutlich kleiner machen können.
Leistung ist nicht eine weitere Stellgröße, es ist die Stellgröße, wenn es um Chipfläche geht.

 

[max9123]

@latiose88

Das Patent liest sich nicht wirklich wie ein klassischer Big/Little Ansatz wie er derzeit von Arm und Intel am Markt ist oder gerade kommt (das wäre auch nicht patentierbar). Bei diesen Ansätzen werden die Cores und die Threadzuteilung vom Betriebssystem verwaltet, meist können auch schwächere und stärkere Kerne gleichzeitig benutzt werden.

Hier wird vielmehr an den niedrigsten Cache Ebenen (L1/L2) oder/und auch direkt an den Registern ein erheblich kleinerer und sparsamer Kern mit reduziertem Feature Set "angeflanscht", wobei nicht unterstützte Features mitunter emuliert werden-> siehe Patent).
Der Vorteil liegt in der gesteigerten Effizienz bei niedriger Last und durch die direkte Nähe (L1/L2 Register) auch ein sehr schneller Wechsel zwischen dem Hochleistungs und Effizienzkern (eventuell auch mehrere spezialisierte). Das Management findet dabei in der Harware statt.

Im Prinzip ist das eher ein zusätzlich C-State (Prozessorkern nach außen hin aktiv, Hochleistungskern jedoch abgeschaltet), was noch immer deutlich effizienter als ständiges ein/ausschalten des Hochleitungskerns oder betreiben des Hochleistungskerns mit reduziertem Takt/Spannung sein kann.

 

[latiose88]

@max9123

Ich habe es geahnt. Emulieren ist nie gut denn das kann nie so gut wie nativ sein. Da wird dann also am Ende die Leistung dann wohl einbrechen. Geht halt leider echt nicht anders.
Und wenn dann so was wie avx nicht verwendet wird, dann kann das ja den kleinen cores ja eben auch egal sein.
Die Frage ob denn sich die hypertrading cores ebenso den cache teilen Die Frage würde ja nicht beantwortet. Also sprich wenn die dann l2 cache von sagen wir mal 2 mb haben, dann würde also bei den 2 threads ja jeder 1mb l2 cache haben. Ist das denn so korrekt? Also wenn das so wäre, dann wäre es ja egal ob es hypertrading Kerne oder kleine Kerne sind. Allerdings die kleinen Kerne haben mehr leistung wie die hypertrading Kerne, wie ich finde.

Jedoch bin ich gespannt wie gut es dann funktionieren wird. Denn nehmen wir mal an man hat ne Software die 16 threads nutzen kann. Nun sind es ja allerdings 8 kleine und 8 große Kerne. Hoffe das die sich nicht gegenseitig ausbremsen und auch harmonisch zusammen gleichzeitig die volle last führen können. Gehe mal davon aus das dieser nen 8 Kerner mit ht bzw smt schon schlagen wird. Gegen einen 16 Kerner ohne hypertrading allerdings verlieren wird weil es ja 16 big cores vs 8 big cores + 8 kleine cores sind. Somit wohl die der power user keine Freude bereiten wir bei der Leistung. Hoffe da kommt noch was mehr als diese bisherige was ja zu sehen ist.

 

[max9123]

@latiose88

Hier geht es meiner Ansicht nach wirklich nicht um Rechenleistung sondern nur um erweiterte Stromsparmechanismen. Teilen müssen sich der Hochleistungskern und der Energiesparkern den Cache nicht (sofern sie nicht gleichzeitig laufen). Der direkte Zugriff hat nur den Vorteil, schnell und energiesparend der Kern wechseln zu können (deutlich schneller und energiesparender als derzeit von einem Hochleistungskern auf einen anderen (zumindest über L3, falls in einem anderen CCX über den Speicherkontroller)

Emuliert wird wenn überhaupt nur, wenn einige wenige Befehle auftreten die der kleine Core nicht unterstützt, bei größerer Auslastung wird praktisch immer der Hochleistungskern aktiviert.
Der energiesparende Kern kann dabei im Schnitt vl. nur eine 10-30% der Leistung eines großen Kerns haben, bei manchen Code Segmenten noch weniger. Er sollte aber bei niedriger Last deutlich effizienter als ein Zen Kern sein.
Derzeit wird bei niedriger Auslastung der Takt reduziert und/oder der Kern (oder Teile von diesem) in kurzen Abständen ausgeschaltet und wieder eingeschaltet.

Hyperthreading ist ein anderes Kapitel. Hier werden Recheneinheiten von einem zweiten Thread genutzt sofern sie vom anderen nicht benutzt werden (durchaus häufig) oder dieser auf Daten aus dem RAM wartet. Der Cache muss dabei eigentlich sauber getrennt/geteilt werden da man ansonsten durch Latenzunterschiede erkennen kann was der andere Thread gerade macht, an Speicheradressen kommt oder in weiterer Folge auch Daten auslesen kann (grobes Grundprinzip einiger Prozessorlücken, die in letzer Zeit aufgetaucht sind).

 

[latiose88]

Verstehe,nun dann ist ja wohl dieser Ansatz wohl nix für mich.Denn ich nutze schon alle Kerne völlig aus,das heißt somit auch Hypertrading.
Wenn also die kleinen Kerne also sogar schlechter als Hypertrading Kerne sind,dann kann ich ja echt drafu verzichten,schade.
Wenn also das die Zukunft beim Pc ist,dann bin ich wohl raus aus der ganzen Sache.
Denn ich kann ja im grunde sogar 28 Threads völlig auslasten.Ja das geht wirklich bei einem 16 Kerner ,wenn man von den 4 Kernen nur die hälfte zum zocken und das andere ebenso für die Anwendung nutzt.
Sollte allerdings irgendwann mal ein so eine CPU kommen wo dieser 16 Big Cores & 4 oder 8 little Cores hat.Dann sehe ich das wieder als gut an.Denn dann kann ich auf die Big cores z.b Umwandeln und auf den little Cores zocken.
Ich sehe das also durchaus als Positv an.So könnte ich mir sogar ein 12 Big und 8 little Core CPU vorstellen.Denn wenn ich nicht zocke dann reichen mir ja sogar 12 Cores völlig aus.Allerdings erwarte ich dann das dann mehr IPC aus den Big Cores dann herausgekitzelt wird.Denn ich brauche ne richtige Leistung um damit dann sehr schnell unterwegs dann bin.