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

[Kacha]

Die Behörden prüfen aber auch hier nicht, ob ein Patent eventuell zu unrecht erteilt wurde oder ggf. gegen ein anderes Patent verstößt, dass gehört nämlich zu den Pflichten des Antragstellers, zu mal es bei der schieren Menge an Patenten und der Komplexität dieser nicht wirklich möglich ist, denn dafür bräuchte man auch entsprechend geschultes Fachpersonal.

Das stimmt so nicht ganz. Die Patentbehoerde prueft sehr wohl ob Prior Art schon vorhanden ist. Und das liegt dann am Antragssteller das zu erklaeren. Da werden dann auch gern US Patente geliefert von der Behoerde, da die etwas schwammiger sind.

Ich hab schon bei Intel nicht verstanden was das im Desktop bringen soll. Und selbst im Notebook ist doch in Zeiten von Powergating der idle Verbrauch kein signifikantes Kriterium mehr.

Das ist auch so eine Sache, die ich nicht ganz verstehe. Ich bezweifle, dass der Verbrauch derart drastisch sich unterscheidet, da eben der Grafikanteil immer noch das gleiche verbraucht. Zudem im mobilen Bereich der Bildschirm mit am meisten verbraucht. Moeglicherweise aber einfachere passive Kuehlungen?

 

[Ozmog]

Es muss in beiden Fällen alle 8 Threads der CPU nutzen können um davon zu profitieren.

Ja klar ist das so, eine Anwendung kann ja nicht in mehr Threads aufgeteilt werden. Es gibt natürlich immer noch einige Programme und Spiele, die nicht so viele Threads ansprechen können, andere Anwendungen machen es aber ohne Probleme.
Dazu ist das Ausfühten mehrerer Anwendungen gleichzeitig ja auch noch da.
Für die reine Spielerkiste vielleicht nicht so relevant, aber es gibt eben genug Fälle, wo mehr parallel ausgeführt wird. Viele Anwendungen die nur einzelne Threads auslasten, lasten so die gesamte CPU aus.

Sehe ich bei meinen Beginnen im Umgang mit einer DAW und einiger Plugins, je mehr Plugins ich nutze, desto mehr laste ich die CPU aus, wo ein einzelnes Plugin kaum mit einem zweiten Thread umgehen kann.

 

[KurzGedacht]

Ich hab schon bei Intel nicht verstanden was das im Desktop bringen soll. Und selbst im Notebook ist doch in Zeiten von Powergating der idle Verbrauch kein signifikantes Kriterium mehr.

Was braucht denn so ein aktueller Ice Lake im Idle und um wieviel verlängert sich die Laufzeit des Notebooks wenn man diesen Wert durch Big Little nochmal viertelt?

Bei Intels monolitischen Ansatz mag big Little ja möglicherweise helfen noch ein paar mm2 Die Fläche zu sparen, aber bei AMD mit den Chiplets ist das doch völlig nebensächlich. Und bei APU Derivaten bei denen 4/5 des Dies aus GPU und Cache besteht, wo genau sollen die little Kerne da platz sparen.

Wie gesagt... ich checks nicht... weder bei Intel und noch weniger bei AMD

Soweit ich das verstanden habe ist Energie sparen nur einer der Treiber für diese Entwicklung. Auch aus reiner Performance Sicht kann es durchaus Sinn machen unterschiedliche Kern zu verbauen.

Wir haben z.b. HT/SMT weil die großen CPU Kerne mit ihren diversen Funktionen nur schwer vollständig ausgelastet werden können.
Eine wenig komplexe dauerhafte Hintergrund Last (nehmen wir jetzt Mal die den Voice Chat in einem Epiel), lastet einen1 modernen CPU Kern nicht annähernd aus, belegt aber dennoch Taktzyklen in denen der Kern nicht wirklich was anderes tun kann. All die ganzen Spezialfähigkeiten wie Avx liegen hier brach.

Wenn wir nun für solche Aufgaben viele kleine wenig komplexe Kerne verbauen, haben die großen Leistungsfähigen all ihre Taktzyklen zur Verfügung um sich um die Dinge zu kümmern, bei denen wir sonst ins CPU Limit trennen.


