Hey, ich hab mich mal gefragt, wie ein PC funktioniert, wenn der Speichertakt ja meistens viel kleiner ist als der CPU Takt. Ich mein, bei jedem Takt muss doch der Code aus dem Speicher bei x86 Architekturen geladen werden. Sprich wenn ich ein 3 Ghz CPU, wie kann der Speicher dann auch so schnell die Daten liefern, wenn der Speicher nur mit 1066 Mhz arbeitet? Andererseits hab ich mir auch noch was überlegt. Wie eine CPU den in 1 Takt ein Befehl ausführen kann? Theoretisch müsste sie dazu doch intern mit einem noch schnelleren Takt arbeiten oder? Ich mein wenn ich mir überlege 1 Takt dafür die neue Instruktion aus dem Speicher holen. 1 Takt für das ausführen der Instruktion.
:
Verschoben durch User
Sebi2020 schrieb: > Hey, > ich hab mich mal gefragt, wie ein PC funktioniert, wenn der Speichertakt > ja meistens viel kleiner ist als der CPU Takt. Ich mein, bei jedem Takt > muss doch der Code aus dem Speicher bei x86 Architekturen geladen > werden. Sprich wenn ich ein 3 Ghz CPU, wie kann der Speicher dann auch > so schnell die Daten liefern, wenn der Speicher nur mit 1066 Mhz > arbeitet? Andererseits hab ich mir auch noch was überlegt. Wie eine CPU > den in 1 Takt ein Befehl ausführen kann? Theoretisch müsste sie dazu > doch intern mit einem noch schnelleren Takt arbeiten oder? Ich mein wenn > ich mir überlege 1 Takt dafür die neue Instruktion aus dem Speicher > holen. 1 Takt für das ausführen der Instruktion. Ja der Speichertakt ist langsamer als der CPU Takt. Aber sie muss nicht jede Instruktion erst aus dem Speicher holen. Dein Stichwort ist: CACHE. Zwischen CPU und Speicher liegen oft 3-4 Cachestufen. gruß cyblord
cyblord ---- schrieb: > Ja der Speichertakt ist langsamer als der CPU Takt. Aber sie muss nicht > jede Instruktion erst aus dem Speicher holen. > Dein Stichwort ist: CACHE. > Zwischen CPU und Speicher liegen oft 3-4 Cachestufen. > > gruß cyblord Was bringt dir eine Cache, wenn diese langsam gefüllt wird? Du schaltest den PC ein und da ist die Cache erst mal leer. Und wir dann erst langsam gefüllt, aber die CPU will schon zich mal eine Instruktion ausführen.
Sebi2020 schrieb: > cyblord ---- schrieb: >> Ja der Speichertakt ist langsamer als der CPU Takt. Aber sie muss nicht >> jede Instruktion erst aus dem Speicher holen. >> Dein Stichwort ist: CACHE. >> Zwischen CPU und Speicher liegen oft 3-4 Cachestufen. >> >> gruß cyblord > > Was bringt dir eine Cache, wenn diese langsam gefüllt wird? Du schaltest > den PC ein und da ist die Cache erst mal leer. Und wir dann erst langsam > gefüllt, aber die CPU will schon zich mal eine Instruktion ausführen. Liebchen, wenn du schon fragst, dann sei auch mit der Antwort zufrieden und zick mich nicht an. Es läuft nunmal so. Natürlich muss ein Cache erst gefüllt werden, na und? Dann kann die CPU halt nicht in wirklich JEDEM Takt einen sinvollen Befehl ausführen. So ist das. Ohne Cache könnte sie vielleicht nur jeden 200. Takt überhaupt einen Befehl ausführen. Kauf dir ein Rechnerarchtiektur Buch.
>> Was bringt dir eine Cache, wenn diese langsam gefüllt wird? Du schaltest >> den PC ein und da ist die Cache erst mal leer. Und wir dann erst langsam >> gefüllt, aber die CPU will schon zich mal eine Instruktion ausführen. > > Liebchen, wenn du schon fragst, dann sei auch mit der Antwort zufrieden > und zick mich nicht an. > Es läuft nunmal so. Natürlich muss ein Cache erst gefüllt werden, na > und? Dann kann die CPU halt nicht in wirklich JEDEM Takt einen sinvollen > Befehl ausführen. So ist das. Ohne Cache könnte sie vielleicht nur jeden > 200. Takt überhaupt einen Befehl ausführen. > Kauf dir ein Rechnerarchtiektur Buch. Ich hab dich nicht angezickt, dir nur einen Fehler in deiner Argumentation aufgeführt "Liebchen". und wenn du nachrechnest erscheit dir das auch logisch. Eine Cache ist dazu da Sachen, die schonmal ausgeführt wurden, wieder auszuführen, die schon mal ausgeführt wurden. Wovon du redest ist ein Puffer, und der macht viel mehr Sinn, wenn du von einem schnellen System auf ein Langsames gehst. Weil die CPU bei deiner Argumentation erst mal die Cahce fülle lasse muss, also nichts macht. Wenns sie voll ist, abarbeitet. Nun ist die Cache wieder leer. Die CPU muss wieder warten usw. Also hast du das selbe Ergebnis wie ohne Puffer.
Sebi2020 schrieb: > Was bringt dir eine Cache, wenn diese langsam gefüllt wird? Der bringt dann etwas, wenn die Zugriffe auf den Speicher nicht gleichverteilt sind. Und eben dies ist i.d.R. der Fall, d.h. manche Speicherbereiche wie der Stack werden häufiger angesprochen. Wenn du nichts anderes tust, als sequentiell Gigabytes abzugrasen, dann bringt es nichts. Aber schon der dafür verwendete Code ist eine Schleife, die immer und immer wieder ausgeführt wird. Und dieser Code ist nach dem ersten Durchlauf im Cache. Rechnerisch sieht das vereinfach so aus: Die Zugriffszeit auf einen L1 Cache sei 3 Takte. die Wahrscheinlichkeit dafür, dass man den Inhalt fort vorfindet sei 95%. Die Zugriffszeit auf den Speicher sei 20 Takte. Das sind jetzt willkürliche Zahlen eines vereinfachten Systems anno Uralt. Ergibt eine mittlere Zugriffszeit von 3 * 0.95 + 20 * 0.05 = 3,85 Takte. Ohne Cache wären es jedes Mal 20 Takte. Ausserdem hat heutiger Speicher zwar eine hohe Zugriffszeit jenseits von 100 Takten, aber andererseits eine hohe sequentielle Transferrate von zig GB/sec. Es dauert zwar lang, bis der Inhalt kommt, aber dann flutscht es.
Leute kommt mal runter bitte, nur weil sich jemand in der Anrede leicht vergreift, muss man es nicht gleich persönlich nehmen und es ausweiten^^ Zum Thema: Das ist tatsächlich so, wie cyblord es beschreibt. Ja, die CPU führt bei weitem nicht jeden einzelnen Takt etwas aus, aber es ist halt immer noch besser als wenn gar kein Cache da wäre. Klar müssen die Informationen schon mal geladen worden sein, aber das passiert öfters, als man vielleicht denken mag, den jedes Programm enthält sehr viele Schleifen bzw. Codeabschnitte, die immer wieder ausgeführt werden. Ebenso werden die Instruktionen meistens nacheinander ausgeführt, d.h. wenn erstmal eine Cache-Line geladen wurde, können ein paar Befehle ohne Verzögerung ausgeführt werden. Das Prinzip bezeichnet man als Lokalität und wird überall erklärt oder erwähnt, wenn es um CPU-Cache geht.
A. K. schrieb: > Wenn du nichts anderes tust, als sequentiell Gigabytes abzugrasen, dann > bringt es nichts. Aber schon der dafür verwendete Code ist eine > Schleife, die immer und immer wieder ausgeführt wird. Und dieser Code > ist nach dem ersten Durchlauf im Cache. > > Rechnerisch sieht das vereinfach so aus: > > Die Zugriffszeit auf einen L1 Cache sei 3 Takte. die Wahrscheinlichkeit > dafür, dass man den Inhalt fort vorfindet sei 95%. Die Zugriffszeit auf > den Speicher sei 20 Takte. Das sind jetzt willkürliche Zahlen eines > vereinfachten Systems anno Uralt. > > Ergibt eine mittlere Zugriffszeit von > 3 * 0.95 + 20 * 0.05 = 3,85 Takte. > Ohne Cache wären es jedes Mal 20 Takte. Mhs, aber das heißt nach dem Einschalten des Rechners ist der effektive Takt erst mal der Speichertakt. Und man muss sich ja selbst bei einer Schleife überlegen. Das dann zwar der Code schneller vorliegt, aber die Daten, die bei jedem Schleifendurchgang verarbeitet werden immer noch aus dem Speicher kommen. Ein gutes Beisspiel ist z.B. ein Array, was ich in einer Schleife verarbeite. Damit muss ich in jedem Takt den neuen Speicherwert aus dem Arbeitsspeicher holen. Und wäre ja wieder bei 1066 Mhz obwohl ich viel schneller arbeiten könnte.
Sebi2020 schrieb: > Wie eine CPU den in 1 Takt ein Befehl ausführen kann? Es sind bei aktuellen Intels bis zu separate 4 Befehle pro Takt, pro Prozessor-Core.
Sebi2020 schrieb: > Damit muss ich in jedem Takt den neuen > Speicherwert aus dem Arbeitsspeicher holen. Nicht ganz. Caches speichern die Daten nicht Byte-weise, sondern Block-weise ab. Sobald man also auf das erste Element zugegriffen hat, hat man die darauffolgenden bereits auch im Cache.
A. K. schrieb: > Ausserdem hat heutiger Speicher zwar eine hohe Zugriffszeit jenseits von > 100 Takten, aber andererseits eine hohe sequentielle Transferrate von > zig GB/sec. Es dauert zwar lang, bis der Inhalt kommt, aber dann > flutscht es. Naja, aber der Speichertakt bestimmte doch auch die Transferrate. Wenn ich einen Takt von 1066 Mhz habe und eine Busbreite von 32Bit habe, kann ich ja maximal (ca.) 1.000.000.000 * 4 Bytes pro Sekunde übertragen.
Sebi2020 schrieb: > Mhs, aber das heißt nach dem Einschalten des Rechners ist der effektive > Takt erst mal der Speichertakt. Ist nicht so einfach, da es längt sehr verschiedene Takt-Domänen gibt und die CPU sich erst einmal selbst initialieren muss, wozu auch der Takt gehärt. Aber ja, bis Tempo aufkommt dauert es etwas. > Ein gutes Beisspiel ist z.B. ein Array, was ich > in einer Schleife verarbeite. Damit muss ich in jedem Takt den neuen > Speicherwert aus dem Arbeitsspeicher holen. Das ist nicht ganz falsch und nicht ganz richtig. Ein Speicherzugriff holt gleich mindestens 64 Bytes en bloc aus dem Speicher in den Cache und wenn die CPU spitz kriegt, dass du den Speicher sequentiell ansprichst, dann holt sie zukünftige Daten schon im Voraus (prefetch). Aber es stimmt, wenn du mit Arrays kämpfst, die grösser sind als die Caches, dann spielt der Zugriff auf das RAM eine bedeutende Rolle und es kann neben dem erwähnten automatischen Prefetch wichtig werden, dem Zugriff mit explizit programmierten Prefetch-Befehlen und ebenso expliziter Cache-Kontrolle nachzuhelfen.
Mark .. schrieb: > Sebi2020 schrieb: >> Damit muss ich in jedem Takt den neuen >> Speicherwert aus dem Arbeitsspeicher holen. > > Nicht ganz. Caches speichern die Daten nicht Byte-weise, sondern > Block-weise ab. Sobald man also auf das erste Element zugegriffen hat, > hat man die darauffolgenden bereits auch im Cache. Naja, aber der Prozessor greift ja lesend trotztdem schneller auf die Cache zu als die Cache die Daten aus dem Speicher holen kann. Sprich während ich mit 1066 Mhz Daten aus dem Speicher hole versucht der Prozessor mit 3 Ghz Daten aus dem Cache zu holen, aber die Daten sind noch nicht im Cache, weil die Daten dort erst mal drinne stehen müssen.
Wer glaubt hier, daß eine moderne Intel-CPU einen Befehl in einem Takt abarbeitet ??? http://www.bernd-leitenberger.de/cisc-risc.shtml
Sebi2020 schrieb: > Naja, aber der Speichertakt bestimmte doch auch die Transferrate. Wenn > ich einen Takt von 1066 Mhz habe und eine Busbreite von 32Bit habe, kann > ich ja maximal (ca.) 1.000.000.000 * 4 Bytes pro Sekunde übertragen. Ein DIMM ist 64 Bits breit und dicke Prozessoren sprechen davon 4 Stück parallel bei 1600MHz an.
Bernd Rüter schrieb: > Wer glaubt hier, daß eine moderne Intel-CPU einen Befehl in einem Takt > abarbeitet ??? Hat das jemand behauptet? Aber bereits der AMD K5 war in der Lage, dauerhaft 4 x86-Befehle pro Takt auszuführen, d.h. sie erfolgreich zu beenden, auch wenn jeder Befehl davon mehrere Takte Laufzeit hatte. Zwischendurch schrumpfte das eine Weile zu 3, liegt aber seit Nehalem wieder bei 4.
Sebi2020 schrieb: > Naja, aber der Prozessor greift ja lesend trotztdem schneller auf die > Cache zu als die Cache die Daten aus dem Speicher holen kann. Ja klar, wie schon erwähnt sorgt der Cache nicht dafür, dass in jedem einzelnen Takt etwas ausgeführt werden kann, sondern lediglich dass die Ausführung schneller ist, als wenn es komplett ohne Cache wäre. Ein Wundermittel ist der Cache auch nicht, aber momentan haben wir halt nichts anderes, was eine derart hohe Speicherdichte aufweist wie DRAM und, müssen deshalb deshalb versuchen, die hohen Zugriffszeiten zumindest so weit wie möglich zu kompensieren. >Sprich > während ich mit 1066 Mhz Daten aus dem Speicher hole versucht der > Prozessor mit 3 Ghz Daten aus dem Cache zu holen, aber die Daten sind > noch nicht im Cache, weil die Daten dort erst mal drinne stehen müssen. Am Anfang. Sobald der Cache sich aber erstmal etwas gefüllt hat, werden die Misses immer seltener.
A. K. schrieb: > Bernd Rüter schrieb: >> Wer glaubt hier, daß eine moderne Intel-CPU einen Befehl in einem Takt >> abarbeitet ??? > > Hat das jemand behauptet? Aber bereits der AMD K5 war in der Lage, > dauerhaft 4 x86-Befehle pro Takt auszuführen, d.h. sie erfolgreich zu > beenden, auch wenn jeder Befehl davon mehrere Takte Laufzeit hatte. > Zwischendurch schrumpfte das eine Weile zu 3, liegt aber seit Nehalem > wieder bei 4. A. K. schrieb: > Sebi2020 schrieb: >> Naja, aber der Speichertakt bestimmte doch auch die Transferrate. Wenn >> ich einen Takt von 1066 Mhz habe und eine Busbreite von 32Bit habe, kann >> ich ja maximal (ca.) 1.000.000.000 * 4 Bytes pro Sekunde übertragen. > > Ein DIMM ist 64 Bits breit und dicke Prozessoren sprechen davon 4 Stück > parallel bei 1600MHz an. Mhs, wie soll das gehen wenn der Datenbus nur 32 Bit breit ist und der Adressbus 32 Bit bzw. heutzutage 64 Bit. 4 Befehle in 1 Takt obwohl sie mehrere Takte lang sind?! Dann hätte das ganze ja einen Asynchronen Anteil. Ich dachte Befehle werden nacheinander abgearbeitet, wenn nicht Multi-Core.
Die CPU ist auch in der Lage, Daten im voraus zu berechnen, ohne das Daten aus dem Speicher schon da sind. Bei Verzweigungen wird so z.B. an beiden Zweigen weiter gerechnet, bis die Daten in der CPU eingetroffen sind und dann werden die nicht benötigten Daten verworfen. Gruß Jobst
Sebastian T. schrieb: > Mhs, wie soll das gehen wenn der Datenbus nur 32 Bit breit ist und der > Adressbus 32 Bit bzw. heutzutage 64 Bit. > 4 Befehle in 1 Takt obwohl sie mehrere Takte lang sind?! Dann hätte das > ganze ja einen Asynchronen Anteil. Mit einem Takt werden 4 Datenschritte übertragen: - bei der steigenden Flanke des Taktes - bei Dachmitte - bei fallender Flanke - und bei Talmitte
1 | ___ |
2 | ___/ \___/ <--Takt |
3 | |
4 | | | | | | | <-- Daten |
Gruß Jobst
Jobst M. schrieb: > Die CPU ist auch in der Lage, Daten im voraus zu berechnen, ohne das > Daten aus dem Speicher schon da sind. Bei Verzweigungen wird so z.B. an > beiden Zweigen weiter gerechnet, bis die Daten in der CPU eingetroffen > sind und dann werden die nicht benötigten Daten verworfen. Bisschen missverständlich. Es kann sein, dass ein Befehl unter der Annahme ausgeführt wird, dass die Daten im Cache seien, und es wird dann mit dem gerechnet, was aus dem Cache kommt. Das Ergebnis wird verworfen, wenn sich ein paar Takte später diese Annahme als falsch herausstellt. CPUs, die gleichzeitig mehrere alternative Wege verfolgen können, sind nicht die Regel sondern die Ausnahme. Und bei x86 nicht anzutreffen.
Sebi2020 schrieb: > Hey, Hi, eins vorweg: du solltest wirklich mal in ein Buch über Rechnerarchitektur schauen. Kann gerne auch aus dem letzten Jahrtausend sein, an den Prinzipien hat sich wenig geändert seitdem. > ich hab mich mal gefragt, wie ein PC funktioniert, wenn der Speichertakt > ja meistens viel kleiner ist als der CPU Takt. Ich mein, bei jedem Takt > muss doch der Code aus dem Speicher bei x86 Architekturen geladen > werden. Nein. Gerade x86 braucht je nach Befehl oft deutlich mehr als einen Taktzyklus. > Sprich wenn ich ein 3 Ghz CPU, wie kann der Speicher dann auch > so schnell die Daten liefern, wenn der Speicher nur mit 1066 Mhz > arbeitet? Der Speicher "arbeitet" nicht "mit 1066MHz". Sei 1066MHz meinetwegen der Basistakt für das Speichertiming, dann kommt noch Overhead für die Adressierung (bei DRAM typisch zweistufig als Zeilen und Spalten) dazu. Außerdem gibt auch noch das Refresh. So ein Speicherzugriff kostet brutto gern mal 5-10 Takte des Speichertaktes. Andererseits wird der Hauptspeicher praktisch immer in Bursts gelesen. Und er ist mit einen deutlich breiteren Datenbus angebunden als die typische Befehlslänge. Und Speicher ist meist in mehreren Bänken organisiert, auf die der Speichercontroller parallel zugreifen kann. Und es gibt DDR. Vom Cache haben dir andere ja schon erzählt. Dein Denkfehler ist, daß Programme ja nicht komplett wahllos auf den Speicher zugreifen, sondern auf größere Blöcke (die dann in schnellen Bursts gelesen werden können). Außerdem gerne auf immer die gleichen Blöcke, die dann zwar beim ersten Mal nicht im Cache stehen, aber bei den folgenden Zugriffen sehr wohl. > Andererseits hab ich mir auch noch was überlegt. Wie eine CPU > den in 1 Takt ein Befehl ausführen kann? Theoretisch müsste sie dazu > doch intern mit einem noch schnelleren Takt arbeiten oder? Wieder daneben. Ein CPU-Kern muß nicht zwingend ein synchrones Design verwenden. Klassisches asynchrones Beispiel ist der 6502. Der braucht nur 2 Takte je Befehl. Krasses synchrones Gegenbeispiel ist der 8051, der mindestens 12 Takte braucht (und immer Vielfache von 12). > Ich mein wenn > ich mir überlege 1 Takt dafür die neue Instruktion aus dem Speicher > holen. 1 Takt für das ausführen der Instruktion. Macht man seit gut 20 Jahren nicht mehr so. Stichwort Pipelining. Deine Wissenslücken sind beängstigend. Schließe sie! Und nein, dieses Forum ist dafür kein geeignetes Medium. XL
Der Adress- und der Datenbus haben beide eine Breite, der Memoryzugriff ist was ganz anderes. Dazwischen steht die MMU, die Memory Management Unit. Der effektive Speicher kann 256 -384 Bit breit sein.
Jobst M. schrieb: > Mit einem Takt werden 4 Datenschritte übertragen: Schon, aber die Angabe von "1600MHz" rechnet das bereits mit ein. Getaktet werden sie tatsächlich mit 400MHz. Eine andere etwas hilfreicher Angabe davon ist deshalb PC3-12800 für DDR3 Speicher mit 12800 MB/sec.
Jobst M. schrieb: > Mit einem Takt werden 4 Datenschritte übertragen: > - bei der steigenden Flanke des Taktes > - bei Dachmitte > - bei fallender Flanke > - und bei Talmitte > ___ > ___/ \___/ <--Takt > > | | | | | | <-- Daten > > > > Gruß > > Jobst Wozu dann der langsame Takt. Um Datensicherheit zu gewährleisten etc. pp. könnte man gleich den 4 fachen Takt nehmen.
Sebastian T. schrieb: > Mhs, wie soll das gehen wenn der Datenbus nur 32 Bit breit ist und der > Adressbus 32 Bit bzw. heutzutage 64 Bit. > 4 Befehle in 1 Takt obwohl sie mehrere Takte lang sind?! Dann hätte das > ganze ja einen Asynchronen Anteil. Ich dachte Befehle werden > nacheinander abgearbeitet, wenn nicht Multi-Core. Auch wenn die Ausführung eines einzelnen Befehls an sich mehrere Takte dauern kann, kann die CPU trotzdem anfangen, den nächsten Befehl zu verarbeiten, obwohl der vorherige noch nicht komplett fertig ist. Sowas nennt man Pipelining, sihe http://de.wikipedia.org/wiki/Pipeline_(Prozessor) Dadurch verbraucht ein Befehl. u.U. im DURCHSCHNITT nur einen einzelnen Takt. Je nachdem wie die Befehle geordnet sind, kann es sogar vorkommen, dass sie tatsächlich parallel ausgeführt werden, auch auf einer Single-Core CPU. Moderne CPUs haben nämlich mehrere Versionen von Rechenpfaden pro Kern, und falls die CPU erkennt, dass die auszuführenden Befehle voneinander unabhängig sind, wie z.B. bei
1 | addl %eax, %ebx |
2 | addl %ecx, %edx |
werden diese auch gleichzeitig abgearbeitet.
Sebastian T. schrieb: > 4 Befehle in 1 Takt obwohl sie mehrere Takte lang sind?! Dann hätte das > ganze ja einen Asynchronen Anteil. Ich dachte Befehle werden > nacheinander abgearbeitet, wenn nicht Multi-Core. Nein. Schon anno Steinzeit hatten Befehle mehrere Phasen, beispielsweise Dekodieren Operand laden Ausführen Ergebnis speichern Wenn man diese Phasen überlappt, das sogenannte Pipelining, dann kann man pro Takt einen Befehl ausführen und es sind dabei jeweils 4 Befehle in unterschiedliche Phasen aktiv. Das hat natürlich auch wieder irgendwelche Haken. Wenn der Folgebefehle das Ergebnis vom Vorgänger in "Operand laden" benötigt", dann stockt diese Pipeline kurz.
Sebastian T. schrieb: > Wozu dann der langsame Takt. Um Datensicherheit zu gewährleisten etc. > pp. könnte man gleich den 4 fachen Takt nehmen. Es ist nicht so ganz einfach, einen 1,6GHz-Taktsignal fehlerfrei über ein Board und quer durch das Speichermodul zu ziehen. 400Mhz ist einfacher. Bedenke auch, dass ein 100MHz Takt zweimal pro Takt den Zustand wechselt, ein altes 100MHz Single-Data-Rate RAM aber nur einmal. Es war dieser Unterschied, der zunächst zum Double-Data-Rate RAM führte, bei dem die Datenleitungen die gleiche Änderungsrate hatten wie der Takt. Was die Verbindungstechnik verglichem mit einer Verdoppelung des Takts deutlich einfacher gestaltete.
Rechnerarchitektur ist einfach ein weites Feld. Was da heute tatsächlich in den Details gemacht wird ist schon krass. Gibts bei dir in der nähe eine Uni-Bib? Dann leih dir doch dort mal ein Buch zu dem Thema aus. gruß cyblord
Zwoelf von Siebzehn schrieb: > Der Adress- und der Datenbus haben beide eine Breite, der Memoryzugriff > ist was ganz anderes. Dazwischen steht die MMU, die Memory Management > Unit. Der effektive Speicher kann 256 -384 Bit breit sein. Eine Breite? Nop! Frühere CPUs hatten z.B. 32 Bit Datenbus und einen 21 Bit-Adressbus. Und das was von der MMU kommt musst du ja immer noch in den Datenbus quetschen. A. K. schrieb: > Sebastian T. schrieb: > Bedenke auch, dass ein 100MHz Takt zweimal pro Takt den Zustand > wechselt, ein altes 100MHz Single-Data-Rate RAM aber nur einmal. Es war > dieser Unterschied, der zunächst zum Double-Data-Rate RAM führte, bei > dem die Datenleitungen die gleiche Änderungsrate hatten wie der Takt. > Was die Verbindungstechnik verglichem mit einer Verdoppelung des Takts > deutlich einfacher gestaltete. Was verstehst du den Unterzustandswechsel? Wenn du 2 mal pro takt den Zustand wechselst hast du schon automatisch den Takt * 2. Das wäre schon ein doppelter Takt. ____ / \______/ 1 x Facher Takt 1 Zustandswechsel _ __ / \___/ \__/ 2 x Facher Takt 2 Zustandswechsel
Sebastian T. schrieb: > Mhs, wie soll das gehen wenn der Datenbus nur 32 Bit breit ist und der > Adressbus 32 Bit bzw. heutzutage 64 Bit. Was man Anfängern in der Rechnerarchitektur beibringt ist das klassische Modell von einem Adressbus, einem Datenbus und einem Steuerbus. So sehen aktuelle CPUs allerdings schon lange nicht mehr aus, die sind viel viel komplizierter mit zig Bussen verschiedener Breite intern und teils recht exotisch anmutenden eher seriellen als parallelen Bussen extern. So erinnert der Aufbau normaler Mehrprozessor-Board mittlerweile eher an per Ethernet voll vernetzte einzelne Rechner mit je einem Prozessor als an das alte Modell eines einzelnen Busses mit mehreren Prozessoren dran.
Sebastian T. schrieb: > ______ > / \______/ 1 x Facher Takt 1 Zustandswechsel Ich sehe da zwei Zustandswechsel pro Takt. Einer rauf, einer runter.
1 | ______ |
2 | / \______/ |
1 x Facher Takt 1 Zustandswechsel
1 | __ ___ |
2 | / \___/ \__/ |
2 x Facher Takt 2 Zustandswechsel
A. K. schrieb: > Sebastian T. schrieb: >> ______ >> / \______/ 1 x Facher Takt 1 Zustandswechsel > > Ich sehe da zwei Zustandswechsel pro Takt. Einer rauf, einer runter. Das sind Flanken. Wenn du es so siehst ja.
A. K. schrieb: > Sebastian T. schrieb: >> Mhs, wie soll das gehen wenn der Datenbus nur 32 Bit breit ist und der >> Adressbus 32 Bit bzw. heutzutage 64 Bit. > > Was man Anfängern in der Rechnerarchitektur beibringt ist das klassische > Modell von einem Adressbus, einem Datenbus und einem Steuerbus. So sehen > aktuelle CPUs allerdings schon lange nicht mehr aus, die sind viel viel > komplizierter mit zig Bussen verschiedener Breite intern und teils recht > exotisch anmutenden eher seriellen als parallelen Bussen extern. > > So erinnert der Aufbau normaler Mehrprozessor-Board mittlerweile eher an > per Ethernet voll vernetzte einzelne Rechner mit je einem Prozessor als > an das alte Modell eines einzelnen Busses mit mehreren Prozessoren dran. Mhs, okay, dann bleibt mir wohl nichts anderes Übrig als mir mal nen Dicken Schmöcker über Rechenarchitektur zuzulegen. ^^
Sebastian T. schrieb: > Das sind Flanken. Wenn du es so siehst ja. Eine Flanke ist ein Zustandswechsel. Und bei alten Single-Data-Rate RAMs wechselten die Daten nur einmal pro Takt.
Sebastian T. schrieb: > Mhs, okay, dann bleibt mir wohl nichts anderes Übrig als mir mal nen > Dicken Schmöcker über Rechenarchitektur zuzulegen. ^^ Wobei du in den Standard-Schmökern altersbedingt die aktuellen Mikroachitekturen nicht finden wirst. Nur wiederum Grundlagen, diesmal aber neuere als du bisher kennst. Andererseits kannst du auch mal versuchen, dich durch die diversen Artikel bei Realworldtech zu kämpfen. David Kanter ist ein ausgewiesener Kenner der Materie. So beschreibt er in http://www.realworldtech.com/haswell-cpu das, was Intel Mitte 2013 rausbringen wird. Vieles wird nach "Bahnhof" klingen, aber zumindest kriegst du eine Ahnung davon, mit welcher Komplexität heute gearbeitet wird. Du solltest allerdings nicht gleich versuchen, das dort ebenfalls beschriebene Thema "Transactional Memory" zu verstehen. ;-)
A. K. schrieb: > Sebastian T. schrieb: >> Mhs, okay, dann bleibt mir wohl nichts anderes Übrig als mir mal nen >> Dicken Schmöcker über Rechenarchitektur zuzulegen. ^^ > > Wobei du in den Standard-Schmökern altersbedingt die aktuellen > Mikroachitekturen nicht finden wirst. Nur wiederum Grundlagen, diesmal > aber neuere als du bisher kennst. > > Andererseits kannst du auch mal versuchen, dich durch die diversen > Artikel bei Realworldtech zu kämpfen. David Kanter ist ein ausgewiesener > Kenner der Materie. So beschreibt er in > http://www.realworldtech.com/haswell-cpu > das, was Intel Mitte 2013 rausbringen wird. Vieles wird nach "Bahnhof" > klingen, aber zumindest kriegst du eine Ahnung davon, mit welcher > Komplexität heute gearbeitet wird. Naja, das hilft aber auch nich viel dem Verständnis und was mir noch eingefallen ist, sowas wie einen Adressbus, der 32 oder 64 Bit breit ist müsste es ja schon geben. Vielleicht auch nur sowas wie ein abstrakter Bus. Ich habe mal angefangen ein kleines Betriebssystem für die x86-Architektur zu schreiben und da musstest du um in den Protected Mode überhaupt zu kommen die 21. Adressleitung erst mal aktivieren. Am Anfang wenn der PC hochfährt bist du nämlich erst mal im Real-Mode.
Etwas einfacher als bei Realworldtech geht es bei Agner Fog und seiner Beschreibung der diversen real existierenden x86er zu: http://www.agner.org/optimize/microarchitecture.pdf
A. K. schrieb: > Etwas einfacher als bei Realworldtech geht es bei Agner Fog und seiner > Beschreibung der diversen real existierenden x86er zu: > http://www.agner.org/optimize/microarchitecture.pdf Kann man denn davon ausgehen, das früher Speichertakt und Systemtakt mal identisch waren?
Sebastian T. schrieb: > sowas wie einen Adressbus, der 32 oder 64 Bit breit ist > müsste es ja schon geben. Nur war der externe Adressbus vom AMD K7 nur noch 13 Bits breit. ;-) Und danach gab es überhaupt keinen klassischen Adressbus mehr. Heutige CPUs sprechen einerseits DRAMs direkt an, d.h. es gibt 2-4 Busse mit Speicheradressen und Daten direkt für die DRAMs. Und zur Peripherie geht es über mehr oder weniger serielle Paketverbindungen entfernt ähnlich CAN oder Ethernet.
Sebastian T. schrieb: > Kann man denn davon ausgehen, das früher Speichertakt und Systemtakt mal > identisch waren? Nicht wirklich, wenngleich das bei 6800/6502 Ende der 70er der Fall war. Andere CPUs dieser Ära benötigten 3-4 CPU-Takte pro Speicherzugriff, allerdings war die Taktfrequenz auch höher. Bis 386 war diese Relation ähnlich, ab 486 lief das auseinander.
A. K. schrieb: > Sebastian T. schrieb: >> Kann man denn davon ausgehen, das früher Speichertakt und Systemtakt mal >> identisch waren? > > Nicht wirklich, wenngleich das bei 6800/6502 Ende der 70er der Fall war. > Andere CPUs dieser Ära benötigten 3-4 CPU-Takte pro Speicherzugriff, > allerdings war die Taktfrequenz auch höher. Bis 386 war diese Relation > ähnlich, ab 486 lief das auseinander. Mhs okay, ich dachte mir nur, das wäre der Einfachheit halber so gewesen. Schließlich hatten frühere CPUs Taktfrequenzen von ein paar Mhz.
Der iAPX 8086 resp 8088 hatte Clock/4, wurde mit 4.77MHz geclockt und hat daher etwas mehr als 1 MIPS gebracht. Als CISK prozessor wurde relativ viel als Mikrocode ausgefuehrt. Ein For Loop war daher lade CX label irgendwas Loop (CX-NZ) label Mit 4 Befehlen erledigt. Ist daher nicht mit den AVR oder so vergleichbar.
Was ihr bei eueren ganzen Erklärungen total vergesst (oder ich überlesen habe): Kein in der Praxis vorkommendes Programm liest die ganze Zeit nur Daten. Nur lesen um es dann gleich zu verwerfen macht einfach keinen Sinn. Normalerweise rechnet man auch noch damit. Und während der Ausführung dieser Befehle werden automatisch schon die nächsten Daten angefordert. Sobald die Daten mal in einem Register sind, kann der Prozessor wirklich in jedem Takt damit rechnen. Zum Teil sind die Register aus Geschwindigkeitsgründen intern sogar mehrfach ausgeführt. Würde man wirklich nur sequentiell lesen und zwar mit jedem einzelnen Befehl, so kann man prinzipbedingt nicht schneller Befehle ausführen als es die Speicherbandbreite erlaubt. Update: Ich hoffe es hat noch niemand was ähnliches geschrieben, mein Internetzugang wollte die letzte Stunde nicht so wie ich wollte.
R2 D2 schrieb: > Würde man wirklich nur sequentiell lesen und zwar mit jedem einzelnen > Befehl, so kann man prinzipbedingt nicht schneller Befehle ausführen als > es die Speicherbandbreite erlaubt. > > Update: Ich hoffe es hat noch niemand was ähnliches geschrieben, mein > Internetzugang wollte die letzte Stunde nicht so wie ich wollte. Naja, ein gutes Beispiel ist aber z.B. der Datentransfer. Als Beispiel, Daten vom Arbeitsspeicher sequentiel vom Arbeitsspeicher auf die Festplatte schreiben. Aber dann hat man natürlich sowieso die Festplatte die sowieso alles ausbremst.
Zwoelf von Siebzehn schrieb: > Der iAPX 8086 resp 8088 hatte Clock/4, wurde mit 4.77MHz geclockt und > hat daher etwas mehr als 1 MIPS gebracht. Als CISK prozessor wurde > relativ viel als Mikrocode ausgefuehrt. Ein For Loop war daher > > lade CX > label > irgendwas > Loop (CX-NZ) label > > Mit 4 Befehlen erledigt. Ist daher nicht mit den AVR oder so > vergleichbar. Heißt aber der 8086 und 8088 hat auch schon den Code in einem Takt geladen und ausgeführt? Ich überlege, weil ich ja auch irgendwie ein Rechenwerk steuern muss, sprich Mikrocode. Ich denke der ist dafür zuständig gerade dies zu erledigen. Also sprich Instruktion laden und ausführen. Was aber bedeuten muss, das dies mit höherem Takt geschieht als der Takt mit dem Programminstruktionen ausgeführt werden.
Sebastian T. schrieb: > Naja, ein gutes Beispiel ist aber z.B. der Datentransfer. Als Beispiel, > Daten vom Arbeitsspeicher sequentiel vom Arbeitsspeicher auf die > Festplatte schreiben. Mach lieber nicht noch ein Fass auf, die CPU ist schon komplex genug. Mit diesem Transfer hat die CPU nämlich nichts zu tun, die Plattendaten landen ohne ihr Zutun vom Speicher auf der Disk.
Sebastian T. schrieb: > Heißt aber der 8086 und 8088 hat auch schon den Code in einem Takt > geladen und ausgeführt? Nein. Und in einem Takt geladen und ausgeführt hat noch nie eine CPU einen Befehl. Auch wenn manche unter dem Strich pro Takt einen oder mehrere Befehle durchziehen brauchen auch einfachste Befehle dafür weit mehr als 10 Takte insgesamt. > Ich überlege, weil ich ja auch irgendwie ein > Rechenwerk steuern muss, sprich Mikrocode. Ich denke der ist dafür > zuständig gerade dies zu erledigen. Anno 8086 ja. Heute nicht mehr. Auch die 6502 hat m.W. keinen Microcode verwendet. Dafür gabs in der 68000 gleich 2 Ebenen von Microcode. Mikrocode wird heute nur noch verwendet, wenn Befehle sich in mehr als 4 interne Microops übersetzen (Intel). Kürzere werden direkt in Hardware dekodiert, ohne Microcode. Was danach geschieht ist unabhängig von der Art der Dekodierung. Und lass superkomplexe Befehle wie Blockmoves erst einmal aus der Betrachtung weg. Ist schon interessant genug, was bei einem einfachen ADD EAX,EAX abgeht.
R2 D2 schrieb: > Zum Teil sind die Register aus > Geschwindigkeitsgründen intern sogar mehrfach ausgeführt. Falls du auf die Replikation zweier Registerblöcke eines nicht mehr ganz so frischen DEC Alpha Prozessors anspielst: Das ist mir danach nie wieder begegnet, zumindest wurde es nicht erwähnt. Allerdings haben die internen Register und das, was der Programmierer kennt, nicht mehr sonderlich viel miteinander zu tun. So gibt es in der aktuellen Generation kein festes AX Register mehr, sondern nur noch ein Register, das frisch dekodierten Befehlen mitteilt, in welchem Register AX grad zu finden ist oder irgendwann zu finden sein wird. Und ein zweites Register, das besagt, in welchem Register der zuletzt endgültig berechnete Wert von AX liegt. Was auch bedeuten kann, dass es gleichzeitig 10 Register geben kann, den grad AX zugeordnet ist, eines endgültig, die anderen als Resultat von noch nicht abgeschlossenen Befehlen.
A. K. schrieb: > Sebastian T. schrieb: >> Heißt aber der 8086 und 8088 hat auch schon den Code in einem Takt >> geladen und ausgeführt? > > Nein. Und in einem Takt geladen und ausgeführt hat noch nie eine CPU > einen Befehl. Auch wenn manche unter dem Strich pro Takt einen oder > mehrere Befehle durchziehen brauchen auch einfachste Befehle dafür weit > mehr als 10 Takte insgesamt. > >> Ich überlege, weil ich ja auch irgendwie ein >> Rechenwerk steuern muss, sprich Mikrocode. Ich denke der ist dafür >> zuständig gerade dies zu erledigen. > > Anno 8086 ja. Heute nicht mehr. Auch die 6502 hat m.W. keinen Microcode > verwendet. Dafür gabs in der 68000 gleich 2 Ebenen von Microcode. > > Mikrocode wird heute nur noch verwendet, wenn Befehle sich in mehr als 4 > interne Microops übersetzen (Intel). Kürzere werden direkt in Hardware > dekodiert, ohne Microcode. Was danach geschieht ist unabhängig von der > Art der Dekodierung. > > Und lass superkomplexe Befehle wie Blockmoves erst einmal aus der > Betrachtung weg. Ist schon interessant genug, was bei einem einfachen > ADD EAX,EAX abgeht. Mhs, naja, was daran so besonders? Das ganze zur ALU, dort zum Addierer, und das Ergebnis zurück nach EAX schreiben. Und sowas meine ich z.B. mit Mikrocode, als beispiel beim Befehl ADD EBX, EAX Ich mein, da sind auch mehrere Schritte nötig z.B. Daten in Addierregister laden. Ergebnis zurückschreiben etc. > Nein. Und in einem Takt geladen und ausgeführt hat noch nie eine CPU Also vorhin wurde das behauptet, das eine Instruction gleichzeitig aus dem Speicher geladen und ausgeführt wird in einem Takt, wo ich der meinung war, das man min. 1 Takt erst mal braucht um nur die Instruction zu fetchen.
Sebastian T. schrieb: > Mhs, naja, was daran so besonders? Das ganze zur ALU, dort zum Addierer, > und das Ergebnis zurück nach EAX schreiben. Das ist die Version von klein Fritzchen. Die reale sieht anders aus. Ich versuch mal eine immer noch vereinfachte Kurzfassung eines nicht vollständigen und keinem realen Prozessor genau entsprechenden Modells. Die diversen Schritte vor der Dekodierung lass ich zur Vereinfachung mal weg. Und um die Verwirrung zu reduzieren betrachte ich den Befehl ADD EAX,EDX (1) Decode: Befehl wird dekodiert zu Ziel(EAX) = Quelle1(EAX) + Quelle2(EDX) (2) Rename: Reale Register werden der Operation zugeordnet: Bisher war EAX dem Register R14 zugeordnet. Bisher war EDX dem Register R6 zugeordnet. Ein freies Register wird gesucht, das sei nun R25. Die Operation heisst von nun an: Ziel(R25) = Quelle1(R14) + Quelle2(R6) Nun ist das aktuelle EAX dem Register R25 zugeordnet, aber noch ohne Inhalt. (3) Dispatch: Die Operation wird in (a) den sequentiellen Reorder Buffer geschrieben damit man den Überblick behält, (b) eine Reservation Station für Integer-Rechnung geschrieben, damit die Operation irgendwann ausgeführt wird. (4) Schedule: Diese Reservation Station überprüft ob (a) Quelle1(R14) bereits zur Verfügung steht, oder im nächsten Takt als Result einer ALU- oder Ladeoperation aufkreuzen wird, (b) Quelle2(R6) bereits zur Verfügung steht, oder im nächsten Takt als Result einer ALU- oder Ladeoperation aufkreuzen wird, (c) im übernächsten Takt eine ALU zur Verfügung steht. Treffen (a)..(c) zu, dann wird der Befehl der ALU zugeordnet. Andernfalls wiederholt sich das gleiche Spiel im nächsten Takt. (5) Register Read: Wenn (4) erfolgreich verlief, dann werden die beiden Quelloperanden (a) entweder aus dem Registerfile gelesen, (b) oder es wird eine Verbindung vom Result-Bus einer grad laufenden Operation und dem entsprechenden Operandenbus der ALU vorbereitet. (6) Execute: Nun wird addiert. Das Resultat landet (a) auf dem Weg nach R25, (b) auf einem Result-Bus, von dem Operationen, die auf R25 aka EAX warten, es runterfischen können. Dem Reorder Buffer wird signalisiert, dass die Sache durch ist. Die Operation fliegt aus der Reservation Station raus, weil erledigt. Danach passiert u.U. erst einmal nichts, bis diese Operation die älteste noch nicht endgültig abeschlossene Operation ist. Es kann ja sein, dass Befehle, die vor dem ADD Befehl standen, mangels Operanden noch nicht ausgeführt wurden und man will doch gerne die korrekte Reihenfolge einhalten. (8) Retirement: Der ADD-Befehl ist nun der älteste Befehl im Reorder Buffer und wird endgültig abgeschlossen. Darin wird festgelegt dass (a) das bisher im Architecture State EAX zugeordnete Register nicht mehr verwendet wird und für (2) zur Verfügung steht. (a) der Architecture State von EAX nun in R25 liegt, Ging irgendwas schief, beispielsweise weil ein Divisionsbefehl vor dem ADD durch 0 dividierte oder eine Sprungvorhersage fehlschlug, dann findet das Retirement nicht statt und der Architecture State bleibt unverändert. Was bedeutet, dass der ADD Befehl keinerlei Auswirkung hat.
A. K. schrieb: > (8) Retirement: Der ADD-Befehl ist nun der älteste Befehl im > Reorder Buffer und wird endgültig abgeschlossen. > Darin wird festgelegt dass > (a) das bisher im Architecture State EAX zugeordnete Register > nicht mehr verwendet wird und für (2) zur Verfügung steht. > (a) der Architecture State von EAX nun in R25 liegt, > > Ging irgendwas schief, beispielsweise weil ein Divisionsbefehl > vor dem ADD durch 0 dividierte oder eine Sprungvorhersage > fehlschlug, dann findet das Retirement nicht statt und der > Architecture State bleibt unverändert. Was bedeutet, dass der > ADD Befehl keinerlei Auswirkung hat. Is ja sehr Abenteuerlich ... und das alles ohne Mikrocode hmms, okay :)
Sebastian T. schrieb: > Also vorhin wurde das behauptet, das eine Instruction gleichzeitig aus > dem Speicher geladen und ausgeführt wird in einem Takt, Nö. Es gibt gleichzeitig Befehle: - deren Code-Bytes gerade geladen werden, - die gerade dekodiert werden, - die gerade ausgeführt werden. Aber das sind alles verschiedene Befehle in unterschiedlichen Phasen. CPUs können weit über 100 Operationen gleichzeitig in ihren verschiedensten Phasen beinhalten. Und davon pro Takt bis zu 4 durchsetzen, wenn keine Blockierungen und Abhängigkeiten stören.
Als Spass am Rande: Bereits um 1970 herum wurden CPUs gebaut, die über Elemente des vorhin beschriebene Ausführungsmodell verfügten, wie die IBM 360/91 und die CDC 7600. Und das im Fall der CDC völlig ohne ICs, nur mit Einzeltransistoren in 60 Bits Breite.
A. K. schrieb: > Als Spass am Rande: Bereits um 1970 herum wurden CPUs gebaut, die über > Elemente des vorhin beschriebene Ausführungsmodell verfügten, wie die > IBM 360/91 und die CDC 7600. Und das im Fall der CDC völlig ohne ICs, > nur mit Einzeltransistoren in 60 Bits Breite. Pah, heute wird auf Integration und damit auch mit Minituralisierung geachtet und der hat sich wirklich jemand die mühe gemacht son Kram diskret zu bauen, der wahrscheinlich auch noch ineffizienter als die integrierte Lösung ist? tzz... :P
Hätten doch mit FPGAs arbeiten sollen. Oder wenigstens Custom-Chips mit Milliarden Transistoren in 22nm Technik. Welche Trottel! ;-) Seymour Cray (u.A.) hat diese CDCs nicht deshalb diskret gebaut, weil er blöd war oder Vorliebe für Ineffizienz hatte. Tatsächlich waren die CDCs 6600 und 7600 in ihrer Zeit die klar schnellsten Computer überhaupt. Nur war die Auswahl an verfügbaren ICs zum Zeitpunkt der Entscheidung der viele Jahre dauernden Entwicklung äusserst überschaubar und eine Bindung an die ersten teilweise noch recht wackligen IC-Reihen ein hohes wirtschaftliches Risiko. Es sei denn, man baute auch die ICs selbst und hatte die Resourcen dafür, wie IBM.
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.