SimsP
PCGH-Community-Veteran(in)
Die Erklärung ist gar nicht so kompliziert:
Die Kerne einer CPU sind voneinander unabhängig und getrennt. Jeder Kern kann eine ganz andere Aufgabe erfüllen bzw berechnen.
Sprich: Kern 1 kann sich um das OS kümmern, Kern 2 berechnet Primzahlen, Kern 3 berechnet Pi, Kern 4 macht .....
Bei einer Grafikkarte hingegen sind alle Kerne aneinander "gebunden". Sie können alle gemeinsam den gleichen Rechenschritt ausführen, oder gar nicht.
Oder anders formuliert: wenn du versuchst, auf den ersten 300 Kernen der Grafikkarte Pi zu berechnen, und auf den anderen 300 Primzahlen, dann sind nur die einen 300 Kerne ausgelastet, während die anderen 300 Kerne Zwangspause halten müssen. Es ist schlicht nicht möglich, die Kerne unterschiedliche Aufgaben berechnen zu lassen.
Das stimmt so nicht ganz. Auch auf einer GPU hast du Mehrere Cluster die tatsächlich auch Aufgaben unabhängig voneinander bearbeiten können. Umgekehrt haben auch Prozessoren SIMD Einheiten, die letztlich dazu verdammt sind parallel die gleich Instruktion abzuarbeiten.
Der wesentliche Unterschied zwischen beiden Architekturen liegt in der Art der sequentiellen Instruktionsabarbeitung, weniger in der Art der Verteilung.
GPUs sind prinzipiell relativ "dumme" Architekturen. Vereinfacht gesagt nehmen die einen Befehl nach dem anderen aus dem Programstrom raus und arbeiten den ab. Wenn ein Befehl jetzt nicht gut parallelisierbar ist, verliert man zwar einiges an theoretisch möglicher Rechenleistung, doch das ist auch bei einer CPU nicht anders.
Was aber passiert zB wenn ich in mein Programm eine if Abfrage rein mache, oder ein Schleife? Für ein herkömmliches sequentielles Programm ist das nicht unüblich. Die CPU ist für so eine Situation mit einem Haufen von Schaltkreisen ausgestattet, die genau diese Art von Probleme behandeln. Sprungvorhersage, Out of Order Execution, Forwarding, Schattenregister nach Schema Tomasulo Architektur etc.
Bedeutet bei der CPU wird ein nicht unerheblicher Teil an Transistoren dafür ausgegeben den sequentiellen Befehlsfluss möglichst perfekt vorherzusagen/zu sortieren, sodass die Pipeline ständig gefüllt ist und man zB nicht bei einer if-Abfrage erst auf das Ergebnis warten muss, um zu wissen was als nächstes gemacht werden soll, sondern zb in der Zwischenzeit andere Befehle vorzieht. Kurz gesagt. Jeder CPU Kern ist perfekt darauf optimiert einen sequentiellen Befehlsstrom so aufzulösen, dass die CPU möglichst permanent Arbeit hat.
Eine GPU verfolgt hingegen ein anderes Konzept. Damit man sich den Spaß von einer riesigen Anzahl an ALUs (also Rechenwerken) auf einem Chip leisten kann, muss man eben an anderer Stelle Abstriche machen und das betrifft maßgeblich den Teil, der die sequentielle Befehlsausführung bei der CPU optimiert. Deswegen ist es notwendig einer GPU schön forgefertigte Instruktionshäppchen zu geben, die sich möglichst gut parallel verarbeiten lassen, am besten keine Sprünge mehr enthalten und am aller besten noch optimale Speicherzugriffsmuster haben, weil man sonst schnell in Gefahr läuft bedeutend langsamer zu sein, als auf einer CPU.
Daher denke ich auch nicht, dass Huang sich in seiner Aussage auf normale General Purpose Systeme bezog, sondern tatsächlich auf Spezialfälle wie Deep Learning, wo auch heute schon die CPU eigentlich nicht mehr zu tun hat, als Daten zwischen Hauptspeicher und GPU-Speicher hin und her zu schaufeln (bzw. bei HSA Systemen in Zukunft nicht mal mehr das). Hier könnte eine GPU-ähnliche Architektur tatsächlich als Haupt-Prozessor Sinn machen.