[Techn. Inf.] Verständnisfrage zum Pipelining

seux

Hallo,
wir haben kürzlich Pipelining in technischer Informatik durchgesprochen, aber so ganz verstanden hab ich das nicht.

http://de.wikipedia.org/w/index.php?title=Datei:Befehlspipeline.PNG&filetimestamp=20110728211033

Ein Maschinenbefehl wird doch in einem Takt ausgeführt. Und es kann immer nur ein Befehl ausgeführt werden. Wie kann es dann zu einem Geschwindigkeitsvorteil kommen. Immerhin bleibt die Anzahl der auszuführenden Befehle gleich.

In dem Wikipedia Artikel steht, das die Abarbeitung des Maschinenbefehls in Teilaufgaben zerlegt wird. Aber ein Maschinenbefehl lässt sich doch gar nicht weiter unterteilen. Er stellt doch schon die kleinste Einheit dar.

gruß seux

Mechanics

Doch, ein Maschinenbefehl wird in zig Micro-Befehle zerlegt, die viel technischer sind, als die Maschinenbefehle und dann werden die in der Pipeline ausgeführt. Wenn du z.B. einen Maschinenbefehl wie add eax, dword ptr[xyz] hast, dann werden da paar Micro Operations rauskommen, die erstmal rausfinden müssen, welchem Shadow Register eax grad entspricht, man muss eine freie ALU finden, den Wert dahin laden, die Adresse von dem zweiten Parameter ausrechnen, die Operation durchführen, die Werte zurückschreiben... Das sind alle Implementierungsdetails und sind von außen weder sichtbar noch interessant. Aber intern kann man das durchaus beschleunigen.

SG1

Steht doch auch in http://de.wikipedia.org/wiki/Pipeline_(Prozessor) was A, B, C, D z.B. sein können.

seux

Danke für die Antworten

SG1 schrieb:

Steht doch auch in http://de.wikipedia.org/wiki/Pipeline_(Prozessor) was A, B, C, D z.B. sein können.

Hast ja recht, irgendwie weiß ich auch nicht. War wohl etwas vorschnell...

nachtfeuer

Man kann sich das auch wie an einer Supermarktkasse vorstellen. Wenn nur eine Kasse aufhat, dröppeln die Käufer Dröpche voor Dröpche aus dem Laden. Wenn dann zwei zusätzliche Kassen aufmachen, geht es flotter, dann kommt einer nach dem anderen aus dem Laden.

Und wenn man zu zweit an der Kasse ist, gehts ja auch viel schneller, wenn einer bezahlt und der andere schon einpackt.

Einen Befehl aufzuteilen, ist nicht so das große Problem, Befehle bestehen ja nun aus mehreren Teilen wie Registername, Speicheraddi, Daten oder Präfixen. Größere Probleme machen Pipline Hemmungen, z.B. bei Registerabhängigkeiten, sowas wie wenn der zweite an der Kasse nochmal in den Laden rennen muß, weil was vergessen wurde.

Sind diese "Micro Operationen" irgendwo Dokumentiert bzw. kann man die Bildlich als Befehl darstelle?

Also z.b.: ASM Befehl: NOP , Opcode: 0x90, Micro Operation/Opcode:

hustbaer

OpcodeNoob schrieb:

Sind diese "Micro Operationen" irgendwo Dokumentiert bzw. kann man die Bildlich als Befehl darstelle?

Also z.b.: ASM Befehl: NOP , Opcode: 0x90, Micro Operation/Opcode:

µOps sind im Prinzip ganz normale Befehle.
Dividieren kannst du z.B. zerlegen in ne (lange) Reihe einzelner (einfacher) Befehle. Und genau das machen viele CPUs auch.

Doku wird man wenn überhaupt dann nur vom CPU Hersteller bekommen, würde mich aber nicht wundern wenn die das gar nicht oder nur per NDA rausrücken.

nachtfeuer schrieb:

Man kann sich das auch wie an einer Supermarktkasse vorstellen. Wenn nur eine Kasse aufhat, dröppeln die Käufer Dröpche voor Dröpche aus dem Laden. Wenn dann zwei zusätzliche Kassen aufmachen, geht es flotter, dann kommt einer nach dem anderen aus dem Laden.

Und wenn man zu zweit an der Kasse ist, gehts ja auch viel schneller, wenn einer bezahlt und der andere schon einpackt.

Einen Befehl aufzuteilen, ist nicht so das große Problem, Befehle bestehen ja nun aus mehreren Teilen wie Registername, Speicheraddi, Daten oder Präfixen. Größere Probleme machen Pipline Hemmungen, z.B. bei Registerabhängigkeiten, sowas wie wenn der zweite an der Kasse nochmal in den Laden rennen muß, weil was vergessen wurde.

