Diskussion:Pipeline (Prozessor)

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
  • Konflikte->Ressourcenkonflikte, wenn eine Stufe der Pipeline Zugriff auf eine Ressource benötigt, die bereits von einer anderen Stufe belegt ist.
    • Was genau ist mit Ressource gemeint? Eine Ressource kann bei mir auch Wasser oder Bier im Kühlschrank sein... Ich denke das sollte hier genauer definiert werden. Z.B. welche Hardware-Ressource genau gemeint ist. z.B. Register, etc Musterstudent 18:06, 30. Jan. 2011 (CET)[Beantworten]
(Neue Einträge bitte per Pluszeichen oben in der Werkzeugleiste initialisieren, dann landen sie auch unten, wo sie hingehören.) Ich habe das nicht geschrieben, aber es ist wohl insofern korrekt, als hier als Ressource alles mögliche wichtig werden kann, jede Art von Verarbeitungsstufe, Register, Buszugang usw. Dass im Prozessor kein Wasser oder Bier vorkommt und auch nicht benötigt wird, ist in meinen Augen so selbstverständlich, dass man es nicht ausdrücklich erwähnen muss. --PeterFrankfurt 02:53, 31. Jan. 2011 (CET)[Beantworten]

Pipelining vs. Parallelisierung[Quelltext bearbeiten]

Hallo Jungs und Maedels,

Pipelining ist nicht Parallelisierung! Das ist die ganze Idee von Pipelining, dass Befehle nicht paralleisiert werden sondern seriell einzelne Stages abgearbeitet werden. Der Durchsatz wird auf max. 1/Pipelinestage gebracht. Aber grundsaetzlich ist hier nix parallel! Wenn man wie auf Graphikkarten parallele Pipelines hat, ist das wieder was anderes. Aber eine Pipeline ist eine Pipeline - und das is seriell. (vgl. Schlepplift - mehr Zughaken, mehr Durchsatz... aber keine parallele Befoerderung) Eine "Production pipeline" zB am Foerderband ist ja auch nicht parallel. Die englische Version schrammt so ein wenig an der Definition vorbei, so dass es ungefaehr noch als richtig durchgehen koennte - mit Bauchweh. Die deutsche Version ist schlichtweg falsch.

lg

Naja, je nach definition ist das schon parallel, denn es sind ja bei einer Pipeling mehrere Befehle/Autos/Skifahrer gleichzeitig in Bearbeitung, was voraussetzt, dass es untereinander keine Abhängigkeiten gibt (z.B. Daten-Hazards bei CPUs oder Ressourcen-Konflikte beim Autos-Schrauben (z.B. nur ein Schraubendreher vorhanden, der in verschiedenen Pipelinestufen benötigt wird). Aber ich gebe dir recht, der 1. Absatz kann so nicht bleiben - ich habe mich mal an einer Überarbeitung versucht. --Jdiemer 15:00, 31. Jul. 2007 (CEST)[Beantworten]
Dabei sind jetzt aber Teile doppelt im Artikel. Sie werden neuerdings schon in der Einleitung erklärt, dann im gleich folgenden Kapitel teilweise gleich nochmal. Das sollten wir noch ein bisschen glätten. --PeterFrankfurt 15:58, 31. Jul. 2007 (CEST)[Beantworten]
Ja, das ist mir auch aufgefallen. Wobei man wohl am besten die Widerholungen weiter unten kürzt, bzw. durch neue, weiterführende Informationen ergänzt. Die Einleitung ist (meiner Meinung nach) so recht gut verständlich, trotz Nennung von mehr Details. --Jdiemer 16:16, 31. Jul. 2007 (CEST)[Beantworten]

Was ist mit Grafikkarten Pipelines? z.B. 12, 16, 24, evtl. 32? Wie funktioniert das... Können wir das irgendwie in diesem Artikel erwähnen... wenn es jemand weiß? ;-) Gruß --SebastianL 08:45, 25. Jul 2005 (CEST)

