64 bit und second level cache?

[mapel110]

Wird bei 64bit-Anwendungen der Vorteil von mehr Second Level Cache grösser, oder hat das keine Auswirkungen?

[Coda]

Theoretisch braucht 64-bit Code mehr Speicher (größerer Code & Pointer), aber ich denke nicht dass es sich da viel anders verhällt als im 32-bit Modus.

[GloomY]

Wird bei 64bit-Anwendungen der Vorteil von mehr Second Level Cache grösser, oder hat das keine Auswirkungen?Was ändert sich denn im 64 Bit Modus vergleichen zum 32 Bit Modus? Wie Coda richtig erwähnte, ist die Codierung der Befehle anders. Aufgrund des zusätzlichen Präfixes, welcher die 64 Bit Befehle identifiziert, wird hier etwas mehr Platz verbraucht.
Bei den Daten ändert sich bis auf die Pointer, die von 32 auf 64 Bit anwachsen, rein gar nichts. Die meisten Daten sind aber wirklich Daten ;) und keine Pointer, also dürfte auch hier der Anstieg recht klein sein.

DEC hat beim Umstieg von ihrer 32 Bit VAX auf die 64 Bit Alpha von etwa 5% mehr Platz gesprochen, welcher bei 64 Bit bei den Daten entsteht.

Alles in Allem dürfte sich hier sehr wenig ändern. Die meisten Zugriffe auf den L2 kommen eh vom L1-D Cache und nicht vom L1-I. Letzterer hat - besonders beim Athlon mit seinem großen 64 kiB - eine recht gute Hit-rate.

[mapel110]

Was ändert sich denn im 64 Bit Modus vergleichen zum 32 Bit Modus? Wie Coda richtig erwähnte, ist die Codierung der Befehle anders. Aufgrund des zusätzlichen Präfixes, welcher die 64 Bit Befehle identifiziert, wird hier etwas mehr Platz verbraucht.
Bei den Daten ändert sich bis auf die Pointer, die von 32 auf 64 Bit anwachsen, rein gar nichts. Die meisten Daten sind aber wirklich Daten ;) und keine Pointer, also dürfte auch hier der Anstieg recht klein sein.

DEC hat beim Umstieg von ihrer 32 Bit VAX auf die 64 Bit Alpha von etwa 5% mehr Platz gesprochen, welcher bei 64 Bit bei den Daten entsteht.

Alles in Allem dürfte sich hier sehr wenig ändern. Die meisten Zugriffe auf den L2 kommen eh vom L1-D Cache und nicht vom L1-I. Letzterer hat - besonders beim Athlon mit seinem großen 64 kiB - eine recht gute Hit-rate.

thx =)
was wären wir ohne dich?!

[GloomY]

thx =)
was wären wir ohne dich?!Ach, gibt ja auch andere kompetente Leute hier auf dem Board...

Noch mal eine zusätzliche Anmerkung zu oben:
Wenn die Datenmengen steigen, fällt vor allem die L1-D Hitrate, während die L1-I Hitrate davon quasie nicht beeinflusst wird. Das habe ich auch per Cache-Simulation mit SimpleScalar (http://www.simplescalar.com/overview.html) bestätigt bekommen. Hierbei wurde ein einfaches Programm zur Matrix-Multiplikation genommen. Bei Matrix-Größen von 10x10 liegen die Hitrates von L1-I bei 89% und die des L1-D bei 92% (jeweils 2 kiB Cache, direct-mapped, 16 Byte Line Size).
Bei einer größeren Matrix (225x225) sinkt die Hitrate des L1-D stark ab auf 36%, während die des L1-I weiterhin sehr gut bleibt (sogar noch auf 99% steigt).
Mit einem entsprechend größeren L2 Cache (256 kiB, direct-mapped, 64 Byte Line Size) kann man dann die niedrige Hit-Rate des L1-D wieder abfangen :)

[Stone2001]

@GloomY:
Noch einer der sich mit SimpleScalar auseinander setzen darf! ;)

