Zukünftige CPUs?

[BUGFIX]

Hi!
Ich habe mir die ganzen Diskussionen um DualCore usw. mal durch den Kopf gehen lassen. Dabei ist mir eine Idee gekommen:
Warum eingeltlich überhaupt noch CPU-Cores?
Heutige scheduler können aus einer Anzahl an Ausführungseinheiten logische Einheiten bilden und die Prozesslast so verteilen dass die vorahndenen Recheneinheiten besser genutzt werden.
Warum nicht ein Schrit weiter gehen?
Wenn man zum beispiel den Instruction-decode teil der CPU (mit I-Cache) zentralisiert, wäre es möglich (eine sehr leistungsfähige Anbindung vorrausgesetzt) die Einheiten Extern quasi zu Snap-Ins 'umzubauen'.
Damit wäre es möglich on demand zusätzliche ALUs, FPUs oder andere Einheiten nacchzurüsten. Statt umständlich jedes mal den Prozessor auszutauschen, wenn die Rechneleistung nicht mehr reicht, müsste man dann nur noch weitere FPUs bzw ALUs nachrüsten.

Mir ist klar, dass sich das jetzt gesponnen anhört, nur:
Das einzige was man dafür wirklich bräuschte wäre ein Prozess/Thread Scheduler der 'on th fly' virtuelle CPUs erstellt und wieder aufgibt (je nach bedarf), so dass der jeweilige Prozess nicht mit einer zu hohen Anzahl von Registern 'überfordert' wird, sowie eine Anbindung der Recheneinheiten an den 'CPU-Stamm' (also der Teil mit dem Command-decode und den Sppeicherkontroller)
Zu Zeiten von Alpha-Prozessoren und skalar-Architekturen (mit 4 - 32 Prozessoren pro 'Rechner') konnte man damals schon die Daughter cards mit den CPUs im 'Hot-Plug' Verfahren Austauschen. So schwer kann das also nicht sein.

Nur so als idee ....

MfG

BUGFIX

[][immy]

nun.. soweit ich das verstanden hab willst du die cpus in ihre bestandteile zerlegen, so das sich jeder selbst den "prozessor" zusammenstellen kann

gibt dabei nur ein paar probleme
1. die dinger sind viel zu klein
2. die latenzen durch den längeren weg (längere leitungen erforderlich) würden jeden performancezuwachs wieder zunichte machen
3. wer soll da noch den überblick behalten? gibt doch jetzt schon genug bugs dank unterschiedlichster rechnerkonfigurationen
4. hitzeentwicklung wäre verteilt und müsste an der jeweiligen stelle gekühlt werden
5. du bräuchtest immernoch eine "normale" cpu für die aufgabenverteilung. schließlich kann ein ein gerät nicht unbedingt wissen das es ein anderes gibt, welches es gerade braucht
6. jedes gerät bräuchte eine eigene stromversorgung. das würde einmal sehr viel mehr leitungen kosten als auch den stromverbrauch immens ansteigen lassen, was wiederum wahrscheinlich zu eine größeren hitzeentwicklung führen würde
.......

[BlackBirdSR]

[immy']gibt dabei nur ein paar probleme


eigentlich gibts nur 1 Problem:
x86
Alles Andere ist dann erstmal nicht relevant.
Man müsste erstmal am x86 Code vorbei.
Was bringen mir so und so viele FUs, wenn ich nur 2 Operationen im Schnitt ausführen kann?

[Alertstatus Red]

Du meinst 'ne Art Vector-Rechner? Machbar ist das schon, gerade Graka-Chips zeigen es das möglich ist. Mal abwarten, was in zukunft kommt, schon heute merken die CPU-Hersteller das mit der GHz- Wahnsinn nicht unendlich gehts, sehe z.B Intel, das der P4 4 GHz gecacelled hat. Was bleibt als Alternative wenn nicht das parallelisieren um mehr Rechenrpower erlangen? Mal gucken, glaube nicht das mit der Dualcore oder Multicore die richtige lösung ist, der teilung muss tiefer passieren, in der Struktur des CPU, nicht auf "discrete cores" ebene ....
Hyperthreading war eigentlich der richtige Weg, aber nicht so halbhertzig wie es intel implementiert. Softwaremässig muss man halt andere Wegen einschlagen, aber nach einige zeit, mache ich eine Wette, niemals würde darauf verzichten .... der Magische Wort ist teilen, nicht konzentrieren. Spezialisieren, nicht Veralgemeinen ;)

