Kernverschmelzung vielleicht doch möglich?

[Piffan]

Hi

Obwohl ich jetzt ne Menge Blech schreibe, bitte ich doch um Prüfung durch Fachkundige, ob nicht ein Körnchen davon realisierbar wäre.

Zunächst mal, was ich von Multicore weiß/zu wissen glaube (jetzt wirds peinlich): Die Cores samt Caches laufen diskret, haben keinerlei Interaktivität auf Hardwareebene. Das heißt im Klartext, dass Lieschen REchnung von der Addition der Taktraten Lötzinn ist. Ob Multicore was bringt, hängt einzig und allein davon ab, wie hoch der Prozentsatz von parallelisierbarem Code ist. Auf Spiele übertragen heißt es, dass ab einer bestimmten Core- Zahl eine weitere Erhöhung der Corezahl einfach nix mehr bringt. Sobald der parallelisierbare Teil des Gameloops aufgeteilt ist, sind die überzähligen Cores arbeitslos und die Performance skaliert nur noch mit der Taktzahl......

Und jetzt die Idee: Muss das so sein? Gibt es keine Überlegung, die Cores untereinander so zu verbinden, dass sie gemeinsam auf eine Pipeline zugreifen, auf einen einzigen Cache usw.? Damit das einen Nutzen haben kann, müssten die Cores mit verschobenen Taktphasen laufen. Der Proz müsste asynchron laufen. Beispiel: Core A fischt sich Daten aus der Pipeline und rechnet. Das Ergebnis wird rausgeschrieben. Normalerweise dauert es nun wieder eine volle Taktlänge, bis der nächste Schritt beginnt. Wäre Core B nun phasenverschoben, könnte er nach einem Bruchteil der Taktdauer mit der Arbeit fortfahren........

Leider habe ich null Plan von sowas, ist ja auch nur ein Gedankenexperiment....Aber falls das ginge, würde folgernder Nutzen entstehen: man könnte maximal die effektive Taktzahl verdopplen, indem die Wartezeiten zwischen Ausgabe des Zwischenergebnisses und Weiterbearbeitung stark reduziert werden. Müsste man dafür die Taktzahl der Zwischenspeicher verdoppeln? DDR- mäßig?.......

So, ich ahne ja schon, dass es alles Käse ist bzw. wenn es ginge, dann gäbe es das schon längst..... :D

[BlackBirdSR]

Piffan[/POST]']
Und jetzt die Idee: Muss das so sein? Gibt es keine Überlegung, die Cores untereinander so zu verbinden, dass sie gemeinsam auf eine Pipeline zugreifen, auf einen einzigen Cache usw.? Damit das einen Nutzen haben kann, müssten die Cores mit verschobenen Taktphasen laufen. Der Proz müsste asynchron laufen. Beispiel: Core A fischt sich Daten aus der Pipeline und rechnet. Das Ergebnis wird rausgeschrieben. Normalerweise dauert es nun wieder eine volle Taktlänge, bis der nächste Schritt beginnt. Wäre Core B nun phasenverschoben, könnte er nach einem Bruchteil der Taktdauer mit der Arbeit fortfahren........



Viele Schritte dauern aber numal genau einen Takt, bzw mehrere Takte.
Nur der Pentium4 hatte so etwas in dieser Richtung, aber auch nur bei zwei sehr simplen ALUs.

Ich bin der Meinung, dass es nicht an roher Kraft fehlt.
Das Problem ist eher die Befehle zu den Ausfürhungseinheiten zu bekommen, und davon so viele wie möglich.
Wenn ein Programm eine Leistungscharakteristik von 0-7-1.3 IPC aufweist, langweilen sich die Ausführungseinheiten die meiste Zeit.
Wenn jetzt noch ein zweiter Kern dazu kommt, und etwas tun will, dann stören die sich eher noch.
Aus diesem Grund halte ich für SMT für eine sehr gute Idee. Nicht weil die CPU pro Takt mehr Leistet, sondern weil es weniger Leerlauf gibt.

Wirklich gute Ideen sind spekulative Berechnungen, die der erste Kern einfach nicht durchführen kann.
Die Kerne zusammenschalten um damit die rohe Rechenleistung zu verdoppeln scheint mir nichts zu bringen (im Gegensatz du GPUs).
Was bringen mir 500 Wasserträger, wenn ich nur Wasser für 150 aus dem Brunnen schöpfen kann? ;)

[Piffan]

Spekulativ heißt, dass man bei Aufzweigungen einfach schon mal auf "Verdacht" in einer Richtung weitermacht bevor der Thread die Verzweigung erreicht? Quasi einem arbeitslosen Core sagt: Wir wissen nicht wie es weitergeht, aber tun wir doch so als ob wir es schon wüssten und du machst mal in dieser Richtung weiter....

Wenn mehrere Cores gerade "rumstehen", könnte man ja mehrere Varianten auf Vorrat rechnen....Im Extremfall könnte man die Sache ja soweit treiben, dass das spekulative Ergebnis auf den Hauptthread zurückwirkt....Im Sinne von Ki oder so........

Naja, fantasieren mit 1 Prozent Wissen hat einen Vorteil: Man ist von den harten Realitäten befreit. :D

