Warum bedeuten mehr Pipeline-Stufen in erster Linie größere Ineffizienz?

[HellHorse]

Das Bezieht sich auf die News:

Mittels dieser Verlängerung der Pipeline wird die gleiche Arbeit in mehr Pipeline-Stufen verteilt, was in erster Linie zwar eine größere Ineffektivität bedeutet, ...

Das deckt sich nicht so ganz mit meinem Verständnis vom CPU's. Da ich recht wenig von CPU's verstehe, nehme ich das als Grund, mein Wissen zu erhöhen.
Und Fragen kostet ja nix ;)

Natürlich hat ein Befehl länger bis er abgearbeitet ist, aber es können ja auch mehr gleichzeitig abgearbeitet werden. Zudem lässt sich die Arbeit gleichmässiger auf verschiedene stages (? richtiges Wort ?) verteilen, was die Wahrscheinlichkeit, dass mehrere auf eine andere warten verringert.
Klar wenn die Sprungvorhersage Scheisse baut, scheisst es mehr an, aber Leo schrieb ja selbst, dass der Prescott eine verbesserte Sprungvorhersage haben soll.

Hoffe es ist das richtige Forum.

Der Thread Titel ist Nonsens, bitte auf "Warum bedeutet eine längere Pipeline in erster Linie grössere Ineffizienz" oder so ändern

[Quasar]

Eine höhere Gleichzeitigkeit (i.e. mehr Parallelität) erreichst du nicht durch längere, sondern durch Rendundanz der Pipelines.

Das Fliessband-Analog ist m.E. noch das Beste.
An einem Fliessband stehen 10 Arbeitende, jeder schlägt in "Das Produkt" einen Nagel, setzt eine Schraube auf und dreht sie fest. (Dummes Beispiel, aber mein "Produkt" wird den Markt revolutionieren!!)
Dazu muss er den Hammer nehmen, draufschlagen, den Hammer weglegen, eine Schraube aus einer Kiste nehmen, die Schraube ansetzen und festdrehen.
Dies kannst du bis zu einer sinnvollen Grenze so erweitern, daß die einzelnen Arbeitsabläufe sich verkürzen.
So z.B. schlägt nur jeder zweite den Nagel fest und jeder erste schraubt.
Die einzelnen Schritte sind jetzt bsw. doppelt so schnell ausführbar (in der Regel schnellern, da dasHammer aufnehmen bei den Hämmerern, und das Schraube suchen bei den Schraubern entfällt), hier gewinnt man durch mehr Pipeline-Stages und hat die Möglichkeit, einen höheren Arbeitstakt einzuführen, da ja die einzelnen Stufen (Arbeiter) nun weniger zu tun haben.

Wenn du das jetzt bis ins Extrem fortführst, hast du irgendwann 100 Leute am Fliessband, 50 von denen schlagen jeweils einmal auf einen Nagel und die anderen drehen jeweils eine halbe Drehung an der Schraube.
Das geht pro Takt, also pro Arbeiter zwar wahnsinnig schnell, aber viel bringen tut's dir am Ende wenig, da halt der komplette Betrieb stillsteht, wenn einem Mal der Hammer aus der Hand fällt oder die Schraube schief angesetzt ist.

Sinnvoller ist da das zwischenlagern bsw. nachdem das Gehämmere fertig ist auf einem Stapel, von dem das Schrauben Fliessband bedient wird. Dazu brauchst du natürlich wieder jemanden, der die genagelten Produkte auf das Schraubenfliessband drauflegt - Overhead entsteht. Je nachdem, wie oft den Hämmerern der Nagel schiefgerät kann es lohnen, diesen Overhead in Kauf zu nehmen, oder eben nicht.

Am sichersten steigerst du deinen Output jedoch, wenn du eine zweite Produktionsstätte einrichtest.

Da ist das Problem dann, wenn die Auftragslage schlecht ist, haben vielleicht die Hälfte der Leute nichts zu tun und stellen nur einen Kostenfaktor dar.

P.S.:
Ich verstehe von CPUs auch nicht so viel, aber so kommt's mir schonmal recht plausibel vor. Mal schauen, wann GloomY, Endorphine, MDSK usw. aufwachen... =)

[Stone2001]