just my 0.02
And sorry for my poor German :)

[BUGFIX]

eigentlich gibts nur 1 Problem:
x86
Alles Andere ist dann erstmal nicht relevant.
Man müsste erstmal am x86 Code vorbei.
Was bringen mir so und so viele FUs, wenn ich nur 2 Operationen im Schnitt ausführen kann?

Man verteilt einfach freie 'Valenzen' und fasst sie logisch zu einer Zusätzlichen CPU zusammen. Wenn mein PRozess also nur 2 FPUs nutzt dann macht man mal eben fluz CPU 3 und 4 auf und ordnet die Prozesse neu zu.
Ich meine man könnte diese Überlegung sogar noch verfeinern. wenn man (wie beim AMD x86-64) den Intruktionsatz einfach erweitert , könnte man ohne probleme Neue und alte Software gleichzeitig einsetzten.
Ach wäre es möglich die Ausführungseinheiten später durch breitere (im sinne von 64 Bit oder größer) zu ersetzten. Vorrausgesetzt, die Anbindung zwischen Recheneinheit und Verwaltungsteil wäre breit genug.

Was genau siehst du als Problem von x86 an? Die umwandlung auf RISC oder ähnlich würde ja schon im Vorfeld passieren.

MfG

BUGFIX

[BlackBirdSR]

Man verteilt einfach freie 'Valenzen' und fasst sie logisch zu einer Zusätzlichen CPU zusammen. Wenn mein PRozess also nur 2 FPUs nutzt dann macht man mal eben fluz CPU 3 und 4 auf und ordnet die Prozesse neu zu.
Ich meine man könnte diese Überlegung sogar noch verfeinern. wenn man (wie beim AMD x86-64) den Intruktionsatz einfach erweitert , könnte man ohne probleme Neue und alte Software gleichzeitig einsetzten.
Ach wäre es möglich die Ausführungseinheiten später durch breitere (im sinne von 64 Bit oder größer) zu ersetzten. Vorrausgesetzt, die Anbindung zwischen Recheneinheit und Verwaltungsteil wäre breit genug.

Was genau siehst du als Problem von x86 an? Die umwandlung auf RISC oder ähnlich würde ja schon im Vorfeld passieren.

MfG

BUGFIX

So wie die x86 Architektur an sich beschaffen ist, kann man froh sein, wenn pro Takt 2 Befehle ausgeführt werden.
Mit Multithreading lässt sich vielleicht etwas tricksen, aber ich kann mir nicht vorstellen mit einer x86 Architektur viel höher zu kommen.
Die jetzigen CPUs können nichtmal mehr als 3 Befehle pro Takt beenden.

Deine Idee würde vielleicht klappen. Aber es wäre nicht mehr x86.
Und um x86 damit zu emulieren kostet wieder soviel Aufwand, dass man sich gleich erschießen kann, oder bei x86 bleibt.
Man bräuchte eine neue Architektur, die das auf Compilerebene alles schon erledigt, und die CPU nur stupide rechnen lässt.
Wie gerne das angenommen wird, zeigt sich ja mit IA64 :)

PS: Die Ausführungseinheiten sind schon 64Bit groß.
Ich gehe mal davon aus, dass wir so schnell keine 128Bit ALUs brauchen.
Bei SSE2 gehts mit den 64Bit (80) FPUs auch ganz gut.

[BUGFIX]

@BlackBirdSR:

Da muss ich jetzt doch nochmal nachfragen:
Deiner Argumentation nach ist AMD's weg mit dem Opteron usw auch kein x86 mehr.

Angenommen ich verbau in meiner 'Zusammensteck CPU' 4 FPU und 11 ALU Einheiten ( im sinne von Recheneinheiten wie sie in jedem x86 Prozessor zu finden sind).
Nun kann der normale x86 Code damit wahrscheinlich wenig anfangen, also erweiter ich den Instruction-Satz mit ein paar instruktionen die ich jetzt mal "Skalar87" nenne.
Für ein normales Programm macht der Scheduler 2 CPUs 'auf' (mit je 2 vollwertigen FPU), mein Skalar87 Programm aber könnte auf alle 4 Zugreifen ohne sich mit virtuellen CPUS rumschlagen zu müssen.

