Warum überhaupt noch feste Anzahl von CPU Kernen statt flexibler ALU Gruppierung?

[Martyn]

Bin gerade auf den Gedanken gekommen das man heutzutage doch eigentlich garkeine feste fest vorgegebene Anzahl von CPU Kernen mehr bräuchte, sondern man einfach die CPUs einfach mit einem flexiblen Frontend und flexiblen Shedulern ausstatten könnte, welche die vorhandenen ALUs je nach gewähltem Profil flexibel auf virtuelle Kerne aufteilen könnten. Das könnt man dann über das EFI / BIOS erledigen.

Man könnte dann eine CPU Familie zum Beispiel in den Ausbaustufen 36+24+12 / 48+32+16 / 60+40+20 / 72+48+24 / 96+64+32 ALUs ( Integer + Gleitkomma + AVX ) und mit verschiedenem Maximaltakt anbieten.

Dann aber z.B. bei der mittleren 60+40+20 Stufe im EFI / BIOS folgende Einstellungen zulassen:

10 Performance-Kerne
4 Performance-Kerne + 12 Efficiency-Kerne
2 Performance-Kerne + 24 Efficiency-Kerne
4 Performance-Kerne + 8 Efficiency-Kerne + 4 ARM Kerne
4 Performance-Kerne + 6 Efficiency-Kerne + 6 ARM Kerne
2 Performance-Kerne + 20 Efficiency-Kerne + 4 ARM Kerne
2 Performance-Kerne + 16 Efficiency-Kerne + 8 ARM Kerne

10 Performance-Kerne wären wahrscheinlich ideal fürs Gaming, die Konfigurationen mit ARM Kernen aber zum Beispiel um Android-Apps nativ laufen zu lassen.

 

[wirelessy]

Ab zu Intel! Die brauchen gerade gute Leute

 

[JumpingCat]

Wird nicht genau das heute schon gemacht?

 

[honky-tonk]

ich würde vermuten, dass die flexibilität den Preis einer komplexeren und dadurch langasmeren Kommunikation unter den Elementen hat, was dann die performanz verringert. Soweit mir bekannt ist ohnehin halbleiter "platz" den man durch den schritt sparen würde ohnehin keine knappe ressource un man eher etwas platz benötigt um die abwärme abführen zu können.

 

[Krik]

Was du willst ist also quasi eine CPU nach GPU-Vorbild. Dort gibt es auch "ALUs", die man allerdings Unified-Shader-Einheiten (oder CUDA-Cores oder Shader-Cores oder ALU-Cores) nennt.

Für MIMO-Aufgaben (multiple input and multiples output) mit überschaubaren Aufgabenbereich ist das ein gutes Design, aber bei unserer Desktop-Arbeit überwiegen eher komplexe, nichtlineare Aufgabenstellungen.

Massiv-parallele Verarbeitung ist gar nicht nötig und auch oft nicht möglich. Also wozu Geld in ein entsprechendes Design stecken, das kein Vorteil bietet? Im Gegenteil: Statt die Prozesse auf eine relativ überschaubare Anzahl von Kernen zu verteilen, muss jetzt bei jeder kleinen Aufgabenstellung vom Scheduler immer wieder geschaut werden, wo denn der Prozess als nächstes ausgeführt werden muss. Der Prozess springt dann also von ALU zu ALU. Das ist extrem ineffizient. Programme leiden heute schon teils unter enormen Performance-Verlusten, wenn sie vom Scheduler von Kern zu Kern verschoben werden.

 

[qiller]

Für mich klang das Konzept, was Jim Kellers Truppe bei Intel sich ausgedacht hatte (bis sie gegangen sind), sehr interessant: Rentable Units statt Hyperthreading. Tweaktown dazu:

Beast Lake Next rumored with 2x IPC over Raptor Lake

Instead of losing P-Core counts and getting smaller and more efficient cores, there would've been monster cores with "Rentable Units". These RU modules would have 2 threads per RU module, which wasn't Hyper-Threading. If you need lots of performance... they stay as one, if you need more threads, they split up dynamically. That. Would've. Been. Exciting, Intel.

Read more: https://www.tweaktown.com/news/1002...ver-raptor-pat-gelsinger-killed-it/index.html

Ob das am Ende auch den erhofften Performance-Sprung gebracht hätte, steht natürlich auf nem anderen Blatt. Aber das Konzept war auf jeden Fall mal "anders".

 

[Krik]

Klingt für mich nach Hyperthreading, das nach Bedarf an- und abgeschaltet werden kann. Die hätten damit vor dem gleichen Problem gestanden wie AMD jetzt mit 9900X3D-CPUs, wo nicht alle Chiplets den 3D-Cache haben. Wo soll ein Prozess ausgeführt werden? Braucht der jetzt mehr Performance oder reicht weniger auch aus? Das ist an sich nicht für einen Computer entscheidbar, deswegen pflegt AMD auch eine entsprechende Liste von Programmen, wo drin steht, was auf welchen Kernen ausgeführt werden soll.

 