Also, der Theorie nach, erhöht eine längere Pipeline den Durchsatz einer Ausführungseinheit! Und zwar, weil man mehrere Befehle gleichzeitig bearbeiten lassen kann.
Und eine längere Pipeline ermöglicht es zusätzlich, die Ausführungseinheit höher zu takten, weil die einzelnen Bearbeitungsschritte schneller zu erledigen sind. (Man muß pro Schritt nicht soviel arbeiten.

Leider gibt es auch einige Probleme mit einer längeren Pipeline. Zum einen wäre da das Problem mit den Abhängigkeiten. Befehle können von einander abhängen, weil z.B. Befehl zwei das Ergebnis von Befehl eins braucht.
Und zum anderen gibt es Probleme, das wenn die Pipeline einmal leerlaufen muß (z.B. durch einen bedingten Sprung) müssen mehr Pipeline-Stufen wieder gefüllt.

Ich würde also sagen, das die Aussage generell falsch ist! Das eine längere Pipeline die Effektivität erhöht, es aber Probleme geben kann, die die Effektivität wieder vermindern.

[Leonidas]

Original geschrieben von Stone2001
Ich würde also sagen, das die Aussage generell falsch ist! Das eine längere Pipeline die Effektivität erhöht, es aber Probleme geben kann, die die Effektivität wieder vermindern.



Theoretisch richtig. Bei den heutigen Prozessoren gilt aber, das die Pipelines schon lang genug sind. Jede verlängerung bedeutet automatisch neue Probleme, welche in Ineffektivität enden. Man errreicht damit wie gesagt nur mehr Takt.

[BlackBirdSR]

Original geschrieben von Leonidas
Theoretisch richtig. Bei den heutigen Prozessoren gilt aber, das die Pipelines schon lang genug sind. Jede verlängerung bedeutet automatisch neue Probleme, welche in Ineffektivität enden. Man errreicht damit wie gesagt nur mehr Takt.

das ist aber sehr pauschal und engstirnig.
Siehe K7-K8
Nicht jede Verlängeren der Pipelines dient ausschließlich zum Strecken.

[Demirug]

Original geschrieben von BlackBirdSR
Nicht jede Verlängeren der Pipelines dient ausschließlich zum Strecken.

Bist du sicher das du das so schreiben wolltest?

Wenn man eine Pipeline verlängert streckt man sie dabei doch automatisch und das Ziel einer solcher Aktion ist immer die maximale Taktrate zu erhöhen.

Ich vermute jetzt mal das du darauf hinauswolltest das man aus der Länge der Pipeline nicht auf den Grad der Effektivität schliessen kann.

[BlackBirdSR]

Original geschrieben von Demirug
Bist du sicher das du das so schreiben wolltest?

Wenn man eine Pipeline verlängert streckt man sie dabei doch automatisch und das Ziel einer solcher Aktion ist immer die maximale Taktrate zu erhöhen.


wenn man die Pipeline verlängert, mit dem Ziel die Taktrate zu erhöhen, dann streckt man die Ausführung in die Länge.
Nutzt man die zusätzlichen Pipelinestufen allerdings, um neue Funktionen durchzuführen, und lässt die bisherigen Abläufe (weitgehend) unangetastet, dann erreicht man auch kaum eine höhere Taktrate. (es sei denn die Funktionen stehen im direkten Zusammenhang mit der Ausführung späterer Stufen bla bla bla)

Ich will einfach darauf hinaus, dass die Sache zu komplex ist, um es so einfach zu pauschalisieren.
Wohin das führt, haben wir ja schon beim TraceCache gesehen. :grenade:

[Demirug]

Original geschrieben von BlackBirdSR
wenn man die Pipeline verlängert, mit dem Ziel die Taktrate zu erhöhen, dann streckt man die Ausführung in die Länge.
Nutzt man die zusätzlichen Pipelinestufen allerdings, um neue Funktionen durchzuführen, und lässt die bisherigen Abläufe (weitgehend) unangetastet, dann erreicht man auch kaum eine höhere Taktrate. (es sei denn die Funktionen stehen im direkten Zusammenhang mit der Ausführung späterer Stufen bla bla bla)

Ich will einfach darauf hinaus, dass die Sache zu komplex ist, um es so einfach zu pauschalisieren.
Wohin das führt, haben wir ja schon beim TraceCache gesehen. :grenade:

OK, wenn du darauf hinaus wolltest will ich nichts gesagt haben.

[Haarmann]

HellHorse

Also ich versuch mich da auch mal auszudrücken - ev hilfts ja etwas.

Heutezutags hast ja nicht das einfache System, dass nur eine Instruktion durch die CPU geht und kaum ist diese fertig ne neue durchgeht. Auch dauert nicht jede Instruktion einen Takt. Das wiederum verträgt sich eher schlecht mit Programmen, die genau diese Eigenschaft haben, dass sie schön einen Befehl nach dem anderen darstellen. Nun muss man das irgendwie unter einen Hut kriegen. Nun "wachsen" nicht alle CPUs in die Breite, also mehr Befehle versuchen pro Takt ausführen, sondern zT in die Länge, womit man weniger Gatter pro Takt passieren muss und damit mehr Taktfrequenz erreichen kann. Die breiten CPUs müssen sehr viel Logik einsetzen, damit man die trennbaren Befehle auch trennt, welche den langen CPUs erspart bleibt. Die wiederum haben ein Problem, wenn ein Program sich verzweigt und brauchen dementsprechend mehr Logik für die Sprungvorhersage, welche den Breiten erspart bleibt. Natürlich ist dies nicht absolut zu sehen, denn auch lange CPUs haben ne Breite etc.
Bei 5 Funktionseinheiten und 30 Pipelinestufen kämen im Extremfall 150 Zwischenresultate hervor, die man pro Takt fürs Wiederherstellen eines Zustandes benötigte. Ich denke hier liegt der Kern für die Ineffizienz. Hier müssen also im Extremfall 30*30*5=4500 Zustände noch vorhanden sein, will immer wieder alles auf jeden Zustand zurücksetzen können.
Der Langen Rede kurzer Sinn. Die Breite wirkt nur linear, wogegen die Länge immer im Quadrat wirkt. Dies müsste meiner Meinung nach dafür sorgen, dass ne längere Pipeline einer Vermehrung der Pipelines unterliegt bei x86. Bei nur 11 Stufen und 8 Einheiten sinds nur noch 11*11*8=968. Da zudem jede Stufe einen gewissen Ballast an Laufzeit mitträgt wirken sich zusätzliche Stufen nicht so stark aus wie zusätzliche Einheiten. Halbe Zahl an Stufen ist also ungleich halber Takt.

Das ist nur ein Erläuterungsversuch und ist vorsätzlich nicht in Fachchinesisch verfasst.

[Stone2001]

@Haarmann:
Kannst du uns mal ein Beispiel für eine 'lange' und für eine 'breite' CPU geben?

[Haarmann]

Stone2001

Schon Intels P4 geht durchaus als lange CPU durch, aber der alte MIPS R4000 hat soweit ich weiss 8 Stufen und sozusagen nur eine Funktionseinheit.
Die VLIW CPUs sind dann das beste Exempel für nen sehr breiten CPU, wobei hier etwas fauler Zauber dasteht, denn diese Dinger können sich den "Verteiler"/"Umordner" der Befehle einsparen, weil dazu der Compiler dient. Aber immerhin die Teile taugen bestens für den Vergleich.

[Stone2001]

hmm, VLIW, ich dachte mir schon, das die Architektur jetzt kommt! Aber du hast dir damit selbst wiedersprochen. Wenn ich dich mal Quoten dürfte:
Original geschrieben von Haarmann
Die breiten CPUs müssen sehr viel Logik einsetzen, damit man die trennbaren Befehle auch trennt, welche den langen CPUs erspart bleibt.
Gerade VLIW Prozessoren brauchen keine großen Logiken um Befehle zu trennen, diese Aufgabe übernimmt der Compiler. (wie du ja schon gesagt hast)

Prozessoren mit langen Pipelines dagegen, brauchen eine komplexe Logik um die Abhängigkeiten zwischen den Befehlen zu beseitigen und für eine möglichst gute Auslastung der Ausführungseinheiten zu sorgen.

Aber man sollte anmerken, das der Vergleich zwischen der x86-Architektur und der VLIW Architektur etwas hinkt. Es sind eben zwei verschiedene Architekturen, beide mit Vor- und Nachteilen.

Generell würde ich aber sagen, das 'breite' CPUs einfacher sind als 'lange' CPUs. Da 'lange' CPUs recht viel mit hardware Logiken lösen und sich 'breite' das Ganze vom Compiler lösen lassen.

[Leonidas]

Original geschrieben von BlackBirdSR
Nutzt man die zusätzlichen Pipelinestufen allerdings, um neue Funktionen durchzuführen, und lässt die bisherigen Abläufe (weitgehend) unangetastet, dann erreicht man auch kaum eine höhere Taktrate. (es sei denn die Funktionen stehen im direkten Zusammenhang mit der Ausführung späterer Stufen bla bla bla)



Stimmt absolut. Leider wird diese Methode bei heutigen PC-Prozessoren kaum noch angewandt, es wird lieber die Leistung auf mehr Stufen verteilt, so daß jede Stufe für sich weniger leisten muß.

[BlackBirdSR]

Original geschrieben von Leonidas
Stimmt absolut. Leider wird diese Methode bei heutigen PC-Prozessoren kaum noch angewandt, es wird lieber die Leistung auf mehr Stufen verteilt, so daß jede Stufe für sich weniger leisten muß.

wenn der K8 keine heutige CPU ist, was dann?

[Bokill]

Morgen!

@BlackBirdSR

der K8 ist eine CPU von Morgen *gg*

[Coda]

Das Problem sind nur die Sprünge, gäbe es diese nicht, dann wäre es die beste Lösung die Pipeline mit so vielen Stufen wie möglich zu bauen.

Es gibt aber Sprünge, deshalb hat der Instruction Decoder immer dann ein Problem, wenn ein conditional jump auftaucht, er aber noch nicht weiß ob der jump nun erfolgen muss oder nicht, weil das durch die Pipeline noch nicht feststeht (die Berechnung ist noch im Gange)

Hier kommt jetzt die jump prediction ins Spiel, diese versucht durch Mustererkennung und andere Algorithmen möglichst gut zu erahnen wohin wohl gesprungen werden muss. Man kann sich vorstellen das auch einige Sprünge danebengehen...

Wenn dies geschieht muss die komplette Pipeline verworfen werden, weil die ganz einfach am falschen Teil des Codes weitergearbeitet wurde.

Und 30 Stufen ist einfach nur krank! Ich unterstelle Intel jetzt einfach mal, dass das ganze nur reine Marketing Strategien sind um möglichst hohe verkaufsfördernde Mhz-Zahlen präsentieren zu können.
Sieht man auch am Itanium 2, der hat sogar weniger Stufen als sein Vorgänger, um die Effizienz zu erhöhen :/

Ich glaube Intel rennt damit irgendwann gegen eine Mauer, weil sie einfach nicht damit gerechnet haben, das die Leckströme so überhand nehmen, der Prescott ist ja schon schweineheiß, aber was kommt danach?
So extreme Taktsteigerungen werden wohl in Zukunft eher zu vermeiden sein, wenn man nicht irgendwann 1kW verbraten will O_o

der K8 ist eine CPU von Morgen *gg*
Eigentlich ist er eine überarbeitete K7 Architektur, das einzige was "von morgen" ist, ist der Memory Controller und die Punkt zu Punkt verbindungen im SMP Betrieb.
Einige kleine Detailverbesserungen sind natürlich auch eingeflossen, sowie nebenbei auch noch eine 64 bit Unterstützung ;)