Die Daten, die du von sim-cache erhältst, sind extrem vom Programm abhängig. Für mein Programm, bekomme ich völlig andere Werte. Die Caches sind die gleichen wie bei dir, aber mein Programm braucht insgesamt ca. 1.2 Millarden Instruktionen. Kompiliert wurde es mit dem Cross-Compiler für die PISA-Architektur ohne weitere Optionen. (mit -O3 bekommt man recht beindruckende Werte)
Bei 10x10-Matrizen habe ich Hit-Raten von 98,2% beim L1-I, 95,7% bei L1-D und rund 85% beim L2-Cache.
Bei 225x225 sieht die Welt etwas anders aus, da habe ich eine Hit-Rate von 99,9% beim L1-I, 91,8% beim L1-D und 99,3% beim L2-Cache!

Anmerkung: Zumindest die von mir geposteten Werte tragen recht wenig zum Thema bei, da die PISA-Architektur eine 64bit Architektur ist. Genauer gesagt eine 64bit-RISC-Architektur mit 64bit Befehlswörtern. Aber auch meine Versuche bestätigen GloomYs Aussage, das die meisten Zugriffe auf den L2-Cache von den Daten her kommen.

[GloomY]

@GloomY:
Noch einer der sich mit SimpleScalar auseinander setzen darf! ;)Hehe, ist ja ziemlich interessant. Du machst nicht zufällig gerade auch das Praktikum Prozessorevaluierung und -entwurf mit SimpleScalar (http://www.ira.uka.de/I3V_HTML/VERANSTALTUNGEN/01219635.htm)? Das wäre ja echt mal ein Zufall...

edit: Muss ja fast so sein: Ansonsten frage ich mich, wie du auf das 10x10 und 225x225 Programm kommst ;)

Die Welt ist manchmal wirklich klein... :O
@GloomY:
Die Daten, die du von sim-cache erhältst, sind extrem vom Programm abhängig. Für mein Programm, bekomme ich völlig andere Werte.Kann durchaus sein.
Die Caches sind die gleichen wie bei dir, aber mein Programm braucht insgesamt ca. 1.2 Millarden Instruktionen. Kompiliert wurde es mit dem Cross-Compiler für die PISA-Architektur ohne weitere Optionen. (mit -O3 bekommt man recht beindruckende Werte)Bei mir ebenfalls. Ich kann ja morgen mal mein Programm hier posten, falls Interesse besteht.
Bei 10x10-Matrizen habe ich Hit-Raten von 98,2% beim L1-I, 95,7% bei L1-D und rund 85% beim L2-Cache.Die L1-I Hitrate scheint mir etwas hoch bei so wenig ausgeführten Befehlen (10x10 Matrix geht ja ganz flott zu berechnen). Die Anzahl der Compulsory-Misses müsste daher eigentlich relativ zur Gesamtanzahl der Befehle einigermaßen hoch liegen.
Bei 225x225 sieht die Welt etwas anders aus, da habe ich eine Hit-Rate von 99,9% beim L1-I, 91,8% beim L1-D und 99,3% beim L2-Cache!Ist ja mal sehr interessant. Hier habe ich wie gesagt weitaus niedrigere Werte. Vielleicht kannst du mal dein Programm hier posten, dann können wir vergleichen :)

99,2% beim L2 ist auch ziemlich gut, wenn man bedenkt, dass es immerhin ein direct-mapped Cache ist, also die Konfliktanzahl eigentlich eher hoch sein sollte.
edit: Blödsinn, ist bei mir ja genau so... :|

[Stone2001]

Hehe, ist ja ziemlich interessant. Du machst nicht zufällig gerade auch das Praktikum Prozessorevaluierung und -entwurf mit SimpleScalar (http://www.ira.uka.de/I3V_HTML/VERANSTALTUNGEN/01219635.htm)? Das wäre ja echt mal ein Zufall...

edit: Muss ja fast so sein: Ansonsten frage ich mich, wie du auf das 10x10 und 225x225 Programm kommst ;)