Das funktioniert wie jede andere Pipeline auch, die Grafikkarte (GPU) besitz im Prinzip auch einen Prozessor...

um die pixelpipeline oder wie das heißt erklären zu können, muss man sich glaub ich mit grafik programmierung a la opengl auskennen. da man diese pipelines auch programmieren kann, nehm ich an, dass es sich nicht um das selbe prinzip handelt. würde mich aber auch interessiernn :) (nicht signierter Beitrag von 94.134.218.211 (Diskussion) 07:39, 10. Jan. 2011 (CET)) [Beantworten]

ein weiterer nachteil bei pipeline ist doch auch, dass dadurch die genaue laufzeit von programmen stark von der programmstruktur abhängt und die exakte laufzeit kaum mehr vorherzusagen ist, oder? (zumindst wird das auf der TU wien so "gelehrt")

    Das ist imho richtig, trifft aber auf jeden Mechanismus zu, der eine sequentielle Bearbeitung von Befehlen versucht aufzulösen. DoomWarrior 19:17, 6. Apr. 2007 (CEST)[Beantworten]

hm warum den kein verweis auf sprungvorhersagen von hier aus?

    Hmm du meinst als Linkliste untern? Meines erachtens sollte das als Punkt bei Konflikte eingearbeitet werden als Problemlösungshinweis. DoomWarrior 19:17, 6. Apr. 2007 (CEST)[Beantworten]


kennt man die Pipeline und ist sie sehr einfach aufgebaut, so ist sie sehr wohl vorhersagbar, man berechnet in diesem Fall oft die Ausführungszeit im schlimmsten Fall (Worst Case Execution time)

die Pipelines der modernen CPUs sind nicht öffentlich und komplziert, Cache und branch-prediction machen eine zeitliche Vorhersagbarkeit hier dann schwierig

Warum "Architektur"?[Quelltext bearbeiten]

Pipelining ist doch gerade kein Aspekt der Architektur (zumindest in der Regel, Stichwort delay slot), sondern einer der Mikroarchitektur. Ich komme darauf, weil ich auf der Seite zu Prozessor-Architektur gerade ein paar Klarstellungen vornehme, was eben nicht zur Architektur, sondern zur Mikroarchitektur gehört.


da hat er wohl Recht - wenn man es so versteht... Architektur -> Intruktion Set Architektur Microa -> Prozessorarchitektur

Nicht nur Hardware[Quelltext bearbeiten]

Pipelining ist eher ein Prinzip, keine Bauweise für Hardware. Zum Beispiel werden auch Datenbank-Abfragen so in Mikro-Operationen zerlegt und parallelisiert. Schade, dass ich mich mit dem Thema nicht wirklich auskenne, aber wenn da jemand genaueres weiß, wäre es IMHO schon interessant, den Artikel ein bisschen allgemeiner zu schreiben.

Siehe Parallelisierung -- D. Dÿsentrieb 02:13, 16. Aug 2006 (CEST)

also natürlich handelt es sich bei dem Begriff Pipelining AUCH um eine grundlegende Prozessortechnik !!! denke der obere Einwand kann gelöscht werden. vergl. "Ungerer/Brinkschulte -Microcontroller/Microprozessoren"

Phasenpipelining[Quelltext bearbeiten]

Das Beispiel am Ende befasst sich nicht mit Befehlpipelining, sondern mit Phasenpipelining. Befehlspipelining beschreibt die Aufteilung des Befehlsstroms auf mehrere Verarbeitungseinheiten. Einfacher gesagt, die Befehlsausführungsphase wird parallelisiert. Des weiteren ist die arithmetische Pipeline ein Spezialfall der Phasenpipeline. Ausserdem sollte auf Superskalarität in diesem Artikel eingegangen werden, da es sich dabei um die Nutzung von gleichzeitigem Nutzen von Phasen- und Befehlspipeling handelt. Der Artikel ist so gesehen leider falsch. Pipelining ist auch keine Architektur, sondern eine Form von Parallelisierung.