[BlackBirdSR]

Original geschrieben von Coda

Und 30 Stufen ist einfach nur krank! Ich unterstelle Intel jetzt einfach mal, dass das ganze nur reine Marketing Strategien sind um möglichst hohe verkaufsfördernde Mhz-Zahlen präsentieren zu können.


der jetzige P7 hat doch schon ca 28 Stufen :-)
Marketing ist hier in dem Fall, die Anzahl der Stufen auf die kritischen zu beschränken, d.h vom Trace Cache aus, statt vom Decoder. -> 20 Stufen
Und dass man 2 Drive Stufen nur fürs Warten hat, erwähnt man auch nicht.

[Coda]

Ich ging auch davon aus das sich die 30 Stufen auf den gleichen Teil der Pipeline beziehen wie früher die 20 Stufen

Falls es wirklich nur 3 Stufen mehr sind, ist es nicht so tragisch

Die Trace Cache Pipeline ist von der Processing Pipeline ja wohl unabhängig oder liege ich da falsch?

Und dass man 2 Drive Stufen nur fürs Warten hat, erwähnt man auch nicht.
Doch, das es gab mal ne Auflistung von Intel und da waren die "Drive" Stages mit drin

[Stone2001]

Original geschrieben von Coda
Das Problem sind nur die Sprünge, gäbe es diese nicht, dann wäre es die beste Lösung die Pipeline mit so vielen Stufen wie möglich zu bauen.

Und was machst du mit den ganzen Abhängigkeiten?

[haifisch1896]

Original geschrieben von Stone2001
Und was machst du mit den ganzen Abhängigkeiten?

Entziehungskur?:kratz2: :spam:

[Coda]

Original geschrieben von Stone2001
Und was machst du mit den ganzen Abhängigkeiten?
Welche Abhängigkeiten? Ich sagte doch FALLS es keine Sprünge geben WÜRDE, dann WÄRE das die beste Lösung. Z.B. bei einer reinen Vektoreinheit...

[Haarmann]

Coda

Sprünge stören auch "breite" CPUs und was besser ist, lasse ich mal im Raume stehen. Allerdings hab ich bei den alten Crays das Gefühl, dass die sehr breit ausgelegt waren trotz der Länge.

[Stone2001]

Original geschrieben von Coda
Welche Abhängigkeiten? Ich sagte doch FALLS es keine Sprünge geben WÜRDE, dann WÄRE das die beste Lösung. Z.B. bei einer reinen Vektoreinheit...
Ahängigkeiten in der Form:
Befehl B braucht das Ergebnis von Befehl A. Da aber Befehl A direkt vor Befehl B steht, steht das Ergebnis nicht zur Verfügung, wenn Befehl B eigentlich berechnet werden sollte. Damit Befehle abgearbeitet werden kann, muß erst das Ergebnis von Befehl A zurückgeschrieben sein.

Um das Problem zu lösen, kann man jetzt z.B. die Pipeline mit NOPs auffüllen (kostet viel Leistung) oder man kann in die so entstehenden Zwischenräume andere Befehle schieben (großer Hardwareaufwand),... . Es gibt viele Möglichkeiten Pipelinekonfilkte zu lösen. Aber je länger eine Pipeline wird desto schwieriger wird es.

[Muh-sagt-die-Kuh]

Original geschrieben von Haarmann
Coda

Sprünge stören auch "breite" CPUs und was besser ist, lasse ich mal im Raume stehen. Allerdings hab ich bei den alten Crays das Gefühl, dass die sehr breit ausgelegt waren trotz der Länge. Es macht allerdings einen Unterschied ob die CPU bei jedem misslungenen Sprung 30 Takte oder nur 7 Takte warten muss, bis es wieder Ergebnisse gibt.

[Coda]

Ok, du hast recht, dann mein ich halt keine Sprünge und keine Abhängigkeiten ;)
Daran hab ich gar nicht gedacht als ich das geschrieben hab

Das mit dem Auffüllen ist genau das was gemacht wird mit der out-of-order execution

[Haarmann]

Muh-sagt-die-Kuh