Big.LITTLE = mehr Kerne auf gleicher Chipfläche und bessere Auslastung, da weniger Funktionen der großen Kerne ungenutzt bleiben.

 

[Ozmog]

mehr Kerne auf gleicher Chipfläche und bessere Auslastung, da weniger Funktionen der großen Kerne ungenutzt bleiben.

Ja, genau das klingt zumindest interessant, quasi ein CMT nur mit kleineren Cores als Partner. Da kommt eine Idee von Bulldozer wieder. Das zusammen mit SMT für den großen "Kern" kann schon was bringen

 

[andi_sco]

Dazu bräuchte AMD erst mal eine Architektur, die sich für little eignet. Die Raubkatzenserie wurde ja eingestampft und entspricht auch nicht mehr der Zeit.

Würde es, theoretisch, reichen, weniger Pipelines, weniger Cache, kein AVX einzusetzen? Dazu natürlich ein geringerer Takt und der DIE dann in einem Low Power Process a la 5nm, wie für Apple?

 

[Ozmog]

Ich würde sagen, dass das Abspecken nicht so das Problem sein sollte.
Also Zen nehmen, ein paar Features streichen und Ausführungseinheiten verkleinern, dann bekommt man schon was kleineres hin. Nur die sinnvolle Aufteilung ist gefragt.
Ein kleiner und ein Großer teilen sich dann ja den L2-Cache. Diese einheit dann vierfach oder 8-fach am L3 dran, wird so ein CCX dann aufgebohrt auf zusätzliche Threads. Also 12 oder 24 Threads bei der Kombination von klassischem SMT und CMT.

 

[andi_sco]

Ich weiß nicht ob es tatsächlich mehr bringt einen kleinen Kern zu verbauen der ständig am Limit läuft oder einen großen der einfach runtergeraktet werden kann...

Ich habe das schonmal in einem anderen Thread gepostet: ein Pentium N 3710 mit 6W TDP schlägt einen i5-4210U auf 6W gedrosselt. Selbst wenn der Pentium auf den Basistakt gedrosselt wird, ist er immer noch schneller.
Und so wird es in Windows für einige Bereiche auch sein. Bis zu einer gewissen Last und benötigter Leistung sind die kleinen Kerne schneller.

 

[pipip]

Hmm, das macht es durchaus interssant, ist ja quasi eine Erweiterung um CMT, das kombiniert mit klassischen SMT, sodass einige Anwendungen dann von drei Threads profitieren.

CMT ist quasi SMT. Das C steht für Core und deutet an, dass einfach statt nur den Register (wie bei SMT der Fall) eben noch mehr vorhanden ist, bei CMT eben der Core bereich. Deshalb haben die ja auch eine FPU geteilt.
Bei diesem Ansatz hast du quasi "zwei" Zen Cores, das aber im Master-Slave. Denn zu sehen ist, der eine steuert den anderen.
Deshalb glaube ich nicht, dass der "große" Core sich schlafen legt. Er schiebt eher dem kleinen was zu. Falls es zu Cache Problemen kommt, kann er entscheiden ob er auch ein flush macht.

Somit ist es aus meiner Sicht ausgelagertes SMT. Der zweite Thread wird mächtiger soll aber offensichtlich jene Aufgaben bekommen, die nicht so "anspruchsvoll" sind.
Das bedeutet der Hauptcore behält sich die dicken Aufgaben. Das geht sehr Richtung HSA Ansatz. Jedem Bereich die passende Aufgabe.

Schnelle Zeitkritische Aufgaben kann der kleine Core machen, der keine SIMD benötigt, größere komplexere Aufgaben der große Core mit den SIMD. Der kann dann die leichten Aufgaben gleich laden. Usw. Also da könnte es schon das eine oder andere Vorteil geben.

Aber am besten wie schon einige sagen abwarten. Vllt kommt davon auch gar nichts ^^
Denn das Chiplet-Design erlaubt ja auch einfach zwei unterschiedliche Die für so ein Big Little Ansatz. (falls das hier beschriebene überhaupt Big Little ist)
PS: Ich bin kein Experte, sondern einfach nur jemand der sich interessiert. Also legt bitte ned so viel Wert in das was ich sage

 

[BLR]