Möchte den Artikel verschieben, wenn kein Widerspruch kommt. Siehe Wikipedia:Qualitätssicherung/31._Dezember_2007#Pipeline-Architektur

Von mir aus ok. --PeterFrankfurt 22:37, 11. Jan. 2008 (CET)[Beantworten]
dito. Habe ich ja bereits vorgeschlagen... --Ponte 23:50, 11. Jan. 2008 (CET)[Beantworten]
Habe den Artikel verschoben und etwas angepasst. Habe alte Links umgebogen, dennoch das alte Lemma als Redirect erstmal belassen.--Cactus26 10:43, 15. Jan. 2008 (CET)[Beantworten]

Datenhazards[Quelltext bearbeiten]

Wäre es nicht sinnvoll bei den Datenhazards die RAW, WAR, und WAW Hazards mit je einem Beispiel einzufügen? Das macht das ganze etwas anschaulicher. Dann könnte man auch gleich einen Link auf den Tomasulo-Algorithmus bzw. auf Scoreboarding setzen. Werd mich mal ransetzen und auf meiner Testseite was entsprechendes zurechtbasteln.. Freaky86 17:30, 12. Mär. 2008 (CET)[Beantworten]

Hab gesehen, dass es für Pipeline-Konflikte einen eigenen Artikel gibt. Wäre es nicht sinnvoll, einen aussagekräftigeren Verweis einzufügen á la "Siehe Hauptartikel Pipeline-Hazard"?

Übersetzung in die chinesische Wikipedia[Quelltext bearbeiten]

Die Version 17:19, 2. Nov. 2008 TXiKiBoT dieses Artikels wird in die Chinesische Wikipedia übersetzt, um ein dort vorhandenen Kurzartikel zu verstärken.--Wing 16:36, 2. Jan. 2009 (CET)[Beantworten]

NetBurst, modern?[Quelltext bearbeiten]

"In einer modernen CPU mit einem Kerntakt im Gigahertz-Bereich (1 GHz ~ 1 Milliarde Takte pro Sekunde) kann die Befehlspipeline über 30 Stufen lang sein (vgl. NetBurst)" - NetBurst ist weder modern noch ein Paradebeispiel für die Prozessorpipeline: "Somit erwies sich die NetBurst-Architektur (hohe Taktfrequenzen, überlange Pipelines) als Sackgasse und führte letztlich zu den Intel-Prozessoren mit Core-Mikroarchitektur, dessen Vorläufer bereits beim Pentium M benutzt wurde."

Weiterhin ist unter der Überschrift "Vorteile und Nachteile" der Punkt "Der Vorteil langer Pipelines besteht in der starken Steigerung der Verarbeitungsgeschwindigkeit." sehr kritisch zu betrachten. Die Erfahrungen von Intel wie auch ARM zeigt das diese Aussage nur in seltenen Ideal-Fällen zutrifft.

Die Behauptung das der "Intel Pentium 4" oder der "IBM Power5" "[..] sehr ausgeklügelte Techniken zur Sprungvorhersage [..]" besitzen ist zwar nett, aber verzerren das Bild. Oder soll damit ausgedrückt werden das Prozessoren mit kurzer Pipeline eine schlechtere Sprungvorhersagetechnik nutzen? Tatsächlich ist es so, das die Sprungvorhersage von einer Prozessorgeneration zur nächsten meist besser ist als die vom direkten Vorgänger. Das hat rein gar nichts mit der Pipeline oder deren Länge zu tun sondern ist das Ergebnis einer fortwährenden Weiterentwicklung. (nicht signierter Beitrag von 85.178.52.224 (Diskussion | Beiträge) 10:34, 21. Sep. 2009 (CEST)) [Beantworten]

Hyperthreading vs Pipelining[Quelltext bearbeiten]