Natürlich - ich wollte nur sagen, dass die Probleme der einen Seite auch die Probleme der anderen sind, nur nicht so extrem.

[aths]

Was ich bei der News nicht so ganz verstehe ist, wieso von der längeren Pipe automatisch auf eine niedrigere IPC geschlossen wird. Immerhin hat der Prescott lt. Aces HW eine Integer-Multiplikationseinheit (und muss dafür nicht mehr die FPU nutzen) und mehr Cache. Der Prescott kann pro Takt mehr tun, als der Northwood. Natürlich besteht die Gefahr, dass er durch wilde Programmsprünge ausgebremst wird.

[mapel110]

Original geschrieben von aths
Was ich bei der News nicht so ganz verstehe ist, wieso von der längeren Pipe automatisch auf eine niedrigere IPC geschlossen wird. Immerhin hat der Prescott lt. Aces HW eine Integer-Multiplikationseinheit (und muss dafür nicht mehr die FPU nutzen) und mehr Cache.

Die Verlängerung der Pipeline bedeutet prinzipiell eine schlechte Pro-MHz-Leistung, da es somit deutlich komplizierter wird, die Pipeline immer gefüllt zu haben und solche Fälle zu vermeiden, in welchen die komplette Pipeline geleert werden muß.

Die niedrigere Pro-MHz-Leistung des Prescott durch die Streckung seiner Pipeline kaschiert Intel wahrscheinlich vollständig durch den größeren Level1 Daten Cache (16 anstatt 8 kB) und den größeren Level2 Cache (1024 anstatt 512 kB).

ist doch alles gesagt. was verstehst du daran nicht?!

[aths]

Original geschrieben von mapel110
Die Verlängerung der Pipeline bedeutet prinzipiell eine schlechte Pro-MHz-Leistung, da es somit deutlich komplizierter wird, die Pipeline immer gefüllt zu haben und solche Fälle zu vermeiden, in welchen die komplette Pipeline geleert werden muß.Eine Pipeline kann immer gefüllt bleiben, solange es keinen Sprung gibt, der falsch vorhergesagt wurde. Da es jetzt eine MUL-Einheit für Integer gibt, werden bei entsprechenden Befehlen die Latenzen verringert, die Leistung pro MHz steigt.
Original geschrieben von mapel110
Die niedrigere Pro-MHz-Leistung des Prescott durch die Streckung seiner Pipeline Der Prescott hat zunächst eine höhere Leistung pro MHz. Je nach Anwendung wirkt sich die längere Pipe auch negativ aus.

[mapel110]

Original geschrieben von aths
Eine Pipeline kann immer gefüllt bleiben, solange es keinen Sprung gibt, der falsch vorhergesagt wurde. Da es jetzt eine MUL-Einheit für Integer gibt, werden bei entsprechenden Befehlen die Latenzen verringert, die Leistung pro MHz steigt.

Der Prescott hat zunächst eine höhere Leistung pro MHz. Je nach Anwendung wirkt sich die längere Pipe auch negativ aus.

jo, und weiter?

bei streaming-anwendungen wird er durch die längere pipe kaum etwas verlieren(encoding) . aber sobald ne anwendung recht viele sprunganweisungen hat(games), siehts wohl wieder düster aus.
alles wie gehabt, wie beim bissherigen p4. aber insgesamt würd ich doch von einer etwas schlechtere PML ausgehen.
50% länger pipe?! das sollte "reinhauen" (im negativen sinne).

[aths]

Original geschrieben von mapel110
jo, und weiter?

bei streaming-anwendungen wird er durch die längere pipe kaum etwas verlieren(encoding) .Er dürfte sogar gewinnen (Cache, eine zusätzliche Recheneinheit.)
Original geschrieben von mapel110
aber sobald ne anwendung recht viele sprunganweisungen hat(games), siehts wohl wieder düster aus.Wieso düster? Die meisten Sprünge lassen sich vorhersagen.
Original geschrieben von mapel110
alles wie gehabt, wie beim bissherigen p4. aber insgesamt würd ich doch von einer etwas schlechtere PML ausgehen.
50% länger pipe?! das sollte "reinhauen" (im negativen sinne). Nur wenn es Sprünge gibt, und die Vorhersage daneben geht. Auch kurze Pipes sind nicht immer auszulasten, z. B. wenn der Cache nachgeladen werden muss. Oder wenn die FPU ihre Takte dreht. Derartige Latenzen lassen sich prinzipiell in einer langen Pipe etwas besser verstecken. Eine längere Pipe heißt nicht zwingend, weniger Leistung pro MHz, schon gar nicht, wenn es mehr Execution Units gibt.

[mapel110]

wie erklärst du es denn dann, dass der p4 willamette so sehr gegenüber dem p3 abgefallen ist, was PML angeht?

[Hamster]

Original geschrieben von mapel110
wie erklärst du es denn dann, dass der p4 willamette so sehr gegenüber dem p3 abgefallen ist, was PML angeht?

die kleinen caches und unoptimierter code (da neue architektur).

[BlackBirdSR]

Original geschrieben von mapel110
Die Verlängerung der Pipeline bedeutet prinzipiell eine schlechte Pro-MHz-Leistung,

falsch, siehe K7-K8.
neue Stufen müssen nicht immer dazu da sein, bereits vorhandene Aufgaben über mehrere Takte zu strecken.
Beim K8 erledigen die beiden neuen Stufen "neue" Arbeit, und verbessern damit die Ausführung.

[BlackBirdSR]

Original geschrieben von aths
Was ich bei der News nicht so ganz verstehe ist, wieso von der längeren Pipe automatisch auf eine niedrigere IPC geschlossen wird.

Vorurteile?

was mich viel mehr interessiert: Wie kann man durch längere Pipelines Hotspots verhindern? Es ist ja nicht so, dass sich da ein Rohr durch die CPU schiebt, das mal länger mal kürzer ist.
Die Funktionseinheiten bleiben immernoch an Ort und Stelle, und produzieren fleißig Hitze (solange die CPU nicht extrem unterausgelastet ist)

[aths]

Original geschrieben von mapel110
wie erklärst du es denn dann, dass der p4 willamette so sehr gegenüber dem p3 abgefallen ist, was PML angeht? Durch eine bewusste Design-Entscheidung, u. a. an FP-Execution Units zu sparen, um mehr Taktreserven zu haben.

Original geschrieben von BlackBirdSR
was mich viel mehr interessiert: Wie kann man durch längere Pipelines Hotspots verhindern? Es ist ja nicht so, dass sich da ein Rohr durch die CPU schiebt, das mal länger mal kürzer ist.
Die Funktionseinheiten bleiben immernoch an Ort und Stelle, und produzieren fleißig Hitze (solange die CPU nicht extrem unterausgelastet ist) Was ich mir vorstellen könnte (ob das so gemacht wird, weiß ich nicht) wäre, eine Execution Unit räumlich zu zerlegen, und die Daten in einer extra Pipeline-Stage von Punkt A zu Punkt B transportieren.