Die Welt ist manchmal wirklich klein... :O[QUOTE=GloomY]
Aye! ;)
[QUOTE=GloomY]
Bei mir ebenfalls. Ich kann ja morgen mal mein Programm hier posten, falls Interesse besteht.
Wäre nicht schlecht. ;)

Die L1-I Hitrate scheint mir etwas hoch bei so wenig ausgeführten Befehlen (10x10 Matrix geht ja ganz flott zu berechnen). Die Anzahl der Compulsory-Misses müsste daher eigentlich relativ zur Gesamtanzahl der Befehle einigermaßen hoch liegen.
hmm, bei 10x10 werden 82297 Instruktionen ausgeführt, davon werden nur 1500 nicht im Cache gefunden, das ergibt eine Miss-Rate von 0,0182. Die Anzahl der Compulsory-Misses dürfte wohl in der Gegend von 650 sein.

Ist ja mal sehr interessant. Hier habe ich wie gesagt weitaus niedrigere Werte. Vielleicht kannst du mal dein Programm hier posten, dann können wir vergleichen :)
Siehe Anhang
matrix.txt ist das C-Programm. matrix10 und matrix225 die Ergebnisse der jeweiligen Simulationsläufe!

[Gabber[CH]]

Bei reinem 64 Bit Code müssten doch rein theoretisch doppelt so viele Daten anfallen oder?
Schon klar, (hoffentlich) keiner wird in ein paar Jahren einfach nur mit 64 Bit rechnen, aber nehmen wir mal an einer würde das machen.

[GloomY]

@Stone2001:

Sorry, ich war die letzten paar Tage nicht online, daher konnte ich nichts posten. Dein Programm sieht sonst ganz gut aus, ich habe die Arrays jedoch dynamisch alloziert (mit malloc). Vielleicht liegt's daran...

Ich poste das Programm, sobald ich es kann (bin momentan nicht zu Hause).
']Bei reinem 64 Bit Code müssten doch rein theoretisch doppelt so viele Daten anfallen oder?
Schon klar, (hoffentlich) keiner wird in ein paar Jahren einfach nur mit 64 Bit rechnen, aber nehmen wir mal an einer würde das machen.Bei Floating Point wird selbst bei 32 Bit Rechnern schon mit 64 / 80 Bit gerechnet. Da ändert sich gar nichts.

Bei Integer Code kann man ja immer noch 32 bit Datentypen verwenden, wenn man eben nur 32 Bit benötigt und keine 64. Spezielle Datentypen wie Strings, Structs oder Arrays haben ja eh ganz andere Größen als die neue "Standardgröße 64 Bit".
Pointer werden natürlich von 32 auf 64 Bit vergrößert, schliesslich will man die Fähigkeit 64 Bit zu adressieren auch nutzen ;)

Daher ändert sich nicht zwingend etwas an den Datenmengen. Es kommt sicherlich auf den Anwendungsfall an. Im Schnitt wird es aber wohl eher relativ wenig sein...

[Gabber[CH]]

64 Bit heisst aber für mich nicht nur den Addressbereich vergrösserrn ..
Klar da wird nicht viel zusätzliches Gemüse entstehen ..

Damt man aber was von den 64 Bit hat, ausser dem erweiterten Adressbereich (und ich hoffe es geht noch laange bis ein Spiel / Desktop App 4 GB frisst ...) müssen die Daten selbst auf 64 Bit anwachsen, was dann zu 2x Speicherverbrauch führt.

[BlackBirdSR]

']64 Bit heisst aber für mich nicht nur den Addressbereich vergrösserrn ..
Klar da wird nicht viel zusätzliches Gemüse entstehen ..

Damt man aber was von den 64 Bit hat, ausser dem erweiterten Adressbereich (und ich hoffe es geht noch laange bis ein Spiel / Desktop App 4 GB frisst ...) müssen die Daten selbst auf 64 Bit anwachsen, was dann zu 2x Speicherverbrauch führt.

2x Speicherverbrauch bei Integerwerten.
FP-Werte bleiben auch weiterhin bei 32/64Bit. Wie schon vor dem K8

