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

[Wadenbeisser]

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.

Und genau das stand nicht in dem von dir zitierten Absatz.
Dort stand lediglich das es dem entspricht wofür es umgangssprachlich steht, nicht das es auch so umgesetzt wird und genau darauf kommt es bei der Patentierung an. Die Umsetzung und keine wage Beschreibung.

Hier dürfte es sich recht deutlich von der bisherigen Umsetzung aus dem mobilen Bereich unterscheiden denn so wie ich es verstanden habe sind bei der bisherigen Variante alle Kerne verfügbar und das OS entscheidet welche zum Einsatz kommen sollen. Bei der Umsatzung von AMD sieht es für mich aber eher nach einem entweder, oder Prinzip aus.

 

[DerJungeDerIst]

Wie der Artikel von Intel gekommen ist hat man es schlecht geredet und sogar ausgelacht, wie der Artikel von AMD gekommen ist kommt man auf einmal sehr differenziert herüber, den Underdog muss man wohl verteidigen, ist wohl ein komisches Naturgesetz.

 

[Wadenbeisser]

@ProximaCentauri

Nö denn von Intel ist es bereits bekannt das die was entsprechendes bringen wollen allerdings ist die Frage wie. Bei AMD war es bisher unbekannt und nun gibt es auf diesen Weg auch erste Details über die man diskutieren kann.

 

[jemandanders]

Wie der Artikel von Intel gekommen ist hat man es schlecht geredet und sogar ausgelacht, wie der Artikel von AMD gekommen ist kommt man auf einmal sehr differenziert herüber,

Sehe ich jetzt nicht so. Ich habe jedenfalls nicht gelacht, allerdings durchaus kritisiert.
AMD hat ja auch einen etwas anderen Ansatz, den ich nicht schlecht finde.

 

[Gaugaumera]

Bin gespannt inwieweit sich little cores wirklich auszahlen.
Ja es spart dir ein paar Watt im Idle aber kostet Chipfläche und damit Leistung in der Spitze, außerdem muss das ja noch sauber gemanaged werden.
Im Desktop würde man schon viel sparen wenn die Chipsätze nichtmehr in 45nm gefertigt werden. Auch mit besseren Powerstages kann man noch viel Energie sparen.

Für Notebooks vielleicht interessant. Aber auch nur wenn alles zusammen spielt. Die Little und Big Cores müssen zusammen genutzt werden können und die Core Zuweisung muss ebenfalls perfekt klappen.

 

[bensen]

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.

Wo wurde der L3 ausgelagert und wohin? Günstigerer Prozess?

 

[Kasjo]

Die Pumpe bei AIO auf die CPU zu setzen soll ein Entwicklungsaufwand sein? Ich schätze da sind 50 Leute drauf gekommen und einer hat es sich Patentieren lassen und bestimmt nicht der erste der darauf gekommen ist hat sich das Patentieren lassen.
Heutzutage wird jeder krumme Furz Patentiert nur damit man evtl. Lizenzgebühren kassieren kann oder man durch Patentrechtssteitereien evtl. auch groß abzukassiern kann.

Natürlich. Würde dich gern mal sehen wenn einer mit deiner Idee den großen Reibach macht und du leer ausgehst. Wer die Idee zu erst hatte is erst mal zweitrangig.

 

[Rockstar85]

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.

Schon mal daran gedacht, dass AMD hier einfach den Schritt mit den ARM Cortex nur konsequent zu Ende geht?
Was wenn AMD 2 Ryzen CCX mit 2 ARM Cortex kombinieren würde? Das wäre dank gleichen Addressierbereichs sogar möglich und dann braucht AMD auch keinen CATS Nachfolger. Den Gedanke habe ich schon länger da in Ryzen ja auch eine ARM CPU drin..
Warum also nicht konsequent die Rechenleistung von effizienten ARM Kernen mit Ryzen kombinieren?
Auch ein Joint Venture mit Mediatek ist immernoch im Rahmen des möglichen.
https://www.cnx-software.com/2020/0...-x1-a78-a55-processor-mediatek-5g-modem-leak/
Und sooo alt ist der Leak nun auch nicht. Am Ende wäre es einfach nur Konsequent.

 

[ghecko]

Was wenn AMD 2 Ryzen CCX mit 2 ARM Cortex kombinieren würde?

Das wäre ein absolutes Befehlssatz-Kuddelmuddel. Es gibt Gründe, warum x86 Code nicht auf ARM läuft und umgekehrt. Damit big.LITTLE funktioniert müssen die beiden Kerne zumindest Codekompatibel sein. Also entweder beide x86 oder beide ARM. Sonst muss alles für beide Architekturen compiliert vorliegen, alles hat also grob gesagt den doppelten Speicherbedarf. Wenn man hingegen einzelne Programmteile der einen oder anderen Architektur fest zuordnet, erinnert das ganze eher an einen statischen Hardwarebeschleuniger und nicht an einen nach Lastzuständen dynamisch wechselnden Core.

 

[WinnieW2]

