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

PS828 schrieb:
Leistung ist Leistung und von nix kommt nix
Ja, für den Desktop würde ich das auch nicht als Relevant betrachten. Beim Big-Little geht es ja um Leistung auf begrenztem Raum und begrenzter Energiezufuhr. Sonst würde man ja nicht sparen, wo es geht.
Ansonsten gilt: Kerne ersetzt man besser durch mehr Kerne ;)
 
  • Gefällt mir
Reaktionen: Schorsch92, Salutos und PS828
@Ozmog

Jein denn du hattest dabei ausser acht gelassen das SMT auch zur ernsthaften Performancebremse werden kann wenn die Priorisierung nicht wie gewünscht greift.
 
Mit dem Platz bei "vielen" Kernen hat aktuell nur Intel ein Problem. Nichts desto trotz werden in Zukunft auch im Desktop mehr Kerne ihre Arbeit verrichten. Skaliert man die aktuellen CPUs hoch bedeutet das automatisch mehr Stromverbauch, was im mobilen Sektor kritischer ist als im Desktop.
Die Frage wird sein, wie intelligent erfolgt das Umschalten zwischen big und little.
Dabei sind die verschiedenen Cachelevel eine CPU zu berücksichtigen, wird ein Prozess an den jeweils anderen "Spieler" übergeben, benötigt dieser auch die Daten dazu, was eben auch Zeit beansprucht , in der die beteiligten Kerne nichts produktives tun.

In diesem Zusammenhang erscheint es interesannt, dass AMD beim L3-Cache von Vermeer eine Art L3-Cachepool (unified Cache) realisiert und auch beim L2 denkt man zukünftig an eine ähnliche Umsetzung.
 
  • Gefällt mir
Reaktionen: Schorsch92
Sehr gut.

Es arbeiten alle in die gleiche Richtung.

Jetzt schaut man noch einmal bei nvidia, wie die damals die Shader mit 3 fachem Takt zur GPU getaktet haben, baut asynchron getaktete Chips mit viel Takt bei den kleinen Babys und wenig Takt bei den großen Cores und klemmt noch ein paar FPGA cores daneben.

Das alles mit schnellem Ram und wir haben die sogenannte "next gen" CPU.

Wenn es nur so einfach wäre in der Praxis, wie auf dem Papier.

mfg
 
Also es steht in dem Patent, das es am Oct 2017 eingereicht wurde.
Es wurde erst jetzt angenommen.
Fall 1:
Im Kern heruntergebrochen, habe ich es so verstanden, das hier ein little Core eigenen L1 hat und einen gemeinsamen L2 mit dem BIG core.
Expizit steht da das bei einer Instruction / Performance gefragt wird, dann der L1 copy auf Big läuft und der BIG Core übernimmt und little in Sleep geht.

Fall 2:
Ob hier beide gleichzeitig an verschiedenen Prozessen arbeiten dürfen, das hab ich auf die schnelle nicht gefunden.

Es wird jedenfalls nur der obere Fall 1 Diagramm beschrieben, was halt den zweiten Fall nicht ausschließt. Muss aber sagen das ich die Seiten an Kleingedruckten nicht gelesen hatte.

Wie jetzt das Intel Gegenstück aussieht hab ich nicht geschaut. Gerade wegen des shared L2. L2 Cache ist ja ein wirklich großer Anteil bei CPU Dies. Getoppt nur um längen vom L3, den AMD ja schon bei Desktop CPUs "auslagerte", weil er bescheuert groß ist wegen Latenzminimierung (eher wegen der Seitenfehler und wegen der Serveranforderungen) und weil ein günstigerer Prozess verwendet wurde.

AMD hat ein Patentabkommen mit Intel (oder Intel mit AMD, wie auch immer), schon wegen 64bit.
Ein Patent bedingt nicht zwingend sofort das ein Produkt entwicklelt wird/wurde. Aber insgesammt überraschte es mich das AMD schon vor 3 Jahren Ressourcen hatte da in die Zukunft zu schauen. Also selbst wenn Alder Lake ein Erfolg wird (ich zweifle da stark dran) kann AMD es bei Bedarf dann wohl kopieren.
 
  • Gefällt mir
Reaktionen: Salutos
PS828 schrieb:
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

warum das? wenn du den PC auch für alltägliche dinge nutzt, kann man so strom sparen und vor allem jetzt im sommer fällt eine hitzequelle weg

ich nutze den pc auch zum filme schauen, musik hören und internet surfen.
wenn das BS jetzt zB die leistungsstarke DIE komplett abschalten könnte und nur auf einer laptop DIE läuft, dann würde ich vermutlich kaum etwas merken, außer, dass die CPU 20° kühler sein dürfte
also ich finde das auch im desktop systemen sehr interessant, wenn man den PC nicht nur zum spielen einschaltet