Allerdings musst du das auch von der Programmiererseite sehen.
Warum sollte man einen 64Bit Wert nutzen, wenn man nur 8Bit benötigt?
Warum einen 64Bit Wert, wenn man nur 32Bit benötigt?
Man kann mit 64Bit Integern mehr machen.. aber nur wenn man sie auch braucht. Nur weil man alles mal eben schnell auf 64Bit aufbläht, gewinnt man kaum performance.
Somit stehen am Ende mit nichten 2x Speicherverbrauch. Bei Weitem nicht.

64Bit heisst momentan für mich
Mittelfrisitg 40Bit Adressraum.
Doppelte Anzahl an GPR/SSE2 Registern.

Gerade die Sache mit den verdoppelten Registern ist vorerst einer der Hauptgründe einmal einen Blick auf AMD64 zu werfen.

[GloomY]

Stone2001,

Du hast bei deinem Matrix-Programm "MAX" auf 250 statt auf 225 gesetzt. Vielleicht ist das mit ein Grund, warum du weitaus mehr Befehle in deinem Programm drinnen hast. Ansonsten kann ich nur spekulieren, warum du das 6-fache an Befehlen ausführst als "wir" (Laurent und ich). Mit "-O3" könntest du Recht haben, denn ich weiss nicht, was Laurent für CFLAGS normalerweise verwendet. Diese gelten doch global und damit auch für den Cross-compiler für PISA, oder?

btw: Deine Simulationsgeschwindigkeit ist mit 5,7 MIPS auch nicht gerade niedrig. War das dein AthlonXP @ 2200 MHz? Unser Duron 900 MHz schafft nur ca. 1,5 MIPS...

[Stone2001]

Stone2001,

Du hast bei deinem Matrix-Programm "MAX" auf 250 statt auf 225 gesetzt. Vielleicht ist das mit ein Grund, warum du weitaus mehr Befehle in deinem Programm drinnen hast. Ansonsten kann ich nur spekulieren, warum du das 6-fache an Befehlen ausführst als "wir" (Laurent und ich). Mit "-O3" könntest du Recht haben, denn ich weiss nicht, was Laurent für CFLAGS normalerweise verwendet. Diese gelten doch global und damit auch für den Cross-compiler für PISA, oder?
hmm, ich muß mal nachschauen, welche Größe ich wirklich für meine Versuche verwendet habe. Werde ich gleich mal machen, aber ich bezweifle, das es einen Faktor von 6 ausmacht.
Der Cross Compiler wird bei mir zumindest nicht von meinen Globalen Flags beeinflusst. Zumindest bekomme ich, wenn ich mit "-O3" kompiliere beindruckende Werte bei den Simulation. ;)
UPDATE: Ich habe bei meinen Versuchen MAX auf 225 gestellt! Also bleibt es bei den 1.2 Mrd. Instruktionen. Wenn ich mit O3 mein Programm kompiliere, brauche ich nur noch 160 Mio. Instruktionen.

btw: Deine Simulationsgeschwindigkeit ist mit 5,7 MIPS auch nicht gerade niedrig. War das dein AthlonXP @ 2200 MHz? Unser Duron 900 MHz schafft nur ca. 1,5 MIPS...
Nicht ganz, der Athlon aus meiner Sig gehört zu großen Teilen jetzt meinem Bruder. Ich habe eine Athlon MP-System mit 2 Athlon 2400+! (also nur 200 MHz weniger, aber halt 133 MHz FSB). Damit kann ich bei größeren Simulationen zwei parallel laufen lassen, das hat auch was.
Die vielen Simulationen zu Teilaufgabe 5 habe ich größtenteils per Skript laufen lassen und habe Std-Error (darauf macht SimpleScalar die Ausgabe) in eine Datei umgelenkt. Dabei wird zwar nur ein Prozessor ausgelastet, aber wenn ein Prozessor belegt ist, stört mich das kaum. (Das SimpleScalar auch die Möglichkeit hat, die Ausgabe in eine Datei umzulenken habe ich erst später erfahren)