[BAGZZlash]

In Frankreich wird gerade ein Versuchsreaktor zur Kernfusion gebaut, die dafür nötigen Supraleiter für die starken Magnete stehen ja endlich zur Verfügung... :wink:
Im Ernst: Deine Idee mit den asynchron laufenden Kernen ist 'ne super Sache, das Problem ist, daß gerade nicht-parallelisierbarer Code sich dadurch auszeichnet, daß der eine Befehl auf das Ergebnis des anderen warten muß. Erst dann kann's weitergehen, auf welchem Kern, ist dann egal... ;(

[Gast]

Piffan[/POST]']Aber falls das ginge, würde folgernder Nutzen entstehen: man könnte maximal die effektive Taktzahl verdopplen, indem die Wartezeiten zwischen Ausgabe des Zwischenergebnisses und Weiterbearbeitung stark reduziert werden. Müsste man dafür die Taktzahl der Zwischenspeicher verdoppeln? DDR- mäßig?.......



sowas nennt sich pipeline-forwarding und ist in jeder aktuellen cpu (in jedem kern) implementiert.

was prinzipiell möglich wäre, anstatt 2 "echter" cores die ausführungspipeline doppelt so breit zu machen und über hyperthreading (oder einer ähnlichen technologie) ermöglicht man mehreren threads gleichzeitig die rechenpipeline zu benützen.

damit hätte man einen core der es einem thread zumindest theoretisch ermöglicht alle ausführungseinheiten zu benutzen, andererseits aber mehrere threads gleichzeitig in der pipeline bearbeiten kann.

da man aber selbst einen heutigen einzelnen kern mit einer anwendung praktisch nie auslasten kann, wird das ganze kaum etwas bringen, weshalb es fraglich ist ob ein cpu-hersteller sich diesen aufwand antut, nur um single-threaded programme im einstelligen prozentbereich zu beschleunigen (programme die bereits auf mehrere cores ausgelegt sind haben ja nichts davon)

soetwas ähnliches wäre auch das einzige was ich mir unter dem herumgeisternden "reverse-hyperthreading" bzw. "anti-hyperthreading" vorstellen könnte, wobei ja alleine schon die begriffe schwachsinn sind, da es sich ja tatsächlich um eine art von hyperthreading handelt.

im unterschied zu intels bisherigem hyperthreading wären dort nicht nur die register sondern wirklich die gesamten aufsführungseinheiten mehrfach vorhanden.

[BlackBirdSR]

Ich denke nicht, dass es sich hier um irgendeine Form von hyperthreading handelt, was ja auch nur Intels Name für die eigene SMT-Implementation ist.

Vielleicht gibts einen Trick um mehr Performance zu erreichen. Allerdings auch nicht als anti-SMT.

[LordDeath]

wie wärs mit folgendem:
zwei cores machen immer eine berechnung abwechselnd. also der eine idlet jeden geraden takt, der andere bei jedem ungeraden takt.
dadurch müsste die temperatur bei vollast niedriger werden und man könnte beide cores höher takten. würde das mehr als 50% takt (wo geidlet wird) ergeben?

[Gast]

LordDeath[/POST]']wie wärs mit folgendem:
zwei cores machen immer eine berechnung abwechselnd. also der eine idlet jeden geraden takt, der andere bei jedem ungeraden takt.
dadurch müsste die temperatur bei vollast niedriger werden und man könnte beide cores höher takten. würde das mehr als 50% takt (wo geidlet wird) ergeben?

das würde nur zu einer besseren wärmeverteilung im die führen, aber nicht die leistung erhöhen, das ganze jeden takt zu machen wäre aber denkbar blöd.

der L1-cache ist ja exklusiv für jeden core, und wäre dann praktisch für nichts.

bei jedem wechsel müsste außerdem das betriebssystem eingreifen was wieder leistung kostet.

ein wechsel nachdem ein prozess einige zeitscheiben rechnen durfte, wird eventuell je nach OS sogar gemacht, auch dieses kostet (sehr wenig) leistung, mehr leistung kannst du mit einer derartigen methode nie bekommen.

[LordDeath]

ich dachte dabei nicht an eine softwarelösung. das OS sieht nur einen core. aber ich denke auch nicht, dass mit 50% weniger auslastung über 50% mehr takt drin sind.

[Gast]

LordDeath[/POST]']ich dachte dabei nicht an eine softwarelösung. das OS sieht nur einen core. aber ich denke auch nicht, dass mit 50% weniger auslastung über 50% mehr takt drin sind.

das sicher nicht, und du musst ja auch noch den fall vorsehen, dass mal eine dual-core-optimierte software kommt und die auslastung/core über 50% ansteigt ;)

die lösung kann nur per OS funktionieren, die anwendung weiß ja nicht auf welchem kern sie läuft.

die taktung wird einerseits durch die vernünftig mögliche kühlung, andererseits durch das langsamste glied in der pipeline limitiert (je nach design)

da du ja nicht einen befehl mitten aus einer pipelinestufe eines cores reißen und auf dem anderen core dort weitermachen kannst, wird der mögliche mehrtakt gegen 0 tendieren.