aber auch für spiele würde eine schwache CPU genügen.
zB für borderlands 2 reicht die schwachen DIE aus und wenn man B3 spielt, dann schaltet sich die starke zu
 
@ [wege]mini

Ich glaube du meintest Fermi der mit doppelten Shader Takt lief, oder?
Der war jetzt nicht soooo ein beispiel für Effizienz. :D
 
@longusnickus alles richtig. Nur tue ich sowas nicht :D ich nutze AVX2, ich nutze alle Kerne und das sehr oft. Zeit ist hier auch ein kritischer Faktor. Die Abwärme hingegen eher nicht. Ich bin wegen der Hitze aktuell für leichte Aufgaben an einen Deskmini mit Athlon 200GE gewechselt. Der Verbraucht nie mehr als 15 Watt und das ganz ohne sheduler Chaos oder teilweise Kastration.

Versteh mich nicht falsch. Hängt alles am Akku ist das Klasse. Aber kommt mir nicht mit Strom sparen wenn man sowieso an einem 60W + Monitor sitzt bzw einer Soundanlage die das zehnfache leistet.
Da ist das am Desktop alles relativ unnütz, bekommt man doch jetzt schon wirklich sparsame CPUs welche man durch TDP Begrenzung noch sparsamer machen kann. Im stationären Betrieb seh ich den Vorteil einfach nicht.
 
  • Gefällt mir
Reaktionen: Schorsch92
Marcel55 schrieb:
Ist aber auch ein unfairer Vergleich, der Pentium ist 2 Jahre neuer und setzt auf 14nm während der i5 noch 22nm hat...

Klar, aber der i5 lief dafür mit geringerer Spannung. Kurioserweise hat er bei 4 Threads eine geringere Punkteanzahl, als im Singlecore Test des Cinebench R20.

Und, technologisch hinkt der Pentium nun mal hinterher, da ja nur Atom und nicht Core Architektur.
Ergänzung ()

latiose88 schrieb:
...
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....

:confused_alt: :confused_alt: :confused_alt:
Irgendwie verstehe ich... Nix
 
Zuletzt bearbeitet:
wern001 schrieb:
Viele Patente dienen doch nur der Abzocke!
bestes Beispiel bei AIOs die Pumpe auf der CPU
Nicht nur dafür, sie sind auch dafür da die Konkurrenz im Dunkeln tappen zu lassen, weil sie denkt die Firma will das Produkt auf den Markt bringen.
 
lokon schrieb:
Das "heterogen" bezieht sich nicht nur auf die "Größe" - sondern auch auf ISA features.
Siehe Claim 4 und 8 zB. Keine Ahnung wie bei ARM das aussieht.
A53 & A57–A73 = ARMv8 - genau der gleiche ISA-Stand.
A55 & A75–A78 = ARMv8.2 (plus ein paar Extras) - da ist es komplizierter...
Arm hat in der neuesten Generation noch ein paar Teile von ARMv8.4 und ARMV8.5 implementiert, so daß der Feature-Set ganz langsam auseinanderläuft.
 
@PS828
Selbst auf einem dicken Desktop können kleine Kerne helfen. Auch wenn eine Aufgabe alle Kerne auslastet, muss die CPU immer wieder andere Threads bearbeiten. Allein das Betriebssystem sichert sich ja immer wieder Slots (allein schon um I/O und Sheduling abzuwickeln). Wenn große Aufgaben erweiterte Befehlssätze und viel Leistung benötigen kann man die "kleineren" Aufgaben des Betriebssystems auf kleinen Kernen abwickeln und so Kontextwechsel auf den dicken Kernen vermeiden. Sowas verspricht durchaus etwas Performancezuwachs[1].
Erweitern kann man das auch insofern, dass die wenigsten Programme dauerhaft in engen Schleifen mit Vektorbefehlen verbringen. Der ganze Code drumherum zur Verwaltung und Ablaufsteuerung, kann im Zweifelsfall auch auf Threads auf die kleinen Kerne ausgelagert werden. Wenn Big und Little sich ihren L2 Cache teilen, ist die Kommunikation zwischen den Threads sogar vergleichsweise günstig was Energie- und Zeitaufwand bedeutet.


[1]Jeder Prozentpunkt Steigerung ist mittlerweile recht aufwendig.
 
@Piktogramm Voraussetzung ist aber dass man dafür vielleicht 4 Minis für die Hintergrundlast lässt und alles andere über die Großen läuft.