[BlackBirdSR]

Original geschrieben von aths
Durch eine bewusste Design-Entscheidung, u. a. an FP-Execution Units zu sparen, um mehr Taktreserven zu haben.

Was ich mir vorstellen könnte (ob das so gemacht wird, weiß ich nicht) wäre, eine Execution Unit räumlich zu zerlegen, und die Daten in einer extra Pipeline-Stage von Punkt A zu Punkt B transportieren.

nicht bei den Laufzeiten, die Intel für Prescott angibt.
Bei den Fast-ALUs schon gar nicht.

Die DIE Photos zeigen sowas ja auch nicht.
Nur für SIMD gibt es anscheinend einen extra Bereich. Mal sehen wieviel Pipelinestufen es dafür gibt (wenn überhaupt)

Aber ich will jetzt mal nicht davon ausgehen, dass der P7-2 10 neue Drive Stufen besitzt *g*

[andr_gin]

Das Prinzip des Pipelinings ist es, einen Befehl schon zu bearbeiten, während der andere noch nicht fertig ist. Das Problem ergibt sich bei Sprüngen im Code (z.B. wenn ich eine if-Bedingung habe und es zwei Codeteile gibt) und bei Abhängigkeiten (z.B. wenn der 2. Befehl das Ergebnis des ersten benötigt, während dieser noch nicht fertig ist), da dann die Pipeline geleert werden muss und die CPU ganz von vorne beginnen muss, falls ein Codeteil schon verarbeitet wird, bei dem sich aber dann herausstellt, dass es der falsche Teil war. Sprünge werden dadurch umgangen, dass es eine Sprungvorhersage gibt. Diese versucht herauszufinden, wo das Programm am wahrscheinlichsten weitergeht, was z.B. bei oft wiederholten Schleifen von Vorteil ist. Falls die Sprungvorhersage versagt, muss die Pipeline geleert werden, was je schlimmer ist, je mehr Stufen sie hat. Beim P4 mit 20 Stufen, was das ganze schon schwieriger gestaltet, als beim Athlon XP mit nur 10 Stufen. Hier ist es zum Einen leichter die Pipeline gefüllt zu halten, da die Vorhersage bei 10 Stufen noch eher leicht ist. Zum Anderen ist ein Versagen nicht so schlimm, da ja "nur" 10 Stufen nachgefüllt werden müssen und nicht 20. Das ist auch mit ein Grund, warum der P4 zwar eine höhere Taktfrequenz erreicht, aber nur eine geringere Pro-Mhz-Leistung. Bei Multimediaanwendungen, wo Schleifen sehr oft wiederholt werden ist es leichter eine Sprungvorhersage zu treffen, was dem P4 sehr entgegen kommt, wobei der Athlon XP eher schlecht abschneidet, da er eine geringere Taktfrequenz hat. Bei Spielen, die sehr vielfältig in der Progrmmierung sind, hat der P4 hingegen ein Problem mit der Sprungvorhersage und der Athlon XP hat dadurch einen Vorteil.

So wie ich das sehe, beginnen AMD und Intel jetzt sich den Markt aufzuteilen und jeder stützt sich vorwiegend auf seinen Lieblingsbereich. Beim A64 mit seinem Memorycontroller hat AMD schon angefangen. Dadurch ist der A64 bei Spielen sehr deutlich schneller, als ein P4, wohingegen er bei Multimediaanwendungen wegen seiner geringen Taktfrequenz deutlich langsamer ist, was auch die Benchmarks verdeutlichen. Anscheinend macht Intel nun auch mit und optimiert jetzt durch die lange Pipeline auf Multimediaanwendungen. In Zukunft wird man sich ganz genau überlegen, für was man seinen PC einsetzt. Früher war die Entscheidung immer der Preis, die Sympatie oder sonst etwas, aber ich denke, dass ab jetzt auch noch so überzeugte Intelfans sich eine AMD-CPU in ihre Spielecomputer einbauen müssen, wohingegen ein AMD-Fan sich für einen Multimedia PC einen P4 oder P5 holen wird. Darum stelle ich bei Ratschlägen auch immer die Frage, was derjenige mit dem PC machen will.

[Bokill]

Ich möchte nochmals auf den Beitrag von BlackBirdSR hinweisen.

Schon auf der ersten Seite des Threads nannte er den Grund weswegen 30 Stufen nicht extrem sind.

Marketing!

Eine andere Zählweise ordnet dem P4 schon 27 Stufen zu (Däumchendreheinheiten)

Zitat BlackBirdSR


quote:
--------------------------------------------------------------------------------
Original geschrieben von Coda

Und 30 Stufen ist einfach nur krank! Ich unterstelle Intel jetzt einfach mal, dass das ganze nur reine Marketing Strategien sind um möglichst hohe verkaufsfördernde Mhz-Zahlen präsentieren zu können.

--------------------------------------------------------------------------------

der jetzige P7 hat doch schon ca 28 Stufen :-)
Marketing ist hier in dem Fall, die Anzahl der Stufen auf die kritischen zu beschränken, d.h vom Trace Cache aus, statt vom Decoder. -> 20 Stufen
Und dass man 2 Drive Stufen nur fürs Warten hat, erwähnt man auch nicht.

Ich täte mich auch schwer mit dem Marketing von der Däumchedrehunit ;)

Warum liest keiner die Threads durch???

30 Stufen ist Marketinggeblubber!

JOE SIXPACK und DADDY WEISSKRAGEN haben sich nun schon an aberwitzige Pipelinelängen gewöhnt.

Welche Vorteile kurze Pipelines haben wird vollkommen vergessen!

Bei ständig variierenden Sequenzen muss dies der wahre Horror sein.

Wäre mal spannend zu sehen wie die WunderCPUs sich vor Verzweiflung , bei riesigen Datenbanken und riesigen Tabelllen, von der Brücke stürzen.
Harakieri begehen (Hitzetod bei Amoklaufenden Code, da beständig die Pipeline geleert und wieder gefüllt wird, damit sie wieder geleert wird)...
oder }illegale Umwege gehen, es wird einfach nichts mehr gebencht was ständiges Leeren der Pipeline bewirkt.

[GloomY]

