Massives SMT statt Replay?

[Wuge]

Moin Moin,

ich als heimlicher Netburst-Anhänger hab mir gestern mal einen alten Artikel durchgelesen. Dabei kam ich zu folgendem Ansatz:

Zum Zeitpunkt der Entwicklung v Netburst wurde versucht die Performance im Single-Threaded-Betrieb zu maximieren. Oder besser gesagt, die Leerlaufzeiten der langen Pipeline zu minimieren. Die Folge ist der optimistische Sheduler und als Folge das Replay.

Jetzt, wo Programme mehr und mehr multithreaded ausgelegt sind, könnte man da nicht komplett auf die spekulative Ausführung verzichten und die Funktionseinheiten mit Hilfe mehrerer Threads auslasten?

Das Konstrukt ist natürlich erstmal theoretischer Natur, da Netburst (zmdst. offiziell) nicht mehr weiterentwickelt wird. Mich würde aber mal interessieren, was Ihr dazu denkt. Was mich nicht interessiert ist, dass andere Architekturen eh effizienter sind. Das weiß ich selber :)

[Demirug]

So etwas lies sich schon machen. GPUs arbeiten ja nach diesem Prinzip. Eine CPU würde sich damit aber die gleichen Probleme einhandeln. Man braucht viel Chip interne Speicher für die Register und für die Caches ist eine große Anzahl von Threads auch nicht gerade gut. Zudem dürfte der Kosten Nutzen Faktor von vier Kernen gegenüber einem mit vierfachem Takt besser sein da die Energieaufnahme ja überproportional zum Takt steigt. Geht man zudem von den teilweiße bis zu 100 Takte „Verlust“ aus die Netburst zum Teil hatte bräuchte man viele Threads zum kompensieren.

[Undertaker]

Zudem dürfte der Kosten Nutzen Faktor von vier Kernen gegenüber einem mit vierfachem Takt besser sein da die Energieaufnahme ja überproportional zum Takt steigt.

eigentlich nicht ganz exakt, überproportional wirds nur weil man für den höheren takt auch eine höhere spannung braucht ;)

[Demirug]

eigentlich nicht ganz exakt, überproportional wirds nur weil man für den höheren takt auch eine höhere spannung braucht ;)

Wenn wir jetzt Detailreiterei betrieben wollen müssten wir auch noch auf die Auswirkungen des höheren Takts auf die Widerstände usw. weiter eingehen. Die Konsequenz bleibt aber immer die gleiche.

[Wuge]

Geht man zudem von den teilweiße bis zu 100 Takte „Verlust“ aus die Netburst zum Teil hatte bräuchte man viele Threads zum kompensieren.

Der enorme Verlust entseht ja hauptsächlich durch Cache-Misses. So häufig sollte das ja nicht gleichzeitig bei mehreren Threads vorkommen.

Die "echte" Auslastung der Funktionseinheiten des P4 soll um die 33% liegen.

Würde man mit 2 oder 4-Way SMT nicht in Richtung Maximalauslastung kommen?

Im Vergleich zum 4-Core Design würde man sich immerhin 3x Frontend + 3x Sheduler sparen.

[Der_Donnervogel]

AFAIR war es doch so, daß die Funktionseinheiten des P4 absichtlich eher schlecht ausgelastet wurden um zu verhindern, daß diese überhitzen, was wiederum den maximal erreichbaren Takt verringert hätte. Wenn man nun aber das Design so umbauen würde, daß die Einheiten möglichst voll ausgelastet würden, würde das den maximal erreichbaren Takt sicher deutlich runterdrücken. Ob sich das lohnen würde, müßte sich dann erst noch rausstellen.

[Coda]

Kann eigentlich nicht sein, da Replay die ALUs die ganze Zeit beschäftigt.

[Endorphine]

Wenn man die Idee zu Ende denkt landet man imho bei EPIC/IA64. Und diese Architektur hat sich nicht durchgesetzt.

[Der_Donnervogel]

Kann eigentlich nicht sein, da Replay die ALUs die ganze Zeit beschäftigt.
War das beim P4 nicht so, daß maximal 3 Mikro-Ops pro Takt aus dem Trace-Cache in die Pipelines leiten konnte und darum die Rechenwerke nie völlig ausgelastet werden konnten?

Falls ich hier grad totalen Stuss erzählt hab bitte korrigieren, denn ich laborier grad etwas an ner Grippe, könnte also schon sein. http://www.web-smilie.de/smilies/kranke_smilies/puke.gif

[Coda]

Ja schon, aber Replay rechnet solange an einer Instruction rum in manchen Fällen bis die Daten den Weg RAM->L2->L1->Register genommen haben (also mehrere hundert Takte). Und das passiert gar nicht mal so selten ;)

[Wuge]

Oder andres herum gedacht, Hyperthreading in der bekannten Form weiternutzen und das Replay deaktivieren.

Damit sollte zumindest der Energieverbrauch reduziert werden ohne die (multhithreaded-)Leistung zu verringern...

Wieso gibts nirgends Simulatoren für logische CPU-Designes im Netz. Damit zum zu spielen wäre sicher interessant ;)

[Coda]

Das Problem daran wäre halt das der serielle Code unglaublich langsam wäre. Und Netburst ist ja so schon nicht gerade so doll darin.

[micki]

ich glaube solche simulatoren gibt es, auch einen in sorceforge... hab leider den namen vergessen.

ich glaube auch, dass in zukunft soein design mit massiv SMT greifen wird bei den cpus (sowas in der art gibt es ja schon von SUN mit ihrem Sparc).
die gpus machen es ja vor, man kann latenzen von bedingten verzweigungen und speicheranforderungen unglaublich gut hinter SMT verbergen. das problem ist wohl, dass diese virtualisierung unglaublich viel speicher braucht, denn jeder thread braucht sein register-set. andererseits koennte man den ganzen OOO-"misst" rauswerfen, wenn man das auf diese weise loesen wuerde.