Wenn's gleich viele oder gar weniger große als kleine Kerne sind bringt es genau nix weil dann ist man insgesamt wieder langsamer unterwegs als wenn einfach alle Kerne die gleichen Voraussetzungen haben.

Im mobilen Bereich bei normalen core counts mag das alles passen. Aber an der Desktop Spitze in Anwendungsleistung sehe ich auf lange Sicht keinen wechsel
 
@smalM
Wenn A55 und A78 auf einem Die sind, was anouncen die CPU Kerne dann an Featuresets? Mein Stand ist ja, dass alle Cores den kleinsten gemeinsamen Nenner angeben.
Ergänzung ()

@PS828
Bei Performance nach dem Motto "Koste es was es wolle" wird bei reinen Rechenaufgaben tendenziell ein komplexeres CPU Monster gewinnen, dass stimmt schon. Normalerweise betrachtet man die Performance jedoch im Verhältnis zu Aufwänden wie:
  • Kosten der CPU
  • Energiebedarf
  • Physikalische Limitierung beim Abführen der Abwärme

Wenn da eine Kombination Big-Little bessere Werte schafft, wird es kommen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: PS828
Problem ist halt dass die Effizienz bei Auslastung aller resourcen bei den kleinen Kernen wieder schlechter wird. Die großen haben dann mehr Takt, dezidierte Berechnungsfunktionen und verbrauchen deshalb weniger da sie einfach ein Vielfaches schneller sind.

Aus diesem Grund bleib ich skeptisch. Wie gesagt im mobilen Bereich kein Problem, aber Workstation, Server usw kann man es vergessen.

Wie träge Software auf grundlegende Änderungen in Architektur und Design reagiert sieht man bei den Threadrippern der ersten beiden Generationen und der nur langsam voranschreitenden Multicoreoptimierung in vielen Bereichen lässt sich nix gutes ableiten.

Wie es dann wird muss die Zukunft zeigen aber ich bin hier nicht sehr optimistisch besonders bei Windows.
 
  • Gefällt mir
Reaktionen: LukS
Das nun gewährte Patent US10698472 (PDF) beschreibt exakt das, wofür umgangssprachlich big.LITTLE steht.
Das kann ja nicht sein, denn darauf könnte es ja kein Patent geben, wenn es etwas beschreibt was schon von anderen so gemacht wird.
 
lokon schrieb:
Außerdem sollte vielleicht ein größerer Schwerpunkt des Patentes erwähnt werden: unterschiedliche ISA / Befehlssets der beteiligten Cores - für das Patent wichtig sind doch wohl die "Claims" also das Neue.
Ja, das ist mir beim Lesen der Patentschrift ebenfalls aufgefallen.
Das bedeutet dass die Little-Kerne nicht den kompletten Befehlssatz der Big-Kerne unterstützen müssen u. wenn im Programmcode Befehle vorkommen welche die Little-Kerne nicht unterstützen dann wird sofort auf die Big-Kerne geswitched.
Wobei es keinen Sinn ergibt unterschiedliche Basisbefehlssätze zu verwenden, also ARM-ISA für die Little-Kerne und x86-64 für die Big-Kerne wäre real extrem schwierig umsetzbar.
Was Sinn ergeben würde: Die Little-Kerne würden dann keine AVX-Recheneinheiten benötigen, und alle AVX-Befehle würden dann von den Big-Kernen verarbeitet werden.

Auf diese Weise könnte AMD sogar aktuelle Zen-Kerne mit kleinen Kernen, z.B. der Puma-Architektur, kombinieren.
In 7 oder gar 5 nm gefertigt würden Kerne mit Puma-Architektur wenig Chipfläche belegen und wären ziemlich energiesparend.
 
Am Desktop halte ich das Prinzip für Müll, da schon das Board regelmäßig 20 Watt frisst und natürlich noch die restlichen laufenden Komponenten dazu kommen. Die CPU taktet doch schon herunter, kann mir da nur größere Einsparungen vorstellen wenn im Desktop wirklich mega langsame Cores zum Einsatz kommen, was bei Multitasking Bullshit wäre.
Ums kurz zu machen, halte das für Power-User nicht für umsetzbar, da sowieso immer die schnellen Cores aktiv wären.

Im Mobil Markt ist es eine ganz andere Sache, bei Notebooks und Smartphones macht es eben wegen dem Akku viel Sinn und die Geräte sind ab Werk auf Strom sparen getrimmt und nicht auf Leistung.

Alles was Leistung benötigt, ist das Prinzip dann aber obsolet.
 
Zurück
Oben