Ist sowas nicht schon heute möglich?
Eigentlich ist das doch nur eine Sache des Instruction decoders, oder?

MfG

BUGFIX

[Muh-sagt-die-Kuh]

Irgendwie ist mir der Nutzen dieses Ansatzes nicht ganz klar. Was willst du erreichen? Optimale Auslastung der vorhandenen Resourcen? Dynamische Zuteilung von Rechenzeit? Erweiterbarkeit? Das ganz hört sich, zumindest für mich, im Moment reichlich wirr an. Auch scheinst du, meiner Meinung nach, kaum den Aspekt der Parallelisierbarkeit von Algorithmen zu bedenken.

[Muh-sagt-die-Kuh]

Man verteilt einfach freie 'Valenzen' und fasst sie logisch zu einer Zusätzlichen CPU zusammen. Wenn mein PRozess also nur 2 FPUs nutzt dann macht man mal eben flux CPU 3 und 4 auf und ordnet die Prozesse neu zu.

MfG

BUGFIXOK, hier wird mir etwas klarer, was du meinst...

Kurz und knapp:
Eine solche Art der Zuteilung ist erstens komplizierter und zweitens symmetrischem Multithreading von der Effizienz her unterlegen.

[BUGFIX]

Vieleicht habe ich micht wirklich etwas zu vermurkst ausgedrückt ....
Also nochmal zum Nachvollziehen:
Wenn man sich die aktuelle technologie betrachtet:
- eine CPU hat immer die Gleiche Anzahl an Ausführungseinheiten
- wenn man mehr braucht heißt es entweder schneller werden (Takt) oder mit einer weiteren CPU mehr Recheneinheiten dazuholen.

Das ganze hat Nachteile:
Wenn ich zum Beispiel viel FP-Power brauche dann müsste ich schon fast ein 4er gespann aufmachen, da ich ja bei jedem Prozessor nur 2 PFUs bekomme.
4 Einzelne kann ich aber schlecht effizient aufteilen - entweder 3 weitere Prozesse aufmachen die unabhängig rechnen, (dann gibt aber kein speedup für die Rechnegeschwindigkeit aus sicht der Einzelrechnung) oder ich versuche die Rechenaufgabe zu parallelisieren.
Gleichzietig habe ich divere ALU Einheiten, die ich eigentlich nicht brauche (ich will ja FP rechnen) und trozdem laufen sie mit. Das heißt:
für jede FPU 'verholz' ich sowohl Strom als auch Platz und Geld.
Und davon will ich weg kommen.

Nach meinem Modell (was eigentlich keins ist) kaufe ich mir statt Prozessor 3 und 4 lediglich die von mir gewünschten Recheneinheiten und 'verbau' sie in meinem System.

Dass die technische Ausführung dieser Architektur wesentlich komplexer ist als hier von mir ausgeführt, ist klar.

Alles klar soweit oder immer noch zu unverständlich?

MfG

BUGFIX

[BlackBirdSR]

Nach meinem Modell (was eigentlich keins ist) kaufe ich mir statt Prozessor 3 und 4 lediglich die von mir gewünschten Recheneinheiten und 'verbau' sie in meinem System.

Dass die technische Ausführung dieser Architektur wesentlich komplexer ist als hier von mir ausgeführt, ist klar.

Alles klar soweit oder immer noch zu unverständlich?

MfG

BUGFIX

Du weisst aber schon, dass du für diese Recheneinheiten wieder ein Steuerelement brauchst, dass ihnen beiwohnt.
Selbst die VektorCPUs im ES haben jeder noch eine Scalare CPU damit das Ding auch funktioniert :P

[BUGFIX]

Du weisst aber schon, dass du für diese Recheneinheiten wieder ein Steuerelement brauchst, dass ihnen beiwohnt.
Selbst die VektorCPUs im ES haben jeder noch eine Scalare CPU damit das Ding auch funktioniert :P

Ja , das Steuerelement wäre dann quasi fix auf der CPU-Daughter Card verbaut. Quasi als Stammhirn - die Ausführungseinheiten würden dann aber wie heutige Prozessoren oder Ram-Module aufgesteckt.

dein " :P " werd ich hier mal stehen lassen - auch wenn ich ihn ehrlich gesagt nicht in einen vernünftigen Kontext zum post bringen kann.

MfG

BUGFIX