Für Notebooks vielleicht interessant. Aber auch nur wenn alles zusammen spielt. Die Little und Big Cores müssen zusammen genutzt werden können und die Core Zuweisung muss ebenfalls perfekt klappen.

Ich habe mich gerade gefragt ob es sinnvoll sein kann die Little-Kerne bevorzugt dem Betriebsystem und dessen Dienste welche permanent im Hintergrund laufen zuzuweisen,
dann würde den Anwendungen die Big-Kerne praktisch exklusiv zur Verfügung stehen.
Andererseits profitiert die Performance von modernen PC-Betriebsystemen schon von SMT / HT was dies betrifft.

 

[Rockstar85]

Das wäre ein absolutes Befehlssatz-Kuddelmuddel.

Das ist mir klar, aber wir wissen ja nicht wie weit man hier am der x86 Kompatibilität gearbeitet hat.
Für mich klingt AMDs Ansatz auch anders als die Stapelchips von lakefield

 

[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.

Meines Wissens nach gibt der Core nur die eigene Identität zurück.

 

[pipip]

https://www.cnx-software.com/2020/0...-x1-a78-a55-processor-mediatek-5g-modem-leak/
Und sooo alt ist der Leak nun auch nicht. Am Ende wäre es einfach nur Konsequent.

Es gab 2015 schon mal ein Gerücht, dass Mediatek GPU Arch von AMD lizenzieren könnte.
Dieser Leak ist mir bekannt, aber AMD hatte bisher kein Interesse für diesen Markt.
Also wäre es am wahrscheinlichsten dass MediaTek so wie Samsung das lizenzieren könnte. Nur der Name spricht dafür, dass AMD was damit zu tun hat. Die ARM Core sprechen eher für das Design, welches MediaTek sonst nützt. Srandard Cores mit Mali GPU und deren HSA Lib plus NPU.

 

[ghecko]

aber wir wissen ja nicht wie weit man hier am der x86 Kompatibilität gearbeitet hat

Ein Prozessor, dessen Befehlsdecoder den x86-Befehlssatz unterstützt, ist ein x86-Prozessor. Intern sind seit dem Pentium Pro ohnehin alle gebräuchlichen Prozessoren quasi RISC und ARM ist das ebenfalls, nur eben konsequent.

Und AMDs Ansatz sieht momentan nach nicht mehr als einem Stück Papier aus, auf dem Pfeile und Rechtecke sind, ein typisches amerikanisches Patent eben. Ich glaube nicht dass die schon irgendwas in Hardware testen. Eher wollen die in Ferner Zukunft mitmischen, falls Intels Konzept aufgeht und Windows irgendwann damit umgehen kann.

 

[Rockstar85]

Daran glaube ich schlicht nicht, denn auch solche Entscheidungen trifft man nicht Mal eben so. Es kann durchaus sein, dass es nicht über einen Prototyp Status hinaus geht, aber etwas patentierten weil der Mitbewerber eventuell erfolgreich sein könnte, ist dann nicht mehr die Denkweise in einem Konzern.

Warten wir es einfach ab.

 

[textract]

Kann ich mir für den PC nicht vorstellen, solange Windows das vorherrschende OS ist.
Der Scheduler kam mit dem Release der Ryzen Many-Core Prozessoren ja schon nicht richtig zurecht, obwohl alle Kerne die gleichen Eigenschaften hatten.

Ein Prozessor, dessen Befehlsdecoder den x86-Befehlssatz unterstützt, ist ein x86-Prozessor. Intern sind seit dem Pentium Pro ohnehin alle gebräuchlichen Prozessoren quasi RISC und ARM ist das ebenfalls, nur eben konsequent.

Das stimmt doch so gar nicht. Der x86-Befehlssatz ist CISC und wird vor der Verarbeitung im Buffer in konstante RISC-Instruktionen übersetzt. Ich würde es eher als hybride bezeichnen.
Das funktioniert so ähnlich wie bei IBMs Z-Systemen.

POWER widerum ist eine RISC-Architektur.

 

[lowrider20]

Kann ich mir für den PC nicht vorstellen, solange Windows das vorherrschende OS ist.
Der Scheduler kam mit dem Release der Ryzen Many-Core Prozessoren ja schon nicht richtig zurecht, obwohl alle Kerne die gleichen Eigenschaften hatten.

Und auch beim Bulldozer und Win7 (oder war es 8) gab es Auslastungsprobleme.

 

[ghecko]

Der x86-Befehlssatz ist CISC und wird vor der Verarbeitung im Buffer in konstante RISC-Instruktionen übersetzt. Ich würde es eher als hybride bezeichnen.

Nun, kein aktueller x86 Prozessor wird als Hybride bezeichnet, obwohl sie nach deiner Definition (der ich durchaus zustimme) alle welche sind. Man nennt sie stumpf x86, weil aus Softwaresicht egal ist was Prozessorintern damit passiert. CISC ist als Konzept ohnehin längst ausgestorben. Im Pentium MMX 266 gab es für x86-Befehle keine Micro-Ops, da liefen die komplexen Befehle noch direkt auf der Hardware, ganz nach der CISC-Philosophie. Das war bei Intel aber der letzte Vertreter seiner Art.

Das stimmt doch so gar nicht.

Was stimmt so gar nicht? Natürlich könnte man einen ARM-Kern mit einem x86-Befehlsdecoder ausstatten. Dann wäre er aber per Definition nichts anderes als ein Matisse oder ein Comet Lake: ein RISC-Core mit x86-Frontend -> x86-Prozessor.

 

[latiose88]

Ergänzung (9. August 2020)

Irgendwie verstehe ich... Nix

Nun ich weiß zwar nicht was du nicht verstehst., ich erkläre es dir sehr gerne. Also im takst Manager oder als extras Software zeigt es mir alle threads des jeweiligen cpu an. Beim 3950x sind es ja somit 16 Kerne und insgesamt somit 32 threads. Ich gehe her und zwack 4 der 16 Kerne ab. Somit laufen 12 + 16 threads für die gewisse Software nur noch. In meinem Fall dann 28 threads. Diese z. B videoumwandlungs software names xmedia recode, hat somit für 2 x gleichzeitig insgesamt 28 threads zur Verfügung. Das entspricht somit ja im Grunde einem 14 Kerner.

Nun weiß ich ja nicht ob ich von den little cores profitieren würde oder nicht und ob einer der Vorredner auf meine Frage eingegangen war bzw ist. Wollte nur damit damit du es besser verstehst es dir erklären was ich eigentlich so meinte.

Ergänzung (9. August 2020)

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.

Ich kann das nur bestätigen was du zum Thema threadripper geschrieben hast. Ich habe sogar einem 2990wx mit einem 3970x ja auch unter anderem dank dir den Vergleich. 10 % zwischen 2990wx und 3970x sind da an unterschied. Das ist fast nix. Eigentlich dürfte ja dank der ganzen Optimierung der CPU ja eigentlich mehr an Leistung rauskommen,allerdings tut es das ja nicht. Das liegt halt an der Software. Zum 3950x sind es dann nur noch 17 % im vergleich zum 3970x. Das ist fast garnichts. Mir sagte bzw schrieb mir einer, damit ich da einen echten unterschied feststellen würde, müsste ich die Software 3x gleichzeitig ausführen und da dann alle 3 befüllen. Dann erst würde ich da einen unterschied feststellen. Dir Bedingung kann ich jedoch nie erfüllen. Für mich würde sich es sich nie lohnen, also im vergleich halt bzw im Gegensatz zu dir halt.

 

[pipip]

Ich stelle die Frage, wieso sich jeder darauf versteift, dass big, little nur dazu da ist um im Idle Strom zu sparen.
Ziel des Konzeptes sollte doch die Effizienz sein.

Sehr gut vorstellbar wäre das mit Smartshift. Effizienz wird gesteigert in dem man für die jeweilige Aufgabe dort die Last bringt, wo sie wirklich gebraucht wird.

Der große Core könnte ein Master sein, der von Windows einen Thread bekommt. Dieser selbst entscheidet dann was er dem Slave gibt. Das würde die Effizienz steigern und dabei etwas Fläche sparen zu zwei big Cores. Denn nicht alles hat Verwendung von SIMD. Deshalb steht ja auch full und low "features"

Der shared register deutet zu mindestens hin, dass der Big Core bescheid weiß, was der kleine macht.
Eventuell geht man so auch den Problemen von CMT in Bulldozer aus dem weg, wo zwei gleichwertige Cores sich Ressourcen geteilt haben und so teils erheblich behindern können. Hier hat einer von beiden Cores eindeutig das Zepter in der Hand. Somit wird um Effizienz zu steigern der andere eher "zugeschalten".
Strom wird dann so gespart, dass man den weiteren Chip eben deaktiviert, wenn er nicht gebraucht wird.

Dann stellt man sich die Frage, was könnte man gewinnen?
Eventuell das was man bei CPUs gerne macht um IPC zu steigern. Man geht in die Breite. 8 Threads könnten gut genützt die Performance von 16 Threads erreichen.
verwendet man aber Programme die nicht gut skalieren, dann hat man einfach nur die 8 Big Core.
Es wäre dann ein Hardwareansatz, womit viele Betriebsysteme offensichtlich Probleme hat. Multi Core, viele Threads sinnvoll auszulasten.

Das erste Bild könnte man sich als multi chips ebenso vorstellen. Big CPU Die und Little CPU Die über I/O chip und gegenseitig per IF im Verbund. Cache im I/O Die.

Aber wie schon jemand sagte hier, man sollte nicht zu viel aus den Bildern interpretieren.

Somit zurück zu meiner Frage. Muss Big Little zwanghaft was mit Idle Verbrauch zu tun haben, oder dient es nicht eher um die Effizienz und somit auch um die Performance zu steigern.

Naja in 5 Jahren sind wir bestimmt schlauer.