Der Vollständigkeit halber möchte ich hier erwähnen, dass es sich um bedingte Sprünge handelt. Unbedingte Sprünge können logischerweise perfekt vorrausgesagt werden. Bedingte Sprünge sind - wie der Name ausdrückt - von einer Bedingung abhängig, meist vom Inhalt eines Registers, welches durch eine artithmetische Operation erst noch festgelegt wird.
Original geschrieben von aths
Wieso düster? Die meisten Sprünge lassen sich vorhersagen.Das stimmt nur, wenn der Code schon mindestens einmal durchlaufen wurde (z.B. in Schleifen). Denn sonst hat der Prozessor keinerlei Information darüber, wie er hier zu verfahren hat. (*)

Branch Prediction hat also immer etwas mit dem "Erinnern" an schonmal an dieser Adresse getätigten oder nicht getätigten Sprüngen zu tun. Einige Formen der Branch Prediction brauchen auch erst mehrere durchlaufene bedingte Sprünge (nennt man auch "Warm-up Time"), um dann korrekte Vorraussagen für die Zukunft treffen zu können. Daher probiert man oftmals, Methoden mit niedriger Warm-up Time aber langfristig schlechteren Vorhersageraten mit anderen Methoden zu kombinieren, die eine längere Warm-up Time aber bessere Vorhersageraten haben.
Die Perfekte Methode gibt es nicht, aber die Entwicklung ist hier eigentlich erst am Anfang. Imho ein sehr interessantes Thema =)

(*) Es gibt dazu die Überlegung, dass Sprünge "nach hinten" (also zu niedrigeren Adressen als der aktuellen) genommen werden sollten. Das beruht darauf, dass Schleifen in Konstrukte der ArtLabel1:

Code innerhalb der Schleife

Sprungbedingung auswerten
Bedingung nicht erfüllt: Springe zu Label1überführt werden. Man sieht leicht, dass dort der Großteil der bedingten Sprünge genommen wird, nur der letzte nicht (wenn die Schleife beendet wird). Das führt schon bei recht kleiner Anzahl an Schleifendurchläufen zu einer guten Trefferquote.
Original geschrieben von aths
Nur wenn es Sprünge gibt, und die Vorhersage daneben geht. Auch kurze Pipes sind nicht immer auszulasten, z. B. wenn der Cache nachgeladen werden muss. Oder wenn die FPU ihre Takte dreht. Derartige Latenzen lassen sich prinzipiell in einer langen Pipe etwas besser verstecken.Kurze Pipes sind meist niedriger getaktet. Daraus folgt, dass diese konstanten Verzögerungszeiten bei kürzeren Pipelines auch auf weniger Takte kommen, da ein einzelner Takt länger dauert.
Original geschrieben von aths
Eine längere Pipe heißt nicht zwingend, weniger Leistung pro MHzTendentiell schon, jedoch wie du bereits erwähnt hast nicht zwingend. Wenn man in den zusätzlichen Stufen mehr "Arbeit" verrichtet und damit die Ausführung effizienter macht (wie beim Hammer geschehen), dann kann das durchaus für mehr Leistung führen.

[GloomY]

Original geschrieben von andr_gin
Das Prinzip des Pipelinings ist es, einen Befehl schon zu bearbeiten, während der andere noch nicht fertig ist. Das Problem ergibt sich [...] und bei Abhängigkeiten (z.B. wenn der 2. Befehl das Ergebnis des ersten benötigt, während dieser noch nicht fertig ist)Das ist kein Problem bei heutigen CPUs. Result Forwarding heisst da das Stichwort. Das Ergebnis der gerade ausgeführten Berechnung kann sofort wieder an die Eingänge der Ausführungseinheit angelegt werden, um im nächsten Takt für einen anderen Befehl als Operand benutzt zu werden. Das Zurückschreiben des Ergebnisses der ersten Operation in das entsprechende Register kann parallel zur Ausführung des zweiten geschehen.

[mapel110]

Original geschrieben von GloomY
Kurze Pipes sind meist niedriger getaktet. Daraus folgt, dass diese konstanten Verzögerungszeiten bei kürzeren Pipelines auch auf weniger Takte kommen, da ein einzelner Takt länger dauert.


bitte um nähere ausführung :)
ein zahlenbeispiel wäre nicht schlecht. irgendwie widerspricht sich das nämlich oder ich steh grad auf der leitung.

[GloomY]

Original geschrieben von mapel110
bitte um nähere ausführung :)
ein zahlenbeispiel wäre nicht schlecht. irgendwie widerspricht sich das nämlich oder ich steh grad auf der leitung. Es ist einfach die Frage, wie lange ein Takt dauert.

Eine kürzere Pipeline hat - meist - eine niedrigere Taktung, weil die Ausführung der einzelnen Stufen länger dauert (die Schaltungen pro Stufen sind komplexer - ergo ist die Laufzeit der Schaltung länger). Eine längere Pipeline kann eine (konstant) zu verrichtende Arbeit auf mehr Stufen aufteilen, hat also somit weniger pro Stufe zu tun, was die Laufzeiten verringert.

Zahlenbeispiele:

CPU1: 2 GHz, CPU2: 3 GHz
Taktdauer CPU1: 1/ 2 GHz = 500 ps
Taktdauer CPU2: 1/ 3 GHz = 333 ps

Wenn er Zugriff auf den Cache oder den Haupstpeicher oder was auch immer nun eine bestimmte (konstante) Zeit dauert, dann braucht dies auf den einzelnen CPUs eine unterschiedlich große Anzahl an Taktzyklen. Eine Wartezeit von 1 ns dauert 2 Takte auf CPU1, während es schon 3 Takte bei CPU2 sind usw.

[HellHorse]

Original geschrieben von mapel110
...
bei streaming-anwendungen wird er durch die längere pipe kaum etwas verlieren(encoding) . aber sobald ne anwendung recht viele sprunganweisungen hat(games), siehts wohl wieder düster aus.
...

Schliesst du aus den K8 <-> P4 Benchmarks, dass Games mehr bedingte Sprünge haben als Encoding?

[BlackBirdSR]

Original geschrieben von HellHorse
Schliesst du aus den K8 <-> P4 Benchmarks, dass Games mehr bedingte Sprünge haben als Encoding?

Encoding und Audio/Video im Generellen, sind sehr stark auf Fließkommeberechnungen (oder SIMD) /Speicherbandbreite fixiert.
Diese sind aber viel weniger anfällig für bedingte Sprünge als Integer Code.
Im Optimalfall durchläuft man immer die Gleichen Befehlsschleifen mit versch. Daten. Optimal für den P7 mit dem Trace Cache.


Spiele haben viel mehr Integer/FP Mix als z.B Encoding würde ich annehmen. Dazu kommen Sachen wie KI Berechnungen und Sound. Das macht dem P4 mehr zu schaffen, ist ja klar.

[andr_gin]

Original geschrieben von HellHorse
Schliesst du aus den K8 <-> P4 Benchmarks, dass Games mehr bedingte Sprünge haben als Encoding?

