CPU & Speichertimings

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

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.

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.

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.

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.

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.