Ist Hyperthreading nicht ein vom Marketing verwendeter Begriff für Pipelining? Meines Wissens handelt es sich bei den beiden um dasselbe. Wieso gibts also zwei Wikipedia Artikel? (nicht signierter Beitrag von 85.2.77.61 (Diskussion) 14:39, 20. Jun. 2011 (CEST)) [Beantworten]

Nein, da geht es ja um (teilweise echtes) paralleles Abarbeiten auf verschiedenen Subprozessoren (units) und Registerbänken. Das hat nichts mit dem zeitlich nacheinander verschachtelten Ausführungsmuster einer Pipeline zu tun. Ganz andere Baustelle. --PeterFrankfurt 22:23, 20. Jun. 2011 (CEST)[Beantworten]

Einleitung zu lang[Quelltext bearbeiten]

Ich finde die Einleitung etwas zu lang. Meiner Meinung nach würde der erste Absatz schon für eine einführende Erklärung reichen (auch wenn ich die aktuelle Formulierung schwer verständlich finde). Ich würde für die restlichen Absätze eine eigene Sektion "Funktionsweise" einfügen (vielleicht mit "Beispiel" als Untersektion). Vielleicht werde ich mich heute Abend mal ransetzen. --Christi4nK 21:46, 4. Jul. 2011 (CEST)[Beantworten]

Hmm, die zwei eher kleinen zusätzlichen Absätze machen in meinen Augen den Kohl nicht fett. Wenn man das auseinanderreißen würde, würde es eine Ecke unübersichtlicher, was ja auch nicht dem Verständnis dient. --PeterFrankfurt 03:27, 5. Jul. 2011 (CEST)[Beantworten]

Steigerung der Taktfrequenz[Quelltext bearbeiten]

Die folgende Formulierung in der Einleitung des Artikels erscheint mir irreführend:

Statt eines gesamten Befehls wird während eines Taktzyklus des Prozessors nur jeweils eine Teilaufgabe abgearbeitet, allerdings werden die verschiedenen Teilaufgaben mehrerer Befehle dabei gleichzeitig bearbeitet. Da diese Teilaufgaben einfacher (und somit schneller) sind als die Abarbeitung des gesamten Befehls am Stück, kann durch Pipelining die Taktfrequenz des Mikroprozessors gesteigert werden. Insgesamt benötigt ein einzelner Befehl nun mehrere Takte zur Ausführung, da aber durch die quasi parallele Bearbeitung mehrerer Befehle in jedem Zyklus ein Befehl „fertiggestellt“ wird, wird der Gesamtdurchsatz durch dieses Verfahren erhöht.

Je nach Aufbau des Prozessors werden grundsätzlich mehrere Taktschritte für eine Instruktion benötigt. Pipelining nutzt lediglich diese Tatsache aus um auf "ungenutzten" Teilen des Prozessors bereits mit der Bearbeitung der nächsten Instruktion zu beginnen. Das ist zunächst unabhängig von der Taktrate. --88.153.188.143 11:10, 29. Mai 2012 (CEST)[Beantworten]

Jein. Andererseits ist es auch Ziel des Pipelinings, die Mikroinstruktionen, in die ein Programmbefehl aufgeteilt wird (und die dann im Pipelining nacheinander ausgeführt werden), zu vereinfachen. Im Idealfall so, dass alle etwa den gleichen Zeitbedarf aufweisen und nicht eine viel mehr als alle anderen. Dann kann die Zykluszeit (inverse Taktfrequenz) auf die Länge der längstdauernden Teilaufgabe reduziert werden. Ok, die Geschwindigkeit von externen Einheiten wie Businterface und Co mag auch noch reinspielen, aber ich sehe schon auch einen Beitrag des Pipelinings zur Taktfrequenzerhöhung. --PeterFrankfurt (Diskussion) 04:28, 21. Jan. 2014 (CET)[Beantworten]