Was AMD dabei massiv zu Gute kommt, ist das Chiplet-Design. Kleine, sparsame Kerne haben sie ja, z.B. aus der embedded-Schiene. Es sollte für AMD kein größeres Problem sein diese Kerne für BIG.little zu modifizieren. Im Grunde muss man nur den Teil rauswerfen, den das IOD-Chiplet übernimmt und ein Interface zu diesem hinzufügen. Der größere Entwicklungsaufwand liegt sicherlich in der "Lastverteilung". Hört sich einfacher an, als es IRL sein wird, ist aber trotzdem ein Vorteil zu monolithischen Chips.

 

[Ozmog]

Deshalb haben die ja auch eine FPU geteilt.

Stimmt, hab vergessen, das die FPU bei Bully geteilt wurde.

Ist aber vom Prinzip her nicht weit davon entfernt, weil man mit dem kleinen Core nicht die gleiche Last wie mit dem Großen fahren kann, selbstverständlich. Also ein zusätzlicher Thread bei weitem nicht doppelter Chipfläche.

 

[SirSilent]

Lieber ARM drin als arm dran.

 

[Marcel55]

ein Pentium N 3710 mit 6W TDP schlägt einen i5-4210U auf 6W gedrosselt.

Ist aber auch ein unfairer Vergleich, der Pentium ist 2 Jahre neuer und setzt auf 14nm während der i5 noch 22nm hat. Wenn man Prozessoren mit vergleichbarer Fertigung und Architektur vergleicht dann kann man da auch schon mal auf andere Ergebnisse kommen.
Ich denke unterm Strich wird sich da nicht viel tun. Aber die kleinen Kerne sind eben günstiger.

 

[Ozmog]

falls das hier beschriebene überhaupt Big Little ist

Ja, es ist auf jeden fall ein anderer Ansatz, als bei Intel oder ARM, weshalb ja auch das Patent kein Problem ist.

 

[Marcel55]

Lieber ARM drin als arm dran.

Vom ARM ist keine Rede. Es können auch einfach 2 verschiedene x86 Kerne in unterschiedlicher Ausbaustufe sein. Sowas macht Intel ja auch.

 

[Floppes]

Den Energieverbrauch zu reduzieren ist immer eine gute Idee. Egal wo.

Ich glaube es bestreitet auch keiner, dass dieser Designansatz im Mobilbereich super ist.
Im Desktop muss ich noch überzeugt werden. Mir wurscht ob das dann Intel oder AMD ist. AlderLake darf das dann gerne versuchen. Das wäre dann auch der nächste Upgrade Zeitpunkt -Zen4 oder AL.

 

[Wadenbeisser]

@Ozmog

Wenn ein Programm sie nicht abrufen kann dann ist es dennoch er Multitasking möglich, womit wir auch schon beim nächsten Problem von SMT wären. Die Leistung des Kerns muss irgendwie auf beide Threads aufgeteilt werden.

Im besten Fall landet die performancekritische Anwendung priorisiert auf einem Thread und andere auf dem zweiten nur die Auslastungsreste, im mittelprächtigen Fall wird die Rechenleistung symetrisch zwischen beiden aufgeteilt (wodurch natürlich nicht die gesammte nutzbare Rechenleistung auf einem Thread liegt) und im schlechtesetn Fall läuft die Priorisierung so schief dass die performancekritische Anwendung komplett durch ein anderes Programm auf den zweiten Thread ausgebremst wird.

Vor allem den zweiten Fall kann man übrigens ganz gut mit mehreren Projekten des BOINC Managers nachvollziehen, welche einen relativ konstanten Berechnungsaufwand haben. Mit SMT laufen zwar doppelt so viele Workunits als ohne aber die Berechnungszeit dieser verlängert sich idR. erheblich. Spätestens dann wenn sie sich verdoppelt hat ist es faktisch überflüssig. Bei einem Mix aus Projekten konnte ich aber auch schon erleben das sich die Berechnungszeit einiger mehr als verdoppelt hat. Vermutlich wurde sie schlechter priorisiert und andere Projekte hatten ihnen die Rechenzeit abgegraben. Startet man beim SMT Einsatz hingegen nur so viele Workunits wie der Prozessor Kerne hat dann haben diese idR. eine vergleichbare Rechenzeit wie mit abgeschalteten SMT.