1.) Bei Encoding ist es ein z.T. einfacher Algorithmus, der angewendet wird, nur das ziemlich oft. Meistens sind es eher kürzere Schleifen, die sehr oft wiederholt werden, was die Sprungvorhersage einfacher macht. Spiele hingegen haben einen sehr vielfältigen Code, da sehr viele verschiedene Dinge berechnet werden und das ganze ist nicht so regelmäßig (man stelle sich z.B. ein KI-Skript vor). Das macht die Sprungvorhersage sehr schwierig, weshalb die Pipeline sehr oft geleert werden muss. und so CPUs mit einer möglichst kurzen Pipeline im Vorteil sind.

2.) In der heutigen Zeit und vor allem in Zukunft wird die Temperaturentwicklung das Hauptproblem sein und im Prinzip spielt die Auslastung hier keine Rolle. Es geht beim Design dann nur darum, mit möglichst wenigen Transistorschaltungen möglichst viele Berechnungen durchzuführen. Wäre es hier nicht auch von Vorteil die Pipelines noch zusätzlich zu verkürzen. Im Extremefall nehme ich einmal eine CPU mit nur einer Stufe. Diese erspart sich sowohl komplett die sowohl die Arbeit durch die Sprungvorhersage, was sicher auch Wärme produziert, als auch die unnötige Wärmeentwicklung durch das Berechnen von Zwischenergebnissen, die dann erst recht wieder verworfen werden müssen. Hier würde zwar die Auslastung katastrophal niedrig sein, aber gerade dadurch lässt sich der Takt wieder erhöhen. Eine gute Auslastung wäre ja rein temperaturmäßig gesehen irrelevant, da ja wie oben gesagt nur die Anzahl der Transistorschaltungen/Ergebnisse zählt oder anders ausgedrückt Wärmeabgabe/Performance. Noch einmal kurzgefasst: Weniger Pipelinestufen => geringere Auslastung => höherer Takt. Es bleibt sich egal nur muss man die Pipeline nie leeren (verlorene Ergebnisse) und die Sprungvorhersage kann z.T. entfallen (Transistoreinsparungen d.h. weniger Wärme).

3.) Andere Idee: Die CPUs wieder auf möglichst wenig Transistoren beschränken. Früher gab es CPUs mit 1 Mio. Transistoren, die auch nicht so schlechte Ergebnisse lieferten. Durch die heutige Herstellungstechnik kann man die Performance noch erheblich steigern. Durch die geringe Größe könnte man so ca. 100 DIEs auf einmal verkaufen, was ja an sich eine viel höhere Leistung haben müsste, sofern mann jede Software in ganz viele Threads teilt, was in fast allen Fällen durchaus möglich wäre. Bei Spielen könnte man z.B. für jeden Bot einen eigenen Thread starten (KI) oder die Bewegung und das Schießen trennen. Man könnte auch z.B. einen Thread alle geraden Frames berechnen lassen und einen anderen alle ungeraden (müsste irgendwie machbar sein oder?) Da gibt es viele Ansätze, wie man den Code gut aufsplitten kann. Ich behaupte einmal, dass es in den wenigsten Fällen unmöglich ist, den Code aufzuteilen, sofern man es versucht. Einige Teile könnten schon selbständig vom Compiler erledigt werden. z.B. wenn man eine Schleife hat, wo die einzelnen Durchgänge nicht voneinander abhängig sind. Man könnte das Ganze auch einfacher in die Programmiersprache einbinden. Wenn ich eine Funktion aufrufe, wo ich die die Ergebnisse noch nicht gleich brauche könnte ich es z.B. mit einem speziellen Zeichen markieren. Ich glaube das Paragrafenzeichen (§) ist noch frei.

[BlackBirdSR]

Original geschrieben von andr_gin
Im Extremefall nehme ich einmal eine CPU mit nur einer Stufe.

wie willst du die CPU höher Takten, wenn der gesamte Ablauf innerhalb eines Taktes geschehen muss.

Kommt man bei 1 Stufe überhaupt über die Geschw. des Speichersystems hinaus, ohne die ganze CPU zu stallen?

[andr_gin]

Indem, dass jeder Teil innerhalb eines Taktes (wird ca. 200Mhz sein) nur eine kurze Zeit arbeitet. Während der Befehl interpretiert wird, tut ist der Teil, der mit der Ausführung beschäftigt ist zum Nichtstun gezwungen und umgekehrt. Dadurch sinkt die Auslastung im Vergleich zu einer 20-stufigen Pipeline auf 1/20 und somit auch die Wärmeabgabe auf 1/20 (wenn man die Leckströme mal außer Acht lässt). Dadurch könnte man theoretisch, falls die Temperatur das einzige Problem wäre die CPU wieder auf das 20-fache hinauftaktet. Dass es noch andere Probleme gibt, ist mir bewusst. Das war nur ein Extrembeispiel und wird in der Realität nie passieren. Jedoch in geringem Maßstab denke ich, dass diese Theorie durchaus ihre Berechtigung hat. Wenn man statt 12 Stufen beim A64 nur 10 einbauen würde, brächte das schon den gewünschten Effekt. Rechne es so einmal durch: Statt 2,4Ghz und 12 Stufen nimmst du nur 2Ghz mit 10Stufen. Dadurch ist er kühler und lässt sich wieder bis auf 2,4Ghz übertakten (oder standardmäßig so betreiben), weil die sonstigen Probleme, wie Laufzeit von Signalen etc. noch nicht zum Tragen kommt. Dadurch muss die Pipeline weniger oft geleert werden und die Sprungvorhersage muss auch nicht so genau sein.

[Haarmann]

BlackBirdSR

Intel behauptete mal, dass ihr P4 Design auf 10 GHz gehen kann... Da müssten zZ noch "leichte" Reserven vorhanden sein ;).

[Muh-sagt-die-Kuh]

Original geschrieben von andr_gin
Indem, dass jeder Teil innerhalb eines Taktes (wird ca. 200Mhz sein) nur eine kurze Zeit arbeitet. Während der Befehl interpretiert wird, tut ist der Teil, der mit der Ausführung beschäftigt ist zum Nichtstun gezwungen und umgekehrt. Dadurch sinkt die Auslastung im Vergleich zu einer 20-stufigen Pipeline auf 1/20 und somit auch die Wärmeabgabe auf 1/20 (wenn man die Leckströme mal außer Acht lässt). Dadurch könnte man theoretisch, falls die Temperatur das einzige Problem wäre die CPU wieder auf das 20-fache hinauftaktet. Dass es noch andere Probleme gibt, ist mir bewusst. Das war nur ein Extrembeispiel und wird in der Realität nie passieren. Jedoch in geringem Maßstab denke ich, dass diese Theorie durchaus ihre Berechtigung hat. Wenn man statt 12 Stufen beim A64 nur 10 einbauen würde, brächte das schon den gewünschten Effekt. Rechne es so einmal durch: Statt 2,4Ghz und 12 Stufen nimmst du nur 2Ghz mit 10Stufen. Dadurch ist er kühler und lässt sich wieder bis auf 2,4Ghz übertakten (oder standardmäßig so betreiben), weil die sonstigen Probleme, wie Laufzeit von Signalen etc. noch nicht zum Tragen kommt. Dadurch muss die Pipeline weniger oft geleert werden und die Sprungvorhersage muss auch nicht so genau sein. Was du hier ausführst scheitert an der einfachen Tatsache, dass eine CPU nur dann funktionieren kann wenn folgendes gilt:

