Hallo an Alle, ich mache gerade eine Ausarbeitung zum Thema Pipelining in Mikroprozessor-Systemen. Dabei stellt sich mir gerade folgende Frage: Aus welchem Grund gibt es eigentlich unterschiedliche Anzahl von Stufen bei Pipeline-Prozessoren? Eine Vermutung dazu habe ich, aber ganz klar ist es mir noch nicht. Es muss davon abhängig sein, wie viele Teilschritte ein Befehl auf einem Mikroprozessor benötigt. - Benötigt ein Mikroprozessor nur zwei Teilschritte, also Fetch und Execute, so ist eine zwei-stufige Pipeline das idealste. - Bei drei Teilschritten, also Fetch, Decode, Execute ist eine dreistufige Pipeline das idealste. - Bei fünf Teilschritten, also Fetch, Decode, Execute, Memory Acess, Write Back, wäre eine fünf-stufige Pipeline das beste und - Bei sechs Teilschritten, also Fetch, Decode, Calculate Operands, Fetch Operands, Execute, Write back, wäre eine sechs-stufige Pipeline am besten. Weitere Fragen dazu sind: - An welchen Eigenschaften lässt sich erkennen, wieviele Teilschritte ein Befehl bei einem Mikroprozessor benötigt, bzw. in welche Kategorien werden die Prozessoren unterteilt? Kann man beispielsweise sagen, dass die Teilschritte von der komplexität des Befehlssatzes abhängig ist? Dann würde dies bedeuten, dass RISC-Prozessoren eine Pipeline mit relativ wenig Stufen benötigen, CISC dagegen mehr stufige Pipelines. Dies wiederspricht sich jedoch irgendwie damit, dass man RISC-Prozessoren Pipelining ermöglicht, da bei diesen die Befehle in etwa gleich lang sind. - Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei denen eine Pipeline garkeinen Sinn macht? - Gibt es Prozessoren mit vier Teilschritten? - Gibt es Prozessoren mit mehr als sechs Teilschritten? - Kann mir vielleicht jemand zu jedem der oben aufgezählten ein Beispiel Prozessor nennen? Ich weiss, dass sind ne Menge Fragen, leider konnte ich mir diese durch längere Recherche nicht beantworten. Vielen Dank schonmal im Voraus für eure Antworten! Gruß, Christoph
> "- Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei > denen eine Pipeline garkeinen Sinn macht?" AVR, soweit ich weiß. > "- Gibt es Prozessoren mit mehr als sechs Teilschritten?" http://de.wikipedia.org/wiki/NetBurst Pentium 4 - 20 Stufen.
Christoph Bechtel schrieb:
> - Gibt es Prozessoren mit vier Teilschritten?
Die erste Generation von TriCore (32-Bit µC) hatte ne 4-stufige
Pipeline. Beim TriCore 2 sind's inzwischen 6.
Danke schonmal für eure Antworten. Aber ist denn meine Vermutung richtig, dass die Anzahl der Stufen einer Pipeline genauso groß ist wie die Anzahl der Teilschritte der Befehle? Wie kategorisiert man Prozessoren mit zwei, drei vier, fünf und sechs und mehr Teilschritten?
Die Stufen einer Pipeline hängen doch nicht mit der Anzahl Teilschritten eines Befehls zusammen sondern umgekehrt... Der Befehl hat (zwangsweise im notfall durch einfügen von no ops) soviele Teilschritte wie die Pipeline lang ist. Klar gibt es immer so "typische" Pipelinestrukturen aber prinzipiell kann ich mir ne Pipelein von 2 ... bis X Stufen bauen, z.B. GPUs/Vektorrechner haben typischerweise ne Sehr lange Pipeline CPUs für Controll Aufgaben eher im Bereich 5 - 9 Stufen. Auch bei einem AVR "KÖNNTE" ne Pipeline Sinn machen (vieliecht ist sogar eine drinn...)
Verwendet man eigentlich nicht auch Pipelines wegen der Signallaufzeiten usw in einem Chip bei einigen MHz muss man da schon aufpassen. MFG Patrick
> >"- Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei >> denen eine Pipeline garkeinen Sinn macht?" > >AVR, soweit ich weiß. der AVR hat 3 Pipelinestufen ;) Register Operands Fetch ALU Operation Execute Result Write Back Sie werden aber hintereinander in einem Takt ausgeführt. Zu finden unter "AVR CPU Core" in den AVR-Datenblättern
Marc S. schrieb: >> >"- Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei >>> denen eine Pipeline garkeinen Sinn macht?" >> >>AVR, soweit ich weiß. > > der AVR hat 3 Pipelinestufen ;) > > Register Operands Fetch > ALU Operation Execute > Result Write Back > > Sie werden aber hintereinander in einem Takt ausgeführt. Zu finden unter > "AVR CPU Core" in den AVR-Datenblättern Da steht bei einem ATmega16 bei mir: --- Instructions in the program memory are executed with a single level pipelining. While one instruction is being exe- cuted, the next instruction is pre-fetched from the program memory. This concept enables instructions to be executed in every clock cycle. ---
Christoph Bechtel schrieb: > - Benötigt ein Mikroprozessor nur zwei Teilschritte, also Fetch und > Execute, so ist eine zwei-stufige Pipeline das idealste. Dieses Schema ist ziemlich sinnfrei weil fast schon eine Tautologie. Die Implementierung einer konkreten Architektur bestimmt das Pipelining, nicht die Befehlssatz-Architektur selbst. Verschiedene Implementierungen der gleichen Architektur haben oft unterschiedliche Pipeline-Tiefen. Immerhin implementierten Intels 386 und der Pentium 4 die fast gleiche Architektur, aber die Pipeline-Tiefe unterscheidet sich um eine Grössenordnung. Auch innerhalb ungefähr gleichzeitiger Implementierungen können die Unterschiede sehr gross sein (AMD K5 vs Intel Pentium Pro). > - An welchen Eigenschaften lässt sich erkennen, wieviele Teilschritte > ein Befehl bei einem Mikroprozessor benötigt, Das läuft oft genug andersrum. Design-Parameter der Implementierung (z.B. die maximale Anzahl sequentieller Gatterstufen innerhalb eines Taktes) bestimmen die maximal mögliche Komplexität der einzelnen Pipelinestufen und daraus ergibt sich, wie fein die Befehle in (Unter-)Schritte aufgeteilt werden müssen um damit implementiert zu werden. > Kann man beispielsweise sagen, dass > die Teilschritte von der komplexität des Befehlssatzes abhängig ist? Auch. > Dann würde dies bedeuten, dass RISC-Prozessoren eine Pipeline mit > relativ wenig Stufen benötigen, CISC dagegen mehr stufige Pipelines. Zwangsläufig aufgrund der komplexeren Dekodierung. Dazu kommt die Frage, ob Befehle in Programmreihenfolge ausgeführt werden oder in Abhängigkeit voneinander auch anders, und ob mehr als ein Befehl parallel ausgeführt werden soll. > Dies wiederspricht sich jedoch irgendwie damit, dass man > RISC-Prozessoren Pipelining ermöglicht, da bei diesen die Befehle in > etwa gleich lang sind. Wenn du mit der Länge die Codierung meinst: Die Dekodierung kompliziert die Pipeline, aber auch bei einfacher Codierung bleibt genug zu tun übrig. Das die Pipeline angeht sind RISCs nicht uniform. Man kann mindestens zwischen ALU-Ops, Load/Store-Ops und FPU-Ops unterscheiden, die jeweils völlig unterschiedliche Pipelinetiefen haben können. > - Gibt es auch Prozessoren, die nur einen Teilschritt haben, also bei > denen eine Pipeline garkeinen Sinn macht? Je Pipeline desto Transistor. Willst du Transistoren sparen, spare an Pipelines. Ganz am Anfang waren Pipelines folglich unüblich. > - Kann mir vielleicht jemand zu jedem der oben aufgezählten ein Beispiel > Prozessor nennen? Bischen Arbeit solltest du schon selber machen. Zumal du wie schon skizziert für unterschiedliche Befehle beim gleichen Prozessor unterschiedliche Tiefen kriegst.
Christoph Bechtel schrieb: > Aber ist denn meine Vermutung richtig, dass die Anzahl der Stufen einer > Pipeline genauso groß ist wie die Anzahl der Teilschritte der Befehle? Einerseits nein. Allein schon weil die x86 Architektur Befehle kennt, die auch in aktuellen Implementierungen in Hunderten von Teilschritten ausgeführt werden. Als Mikroprogramm. Andererseits ja. Denn wenn man Mikroprogrammierung mal draussen lässt, entspricht bei heutigen auf Performance optimierten Prozessoren eine Pipeline-Stufe fast per Definition einem Teilschritt. Die schon erwähnte Tautologie. Wenn's nicht so ist, dann ist man bei der Optimierung noch nicht ganz im Ziel angekommen und dreht in mancher Stufe Ehrenrunden, was das Pipelining ins stocken bringt (vgl. die sehr ähnlichen Intel Pentium Classic [mit Ehrenrunde] und Cyrix M1 [ohne]). Ist nicht Performance normaler Standard-Operationen das Hauptkriterium, dann kann alles rauskommen. Die dsPIC30 beispielsweise haben trotz teilweise komplexer mem=>mem Befehle eine sehr kurze Pipeline mit vielen Teilschritten in einem einzigen Takt.
Ohh... hier hat sich ja einiges getan. Vielen Dank für eure Posts. Nur dass ich das richtig verstanden habe, möchte ich das noch einmal zusammenfassen: Grundsätzlich bestimmt also die Architektur des Mikroprozessors, insbesondere die daraus resultierenden Teilschritte (Mikrobefehle), die Tiefe einer Pipeline. Je mehr Mikrobefehle ein Befehl enthält, desto tiefer sollte die Pipeline sein, um möglich viel Performance aus dem Mikroprozessor rauszuholen. Des Weiteren ist es sinnvoller einen RISC-Prozessor mit einer Pipeline auszustatten als einen CISC-Prozessor, da der RISC-Prozessor kleine Befehle hat, die schneller ausgeführt werden können und somit auch die Taktrate erhöht werden kann. Die Verarbeitung der RISC-Befehle durch die Pipeline ist einfacher als CISC-Befehle. Ich hoffe das ist soweit richtig. Jetzt muss ich doch noch mal ein paar weitere Fragen stellen: - Die von mir genannten "Teilschritte" eines Befehls sind Mikrobefehle, aus denen der Befehl besteht oder? - Werden jetzt die einzelnen Mikrobefehle auf die verschiedenen Stufen einer Pipeline aufgeteilt, oder enthält jede Stufe einen eigenen kompletten Befehl? - Wie kann man sich eine Pipeline hardwaretechnisch vorstellen? Ist dies einfach nur ein "Bus" zwischen den verschiedenen Einheiten eines Mikroprozessors und dem Speicher oder gehört auch ein Pipeline-Controller dazu? Irgendwie muss das ganze ja kontrolliert werden. Vielleicht hat jemand ne gute Seite die beschreibt, wo eine Pipeline in ein Mikroprozessor eingebettet ist. Schönes Wochenende! Gruß, Christoph
Christoph Bechtel schrieb: > Nur dass ich das richtig verstanden habe Hast du nicht. > Grundsätzlich bestimmt also die Architektur des Mikroprozessors, > insbesondere die daraus resultierenden Teilschritte (Mikrobefehle), die > Tiefe einer Pipeline. Nein. > Je mehr Mikrobefehle ein Befehl enthält, desto > tiefer sollte die Pipeline sein, um möglich viel Performance aus dem > Mikroprozessor rauszuholen. Nein. > Des Weiteren ist es sinnvoller einen RISC-Prozessor mit einer Pipeline > auszustatten als einen CISC-Prozessor, Nein. Nur etwas einfacher. > - Die von mir genannten "Teilschritte" eines Befehls sind Mikrobefehle, > aus denen der Befehl besteht oder? Mikrobefehle sind etwas gänzlich anderes. Siehe beispielsweise http://en.wikipedia.org/wiki/Instruction_pipeline http://en.wikipedia.org/wiki/Pipeline_(computing) http://en.wikipedia.org/wiki/Microcode Generell ist die Wikipedia eine ganz passable Informationsquelle dafür.
Hmm.. okay, dass die Bezeichnung der Mikrobefehle in diesem Zusamenhang falsch ist sehe ich inzwischen ein. Aber ich bin der Meinung, dass auf jeden Fall von der Performance her sinnvoller ist einen RISC-Prozessor mit einer Pipeline "auszustatten" als einen CISC-Prozessor. Das hat einfach den Grund, dass die RISC-Befehle kleiner sind und sich von ihrer Ausführungszeit mehr ähneln als die Befehle der CISC-Prozessoren. Die Befehle der CISC-Prozessoren können ja theoretisch beliebig lang und kurz sein, also werden dort viele Lücken in der Pipeline entstehen, oder liege ich auch damit falsch? Bezüglich der Tiefe der Pipeline meinte ich nicht die Architektur des Mikroprozessors, sondern wie du oben schon gesagt hattest die Implementierung des Mikropozessors. >> Je mehr Mikrobefehle ein Befehl enthält, desto >> tiefer sollte die Pipeline sein, um möglich viel Performance aus dem >> Mikroprozessor rauszuholen. > >Nein. Wenn wir mal das Wort "Mikrobefehle" durch "Teilschritte eines Befehls" ersetzen, dann stimmt das aber doch? Eine geringere Tiefe würde bedeuten, dass der Prozessor nicht mehr bestmöglich ausgenutzt wird und eine größere Tiefe wäre nutzlos bzw. steht bei einem unvorhersehbarem Sprung sogar im Weg, da mehr Daten aus dem Speicher nachgeladen werden muss. Bitte korrigier mich, wenn ich damit falsch liege. Gruß, Christoph
Christoph Bechtel schrieb: > Aber ich bin der Meinung, dass auf jeden Fall von der Performance her > sinnvoller ist einen RISC-Prozessor mit einer Pipeline "auszustatten" > als einen CISC-Prozessor. Wäre Intel dieser These gefolgt, der Welt wäre der Siegeszug der x86-Prozessoren erspart geblieben. > als die Befehle der CISC-Prozessoren. Die Befehle der CISC-Prozessoren > können ja theoretisch beliebig lang und kurz sein, also werden dort > viele Lücken in der Pipeline entstehen, oder liege ich auch damit > falsch? Nein, das ist korrekt. Und der Versuch, effektive Pipelines einzubringen, hat DEC soviel Geld gekostet, dass das Ende der Super-CISC VAX besiegelt war. Aber bezogen auf x86er: Die weitaus meisten Befehle (entsprechend Laufzeitstatistik) passen in der Ausführungsphase in ein recht simples Schema: - Adresse berechnen - Operand laden - Rechnen - Operand speichern wobei mancher Schritt entfallen kann. Die Pipeline liegt auf der Hand und wurde von Cyrix auch exakt so umgesetzt. Intel hatte in der 486/Pentium Pipeline Load und Execute zusammengelegt und damit für häufige Ehrenrunden gesorgt. > Wenn wir mal das Wort "Mikrobefehle" durch "Teilschritte eines Befehls" > ersetzen, dann stimmt das aber doch? Dann stimmt das. Ungefähr. Es gibt aber noch andere Aspekte. Nichtsequentieller Befehlsfluss beispielsweise. Je tiefer die Pipeline, desto grösser der Schock wenn sie unterbrochen wird. Da man gemeinhin davon ausgeht, dass einer von grob 5 Befehlen ein Sprungbefehl ist, sollte man das im Auge behalten. Eine Zeitlang hatte IBM seine RS/6000 Schiene gleichzeitig in 2 Richtungen entwickelt. die Power3/4/5... für eher datenorientierte technisch/wissenschaftliche Aufgaben mit tendentiell guter Planbarkeit der Befehle und die RS64 für stark entscheidungsorientierte schlecht vorhersagbare kaufmännische Aufgaben. Dementsprechend hatten die PowerX eine tiefe Pipeline mit hohem Takt, die RS64 eine extrem kurze Pipeline mit niedrigem Takt. Eine sehr tiefe Pipeline kann dazu führen, dass voneinander abhängige Befehle langsamer werden und auch die Planung der Befehlsausführung immer mehr in Raterei ausartet. Historischer Spitzenreiter in dieser Problematik war der Pentium 4, bei dem der Planungszeitpunkt in der Pipeline so weit vor der Ausführung lag, dass er nur raten aber nicht wissen konnte was wann zu starten war. Und wenn er damit falsch lag, war er langsamer als die Konkurrenz.
Wie reihen sich den superskalare Architekturen darin ein? http://en.wikipedia.org/wiki/Superscalar_architecture Hier muss es je mehrere Pipelines geben, und Fetches durfen sich nicht quer kommen. Braucht's dazu mehrere Bussysteme (eines für jede Pipeline)? Wie wird erkannt, daß zwei Befehle innerhalb der gleichen "Issue Group" ausgeführt werden können? Dazu müssen ihre Operanden ja unabhängig sein, weil ein Befehl nicht auf das Ergebnis eines anderen, sich ebenfalls gerade in der Pipeline befindlichen Befehls, verwenden kann. A. K. schrieb: > Es gibt aber noch andere Aspekte. Nichtsequentieller Befehlsfluss > beispielsweise. Je tiefer die Pipeline, desto grösser der Schock wenn > sie unterbrochen wird. Da man gemeinhin davon ausgeht, dass einer von > grob 5 Befehlen ein Sprungbefehl ist, sollte man das im Auge behalten. Moderne CPUs machen da nen "Inject" in die Pipeline, AFAIK. D.h. es wird nachträglich in die Pileline was reingefummelt, so daß bei einem Sprung nicht so viel verloren ist. Johann
Johann L. schrieb: > Hier muss es je mehrere Pipelines geben, Korrekt. Die gab es allerdings schon vorher und superskalare Ausführung sollte die existierenden nebenläufigen Pipelines besser nutzen. > und Fetches durfen sich nicht quer kommen. ??? > Wie wird erkannt, daß zwei Befehle innerhalb der gleichen > "Issue Group" ausgeführt werden können? Dazu müssen ihre Operanden ja > unabhängig sein, weil ein Befehl nicht auf das Ergebnis eines anderen, > sich ebenfalls gerade in der Pipeline befindlichen Befehls, verwenden > kann. Was vielleicht helfen mag: "The Anatomy of a High Performance Microprocessor" von Shriver/Smith, ISBN 0818684003. Beschreibt ziemlich detailliert den inneren Aufbau des AMD K6, und damit einer Lösungsvariante dieser Problematik. Auch sehr informativ: http://www.agner.org/optimize Punkt 3, sowie http://www.azillionmonkeys.com/qed/cpuwar.html und manches Grundlagenmaterial von Hannibal auf arstechnica.com. Das lässt sich hier wirklich nicht gut in wenigen Worten erklären, dazu ist es in all seinen Varianten viel zu komplex.
A. K. schrieb:
> Auch sehr informativ: http://www.agner.org/optimize Punkt 3, sowie
Typisch... nicht nur für Intel und AMD, daß die Informationen nicht vom
Hersteller kommen, sondern per reverse Engineering beschafft wurden bzw.
werden mussten...
Auch nicht übel: http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Der Autor neigt allerdings zu wilden Spekulationen, insbesondere in seinen anderen Texten.
Johann L. schrieb: > Typisch... nicht nur für Intel und AMD, daß die Informationen nicht vom > Hersteller kommen, sondern per reverse Engineering beschafft wurden bzw. > werden mussten... Sachte, optimzation guides gibt es von Intel wie von AMD. In der Qualität wie von Agner jedoch nicht. Andererseits sind solche Analysen manchmal auch nicht ganz korrekt. Bei AMD K7 aufwärts war Agner anfangs ziemlich auf dem Holzweg, er hatte dessen Pipelining nicht verstanden, ist aber (mit etwas Hilfe von mir) besser geworden. Allerdings sind die Herstellerdokus nicht so tiefschürfend und werden vor der Veröffentlichung gründlich zensiert, um nicht zu viel über die interne Struktur zu verraten. Wobei auch manche wichtigen Aspekte unter die Räder kommen, die Schwachpunkte verraten. Mit NDA gibt's da teilweise mehr Info. Etwas detailfreudiger sind manche Herstellerinfos an unerwarteter Stelle: in Patenten. Grosse Teile vom K6 kann man dort wiederfinden und das war wohl auch eine wesentliche Quelle des obigen Buches. Und dort findet man in geradezu epischer Breite auch eine Architektur die als "missing link" exakt zwischen K5 und K7 liegt und nie implementiert wurde (der K6 ist kein Design von AMD, sondern von Nexgen).
A. K. schrieb:
> Mit NDA gibt's da teilweise mehr Info.
Die Frage ist dann, ob ein NDA der Beschreibung der Architektur
(Scheduling, Pipelines, ...) innerhalb eines Open Source Compilers
widerspricht. Immerhin stellt die Compiler-Quelle die Informationen, die
in den Dokumenten enthalten sind, offen lesbar dar -- eben in einer
etwas anderen Form.
Ich würd da eher raten, daß die Hersteller ihre Hausaufgaben nicht
machen und NDAs eigentlich nicht nötig wären. Es muss doch möglich sein,
die Hardware für Compilerbauer et al. hinreichend darzulegen, ohne daß
daraus tiefgreifende Rückschlüsse (solche, die die Konkurrenz nicht eh
schon hat) auf die Architektur möglich sind; ebenso wie aus dem
Befehlssatz nicht auf die Architektur geschlossen werden kann.
Einige Hardwarehersteller wissen allerdings gar nicht mehr, was sie da
bauen und produzieren. Namentlich Infineon: Teilmodule wurden zugekauft
und aufs Silizium gepappt, aber keiner weiß, wie's geht. Dokumentation
gibt's keine. Irgendwo gibt's Treiber, die das Wissen implizit
enthalten, aber in München ist keiner mehr, der weiß, was da abgeht. Und
in Indien... naja, lassen wir das Thema. :-/
Johann
Johann L. schrieb: > Die Frage ist dann, ob ein NDA der Beschreibung der Architektur > (Scheduling, Pipelines, ...) innerhalb eines Open Source Compilers > widerspricht. AMD hatte die erste Version des Optimization Guide vom K7 rausgelassen ohne sie zu redigieren. Mitsamt NDA-Formular vorne drauf. 2 Tage drauf war's wieder weg und kam später zensiert wieder raus. Fehlten insbesondere ein paar Schwachpunkte beim branch predictor. Sowas aus dem Compiler rauszulesen ähnelt dem Versuch, aus einer Frikadelle wieder das Schwein zu machen. > Ich würd da eher raten, daß die Hersteller ihre Hausaufgaben nicht > machen Die Autoren dieser Dinger sind natürlich nicht die hochbezahlen Architekten selbst, insofern stochern die u.U. selber etwas im Nebel.
Zum Zusammenspiel der Pipelines im K7/K8 hatte ich für Agner mal 2 Bildchen fabriziert. Sind zwar vermutlich nur in Verbindung mit der Gesamtstruktur verständlich, ich hänge sie aber trotzdem mal ran.
Und hier der Ablauf von typischen x86 load-execute und load-execute-store Operationen.
A. K. schrieb: > Sowas aus dem Compiler rauszulesen ähnelt dem Versuch, aus einer > Frikadelle wieder das Schwein zu machen. Seh ich auch so. Um so mehr verwundern mich die NDAs.
Ich wunder mich manchmal, wie die Leute das heutztage noch schaffen, Teile einer CPU Architektur zu reversen. In den 70er Jahren war das noch ziemich einfach, mit Lichtmikroskop Bild machen und nachverfolgen was abgeht, wie hier: http://www.flylogic.net/blog/?p=63 Aber heute? Um allein 1mm² aussagekräftig abzubilden, braucht man 1000um*20=20000 Pixel pro Achse (50nm pro pixel) 200000²=400M, Ein zusammengesetztes REM Bild, auf dem man die Strukturen von 1mm² sehen kann, hat somit 400M Speicherbedarf. Und das multipliziert mit allen Layern eines Chips. (Die daraus folgende Auflösung der Masken zur Fertigung ist auch sehr beachtlich) Meiner Meinung nach fast unmöglich, somit braucht mal wohl irgendwie sie Infomationen des Herstellers.
Johann L. schrieb:
> Seh ich auch so. Um so mehr verwundern mich die NDAs.
Wer bindet den Kunden, Journalisten und Konkurrenten schon gerne seine
Schwachpunkte direkt unter die Nase? Erst recht nicht am Anfang, wenn
alle drüber schreiben. Später sind Teile der bei AMD kastrierten Info
auch wieder offiziell aufgetaucht.
Dass beispielsweise eine Konstruktion wie der Trace Cache vom P4 in
Verbindung mit just-in-time Compilern eine recht üble Sache sein kann,
das hat Intel im Guide nur sehr sehr verschlüsselt formuliert. M.E. nur
jenen Leuten verständlich, die wissen wie sowas funktioniert.
Fuzzy schrieb: > Meiner Meinung nach fast unmöglich, somit braucht mal wohl irgendwie sie > Infomationen des Herstellers. Korrekt. Man sammelt alles an Info-Schnipseln was da ist. Die erwähnten Guides, Artikel, Präsentationen evtl. mitsamt Ton-Aufzeichnung usw. Dann gibt es gelegentlich Detail-Info in Patenten. Nur muss man peilen können, ob das was mit der Realität zu tun hat oder nicht. Oft nicht, manchmal schon. In diese Falle ist Hans de Vries mal reingetappt und hat so beispielsweise eine wunderschön illustrierte Beschreibung eines K8 abgeliefert, die von A bis Z komplett falsch ist weil sie auf einem nie realisierten Projekt aus diversen Patenten basiert: http://www.chip-architect.com/news/2001_10_02_Hammer_microarchitecture.html. Testprogramme. Das Verhalten von verschiedensten Codeschnipseln messen. Die Performance Counter der Prozessoren. Die zählen allerlei Statistiken und Events mit, und damit lässt sich was anfangen. Vor allem in Verbindung mit Testprogrammen. Anfangs (P5) hatte Intel diese Details nur gegen NDA raugerückt. AMD wiederum stellt mit dem Codeanalyst ein Tool zur Verfügung, das auf einem Programm zur Software-Simulation der Pipeline aus der Designphase basiert, und daraus Optimierungs-Tips ableitet. Vor allem aber braucht man eine solide Vorstellung davon, wie Rechnerarchitekturen funktionieren. Um diese ganzen Schnipsel in Beziehung zu setzen. Ist ein recht interessantes Puzzle-Spiel.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.