latiose88 schrieb:
Das mit den register ist interessant. Wusste nicht das des für die Anwendung unsichtbar ist.
Man unterscheidet heute zwischen zwei Arte von Registern, einmal die Architekturregister, also die Register die in der ISA fest gelegt werden, bei x86 sind das die Register
RAX, RBX, RCX, RDX, RBP, RSI, RDI
und
RSP
sowie die
FPR0
bis
FRP7
(später dann
MMX0
bis
MMX7
oder als
XMM0
bis
XMM7
). In den späten 1970er waren Transitoren "teuer" und entsprechend hat man an Registern in den ISAs damals auch gesparrt, weil man wo die Schaltungen wo anders brauchte.
Mit x64 hat dann AMD - weil das damals auch bereits zu Problemen führte, da man mehr Load- und Store-Einheiten brauchte - die Register
R8
bis
R15
und
XMM8
bis
XMM15
eingeführt. Die SSE-Register werden heute auch als AVX-Register genutzt, heißen dann halt wieder anders, aber lassen wir das mal weg.
Die Software sieht nur dieses 16 + 16 Register - und noch ein paar Spezialregister, mehr nicht. Da heutige Prozessoren superskalar arbeiten und Befehle auf - bei AlderLake bis zu 6 - kommt es vor, dass zwar Befehle "theoretisch" Nebenläufig sind, aber durch Namesgleichheit der Register nicht Nebenläufig arbeiten können. Um in diesem Fall doch eine Nebenläufigkeit zu ermöglichen, gibt es das Register-Renaming bei OoO-Prozessor, damit man mehre Befehle nebeneinander ausführen kann, ohne dass sie sich bei den Registern in die quere kommen.
Da Befehle dann auch spekulativ ausgeführt werden aber auch ein Prefetching der Daten statt findet um sie in die Register zu laden, brauchst du eine gewisse Anzahl an zusätzlichen Hardwareregistern, also die Register, die die CPU wirklich hat, in denen sich die "Optimierungen" austoben können. Ebenso brauchst du für SMT viele Register mindestens einmal "doppelt", da du ja zwei Task hast, die da ablaufen und sich diese nicht in die queere kommen dürfen.
Zen hatte 168 Register, Zen 2 hatte 180 Register und Zen 3 hat nun 192 Register und das hängt bei Zen 2 und 3 damit zusammen, dass man den Sort-Order-Buffer vergrößert hat - also man mehr Befehle umsortieren konnte - ebenso, dass man die Load/Store-Queue vergrößert hat, dass man die Lookaside-Buffer und Co vergrößert hat und damit auch mehr Daten "vorladen" konnte, die dann irgendwo Platz finden müssen, damit die Daten bereit liegen, wenn sie gebraucht werden.
latiose88 schrieb:
Und heißt es je mehr register desto besser für die CPU oder kann sich durch das auch nicht mehr ab einen gewissen Punkt mehr abarbeiten. Wie sieht es aus in der Hinsicht.
Nicht automatisch, weil sowohl der "Kern" aber auch das Programm etwas mit den Registern anfangen können müssen.
Ein Zen 5 oder OceanCove (Nachfolger von GoldenCove) würden nicht automatisch schneller werden, nur weil man weitere Hardwareregister hinzufügt, sondern die Register würden ab einem gewissen Zeitpunkt brach liegen, wenn man nicht andere Parameter anpackt. Genauso würde die CPU nicht automatisch schneller oder effizienter werden, nur weil man noch mehr Daten vorladen kann in die Register, da ja immer wieder auch ein "ungeplanter" Sprung vorkommen kann und dann die geladenen Daten umsonst geladen wurden.
Die Größe Registerfiles einer CPU wird in der Regel anhand der ALUs, Load- und Store-Einheiten, des Größe des Reorder-Buffers, der tiefe der Branche-Prediction und eben der Architekturregister ausbalanciert. Man braucht bei den "Registern" einfach nur genug und mehr "hilft" nicht unbedingt.
latiose88 schrieb:
Zen 3 hat da ja mehr, ja nicht jede Zen 3 rennt automatisch Zen 2 davon.
Anders Beispiel wäre SunnyCove zu GoldenCove: Beide haben 280 Register, dennoch legte GoldenCove ca. 20 % IPC zu. SunnyCove hat damals den "Register-Overkill" gezündet, aber erst GoldenCove kann jetzt mit den weiteren Umbauarbeiten damit wirklich umgehen und daraus nutzen ziehen.
Die Architekturregister wirken sich dirkt auf die Software aus und legen dann fest, wann ein Compiler mit Load/Store-Anweisungen agieren muss, die Hardwareregister sind für die Optimierunge auf der Hardwareebene wichtig, damit sie sich austoben können.