Taktzyklus in ns >= max(i in Pipelinestufen) {Schaltzeit der langsamsten Schaltung in Pipelinestufe i} in ns

[andr_gin]

Original geschrieben von Haarmann
BlackBirdSR

Intel behauptete mal, dass ihr P4 Design auf 10 GHz gehen kann... Da müssten zZ noch "leichte" Reserven vorhanden sein ;).

Meiner Meinung nach nur Marketing, um jetzt auf einmal nicht so schlecht dazustehen. Selbst wenn man jetzt eine Pipeline mit 100 Stufen baut, dann lässt sich die Taktfrequenz nicht weiter steigern, da dann durch ein und denselben Teil der CPU viel mehr Daten durchmüssen, was einen unglaublichen Temperaturanstieg bedeutet. Die Ausführungseinheiten müssen ja dann viel mehr Ergebnisse pro Sekunde verarbeiten. Wenn die Pipeline dann oft unnötig gefüllt und geleert werden muss, dann schlägt es sich nur in der Performance nieder und nicht in einer geringeren Teperaturentwicklung.

@ Muh: Das stimmt schon, was du sagst, aber einen A64 kannst du um bei dem Beispiel zu bleiben auch mit extremer Kühlung auf über 3Ghz übertakten, ohne, dass es ein Problem mit der Schaltzeit der Transistoren gibt und ich bin mir sicher, dass es da auch noch nicht aus ist. Wenn die Temperaturprobleme nicht wären, dann könnte man heutige CPUs weitaus höher takten. Da ist noch einiges an Spielraum. Ich kann also ohne weiteres die Auslastung senken und höher takten. Das würde in so geringen Maßstäben wie 20% gar keinen Unterschied machen. Der einzige Vorteil wäre, dass nicht so viele Ergebnisse wieder verworfen werden müssen. Das erste Beispiel mit einer Stufe ist natürlich nicht möglich, sondern war nur da um darzustellen, was ich meine.

[mrdigital]

Die CPU Ingenieure haben sich schon was überlegt, als sie auf die Idee kamen, eine Piplearchitektur zu bauen. Deine Argumentation, dass es bei weniger Pipestufen nicht so warm wird, kann ich nicht nachvollziehen, denn das Hauptproblem mit dem die CPU´s kämpfen hat (in Hinblick auf die max erreichbare Taktfrequenz) sind Schaltzeiten und Signallaufzeiten, und diese kann man eben nur reduzieren, wenn man die Komplexität in den einzelnen (Pipe)Stufen niedrig hält, was einem dann wiederum viele Stufen beschert. Diese vielen Stufen haben aber auch für das thermische Verhalten positive Auswirkungen, denn man Verteilt das ganze in der Fläche, wodurch man Hotspots vermeiden kann (diese Hotspots sind letzlich das Temperaturproblem der CPU, nicht die Gesammtleistung). Wenn man nun zu wenigen, aber sehr Komplexen Stufen zurückkehrt hat man das Problem, dass die Schaltzeit dieser Stufen wieder grösser wird (die Schaltzeit ist eine Grösse, die in erster Linie von der Anzahl der Gatter abhängt und nicht von der Temperatur) und damit (wie Muh schon gezeigt hat) deine max Taktfrequenz limitiert.

[andr_gin]

1.) Du hast mich falsch verstanden. Pipelining ist sehr sinnvoll und beschleunigt heutige Prozessoren um ein vielfaches. Ich denke nur, dass wir heutzutage schon zuviele Stufen haben.

2.) Klar ist das Problem mit den Signallaufzeiten ein wichtiges, aber es limitiert eben z.B. beim A64 nicht die Taktfrequenz, denn dieser hat ja nur 2Ghz bzw. 2,2Ghz und er wurde schon auf über 3Ghz getaktet und ist noch gelaufen, woraus ich schließen kann, dass bis 3Ghz kein Problem mit der Signallaufzeit aufgetreten ist. Das heißt man könnte ohne weiteres den Takt um 40% steigern, ohne dass ein Problem auftritt. Wenn ich also jeder Piplinestufe 20% mehr Arbeit gebe (sprich aus 12 mach 10), dann würde immer noch kein Problem auftreten. Der einzige Effekt wäre, dass die Pipeline nicht so oft geleert werden müsste und bei einer Entleerung nur 10 statt 12 Stufen verworfen werden müssten.

3.) Da mich viele missverstanden haben, bringe ich einmal ein Gegenbeispiel: Angenommen Intel baut bei ihrem P4 3Ghz statt 20 Stufen 25 ein, dann würde zwar die Auslastung der einzelnen Stufen sinken, aber wegen der Überhitzung könnte man ihn trotzdem nicht höher takten, denn für einmal schalten verbraucht ein Transistor eine gewisse Menge an Strom bzw. produziert eine gewisse Menge an Wärme. Das ist völlig unabhängig, wieviele Stufen ich habe oder ob die CPU gut oder schlecht ausgelastet ist. Die Wärmeentwicklung eines P4 3Ghz mit 20Stufen wäre gleich der Wärmeentwicklung eines P4 3Ghz mit 25Stufen. Es spielt keine Rolle, ob eine Stufe jetzt einen Befehl in z.B. 20ns ausführt und ständig ausgelastet ist, oder ob sie ihn in 10ns ausführt und die anderen 10 unbeschäftigt ist. Das heißt wenn ich eine CPU um 10% besser auslaste und dafür um 10% runtertakte, bleibt die Wärmeentwicklung gleich. Es bleibt sich in dem konkreten Beispiel des P4 3Ghz egal, ob ich ihn mit 20 oder 25 Stufen betreibe. Der einzige Nachteil ist, dass dann die Pipeline entleert werden muss und das kostet Performance.
Ist jetzt klar, was ich vorher sagen wollte? Wenn Intel von 20 auf 30 Stufen geht, heißt das nicht, dass sie den Takt auch mitsteigern können.