Wegen dieser potentiellen Performanceprobleme sehe ich SMT auch nur als Krücke an mit der man wenig forderne Hintergrundprozesse versorgen kann. Bei performancekritischen Programmen sollte man ausschließlich mit den physischen Kernen rechnen, SMT ist da lediglich Bonus.

Ergänzung (9. August 2020)

CMT ist quasi SMT. Das C steht für Core und deutet an, dass einfach statt nur den Register (wie bei SMT der Fall) eben noch mehr vorhanden ist, bei CMT eben der Core bereich. Deshalb haben die ja auch eine FPU geteilt.

Ähm.....nein.
Bei CMT wurde eben nicht nur die FPU geteilt sondern es waren pro Modul 2 Integer Kerne vorhanden die sich dann die aufgeteilte FPU teilen mussten.
Genau deshalb ist es auch nicht wie SMT sondern geht darüber hinaus und hatte deshalb auch eine relativ symetrische Aufteilung der Rechenleistung. Es ist eben nicht nur ein Lückenfüller für die Pipeline des Kerns.

 

[Ozmog]

@Wadenbeisser
Genau das habe ich beschrieben. SMT ist kein Wundermittel, aber für viele Fälle sorgt es eben für eine bessere Auslastung ohne dabei sonderlich viel mehr Chipfläche zu verbrauchen. Wenn man natürlich Anwendungen hat, die die Ressourcen der CPU soweit nutzen, das ein zweiter Thread kein Platz mehr hat, dann kann SMT ja nichts herzaubern. In einigen Fällen kann SMT auch bremsen, wurde auch bei einigen wenigen Spielen so schon beobachtet, ist aber wohl eher ein Problem des Sheduling.

Bei BOINC oder bei F@H werden ja mehr oder weniger gleichartige Berechnungen durchgeführt, die dann eben die gleichen Ressourcen der CPU verwenden, die können sich die CPU-Kerne daher auch schlecht teilen. Verschiedenartige Anwendungen können so aber für eine bessere Auslastung sorgen, und somit mehr Leistung aus der CPU rausholen.

 

[Salutos]

Lieber ARM drin als arm dran.

Aussage 👍
Das Problem hier ist das OS, in diesem Fall Windows.

 

[PS828]

Für den mobilen Bereich ein sinnvolles Mittel den Verbrauch zu senken und die Akkulaufzeit auch unter Last zu verlängern.

Aber sonst nicht interessant. Leistung ist Leistung und von nix kommt nix. Am Desktop kommt mir sowas nicht in den Rechner und selbst im Laptop habe ich persönlich bedenken, da ich gelegentlich Dinge tue die wohl nicht von sowas profitieren

 

[latiose88]

Ah OK interessant zu wissen das es mit der Anzahl der threads egal ob smt bzw ht oder echte Kerne als threads die gesamte thread Zahl ergibt. Das wäre echt interessant. Denn ich habe es ja auch asynchron verwendet gehabt. 4 echte threads zum zocken verwendet und der Rest 4 virtuelle threads der einen cores mit dem Rest in dem Sinne dann 28 threads dann gehabt. Das ganze dann durch 2 weil ich 2 der gleichen Software gestartet hatte. Schwupps habe ich dann pro Software dann 14 threads. Würde ich somit von little gib Konstellation progiterieren. Also ich verwende ja kein einziges avx.

Gibt es denn echt ne Möglichkeit das big und small cores gleichzeitig an ner Anwendung zusammen arbeiten können. Sodas am Ende mehr Leistung beim videoumwandeln dann herrschen können. Die Anzahl der threads die dann das Programm in den Sinne videoumwandeln dann in der umgewandelten Aufnahme an Infos rein schreibt,scheint die von der Software maximale Anzahl an threads die die Software dafür verwendet hat, anzuzeigen. Heißt also mehr geht nicht sinnvoll mehr.

Und wie sieht es denn dann mit den Fall aus, das ne Software nur 80 % auslastet, gibt es da ne Möglichkeit wo es dann in Richtung 100 % gehen kann und dabei dennoch die selbe Leistung abliefert oder hat man da etwa dann einfach Pech gehabt?
Heist das, das ich dann von den little cores profitieren könnte oder eher nicht?