Das beschreibt eher einen Multicore-Prozessor. Pipelining würde eher das Band an der Kasse beschreiben. Hätte ich kein Band, könnte der Kunde erst anfangen, seine Waren zu reichen, wenn der vorige Kunde bereits bezahlt hat. Mit dem Band kann der nächste Käufer seine Waren bereits auf das Band legen, solange der vorige noch am bezahlen ist.

Und jetzt kommt die Latenz der Pipeline ins Spiel. Wenn der Kassierer plötzlich seine Kasse wechselt und das Band ist sehr lang, müssen viele Kunden ihre Waren wieder einsammeln und auf ein anderes Band legen. Ist das Band sehr kurz, können solche Kassenwechsel schneller statt finden.

nachtfeuer

ich bins schrieb:

Das beschreibt eher einen Multicore-Prozessor. Pipelining würde eher das Band an der Kasse beschreiben. Hätte ich kein Band, könnte der Kunde erst anfangen, seine Waren zu reichen, wenn der vorige Kunde bereits bezahlt hat. Mit dem Band kann der nächste Käufer seine Waren bereits auf das Band legen, solange der vorige noch am bezahlen ist.

Und jetzt kommt die Latenz der Pipeline ins Spiel. Wenn der Kassierer plötzlich seine Kasse wechselt und das Band ist sehr lang, müssen viele Kunden ihre Waren wieder einsammeln und auf ein anderes Band legen. Ist das Band sehr kurz, können solche Kassenwechsel schneller statt finden.

Naja, die Piplines arbeiten schon auch parallel, um die Abläufe besser zu verzahnen. Aber das Bandbeispiel ist natürlich schön für die Vorstellung von Verzahnungen der Abläufe und Timings und warum man nicht zu oft jumpen sollte.

Wenn wir uns nun noch vorstellen, dass eine Geisterhand den Kassenwechsel schon vorbereitet hat, und die Sachen alle schon auf dem Band liegen nach dem Kassenwechsel, dann sind wir bei Hyperthreading...:)

Multicore wäre, um bei den Analogien zu bleiben, in drei Läden gleichzeitig einkaufen...

hustbaer

nachtfeuer schrieb:

Wenn wir uns nun noch vorstellen, dass eine Geisterhand den Kassenwechsel schon vorbereitet hat, und die Sachen alle schon auf dem Band liegen nach dem Kassenwechsel, dann sind wir bei Hyperthreading...:)

Nö. Hyperthreading wäre eine Kassierin die 4 Hände hat und mit einer Kassa mit zwei Registern und 3 Scannern zwei Bänder gleichzeitig bedient. Oder so.

Multicore wäre, um bei den Analogien zu bleiben, in drei Läden gleichzeitig einkaufen...

Versteh ich nicht.
Der Vergleich ist einfach nur Quatsch

cooky451

hustbaer schrieb:

Versteh ich nicht.

Ist doch klar: Die Regale sind der L1 Cache, das Lager im Supermarkt der L2 Cache, das nächste Großlager der L3 Cache, Lieferanten sind der RAM und die Felder sind die Festplatte. So können z.B. zwei Supermärkte nicht gleichzeitig eine Bestellung bei dem gleichen Lieferanten aufgeben, weil die nur einen Schreiberling haben.

nachtfeuer schrieb:

Naja, die Piplines arbeiten schon auch parallel, um die Abläufe besser zu verzahnen. Aber das Bandbeispiel ist natürlich schön für die Vorstellung von Verzahnungen der Abläufe und Timings und warum man nicht zu oft jumpen sollte.

Es geht ja auch darum, dass die Kunden parallel an verschiedenen Stationen der Kasse arbeiten können. Einer packt seine Sachen noch ein während der nächste beim Bezahlen ist und der übernächste seine Sachen auf das Band packt.

hustbaer schrieb:

Nö. Hyperthreading wäre eine Kassierin die 4 Hände hat und mit einer Kassa mit zwei Registern und 3 Scannern zwei Bänder gleichzeitig bedient. Oder so.

Das wiederum finde ich ich gut. Die Kassiererin oder auch Kassierer braucht aber nicht unbedingt 4 Hände. Aber wenn er 2 Kassen hat, dann kann er bei der 2. Kasse die Preise schon mal ein tippen, während an der ersten Kasse der Kunde gerade sein Geld abzählt. Der Kassierer braucht dann nicht zu warten. Das ganze wird dann zwar nicht doppelt so schnell, aber ein wenig schneller dann doch.

Ich glaube wir sollten gemeinsam mal eine Abhandlung verfassen über so ein wichtiges Thema und in die FAQs stellen .

nachtfeuer

hustbaer schrieb:

[

Multicore wäre, um bei den Analogien zu bleiben, in drei Läden gleichzeitig einkaufen...

Versteh ich nicht.
Der Vergleich ist einfach nur Quatsch

Wieso? die Kassen sind doch nur die Piplines, der eigentliche Blick ist auf dem Ausgang des Supermarktes, dass da eben zeitlich versetzt einer nach dem anderen herauskommt
(also wo der Bus vor der Tür vorbeifährt sozusagen...)