[Martyn]

Was du willst ist also quasi eine CPU nach GPU-Vorbild. Dort gibt es auch "ALUs", die man allerdings Unified-Shader-Einheiten (oder CUDA-Cores oder Shader-Cores oder ALU-Cores) nennt.

Ja, so in etwa hätte ich mir das vorgestellt.

Ob das am Ende auch den erhofften Performance-Sprung gebracht hätte, steht natürlich auf nem anderen Blatt. Aber das Konzept war auf jeden Fall mal "anders".

Das kann natürlich gut sein, aber irgendwie würde ich mir nach dme gefühlten technologischen Trippelschritten der letzten Jahre mal wieder was Grössers Neues wünschen.

 

[Krik]

@Martyn
Das täuscht, wenn man ein paar Intel-Generationen mal ausklammert. Die CPUs werden seit Jahren bei jeder Generation um 10-20 % schneller. Die CPUs bekommen immer mehr Kerne, sie enthalten mittlerweile auch verschiedene Arten von Kernen (mit/ohne 3D-Cache, P- oder E-Core). AMD führt Chiplets ein. Neuerdings enthalten sie NPUs. Da passiert also einiges.

Die modernen Highend-CPUs bieten so viel Leistung, dass man dafür passende Anwendungen schon suchen muss.

 

[Martyn]

Das ist es ja irgendwie gerade, wenn die Leistung eh schon hoch ist, dann sind 10-20% etwas das man einfach nicht mehr spürt.

Und den Sinn der NPUs verstehe ich auch nicht so ganz.

Beim den Ryzen 5 8600G und Ryzen 7 8700G für Sockel AM5 hat man eine NPU mit 16 TOPS und die Core Ultra für Sockel 1851 sollen je nach Variante eine NPU mit 13-21 TOPs haben.

Was kann man damit überhaupt anfangen. Das reicht ja nichtmal für den Microsoft Copilot. Den ich aber auch nicht so sensationell finde.

Die Ryzen AI für Notebook sollen auf 50-55 TOPS und die Core Ultra auf Lunar Lake Basis sollen auf 48 TOPS kommen. Das reicht dann gerade für den Microsoft Copilot aber nicht für viel mehr.

Hingegen hab ich von den GeForce RTX 5000 GPUs von 988 TOPS bei der RTX 5070 bis hin zu 3.352 TOPS bei der RTX 5090 gehört.

Bei einer CPU bei der sich die ALUs flexibel zusammengruppieren lassen würde ich zwar auch nicht davon ausgehen das sie einer GeForce GPU Konkurrenz machen können, aber zumindest in den Bereich von 150-500 TOPS könnte ich mir dann schon vorstellen.

 

[Krik]

Ich vermute, das Ziel der NPU in CPUs ist einfach, dass sie dann überall verfügbar sind. Auch auf Laptops ohne dedizierte Grafikkarte.

Bei den TOPS-Angaben frage ich mich immer noch, wie viel man wirklich braucht. Es gibt NAS, die bieten bspw. Foto-Apps an, die Bilder auf Wunsch automatisch kategorisieren können. Darunter gibt es auch Bilderkennung, sodass die Bilder später z. B. in "Hund" und "Auto" einsortiert werden. Selber Personenerkennung ist dabei, sodass man z. B. gezielt Bilder seiner Schwester heraussuchen lassen kann.
Das konnten die NAS schon, als NPU noch für network processing unit = Netzwerkkarte stand. Ja, sie haben diese Kategorisierungsaufgaben üblicherweise auf Zeiten geschoben, zu denen das NAS nichts zu tun hat (nachts), wenn man sich aber mal anschaut, was für schwache Hardware da drin steckt, dann ist das Ergebnis doch beachtlich.

Ich vermute stark, dass es zukünftig ähnlich zu NPUs mehr auf bestimmte Aufgaben spezialisierte Funktionseinheiten in der CPU geben wird. Es gibt da immer noch Potential.

 

[Naru]

Wird nicht genau das heute schon gemacht?

Wie genau das Instruction-& Thread-Level Parallelism realisiert werden, darüber schweigen die Herausgeber sich aus.
Eventuell richte man mal eine Anfrage an die Parallel Architectures and Compilation Techniques (PACT), denn sie hält das Patent dafür zu Händen.

Was in seiner Überlegung nicht mit bedacht worden ist, denn es ist maßgeblich, ist der Cache. Der lässt nicht flexibel verbauen; je mehr parallele Threads und Instruktionen, umso größer müssen die Cache-Stufen realisiert sein. Auch dafür ist ein Zenit gesetzt; das, was verbaut ist.

Ansonsten muss man sich überlegen, wie man es noch realisieren kann: Mehr Phasen aufkosten der Signallaufzeit? Insofern komme man um Spielereien à la NVIDIA Reflex nicht drumherum.