amd64 - aufklärung gewünscht
- Ersteller Treverer
- Erstellt am
in einem link von riknet auf ein amd-pdf fand sich etwas, was ich gerne näher erklärt hätte von leuten, die ahnung haben. der link:
http://www.hotchips.org/archive/hc14/hc14pres_pdf/26_x86-64_ISA_HC_v7.pdf
das zu diskutierende (shit tipperei):
* specInt 2000 code quality, 64bits vs. 32bits (using gcc 3.1.1)
- average instruction lenght increased to 3.8 from 3.4 bytes
- dynamic instruction count decreased by 10%
- dynamic load count decreased by 26%
number of loads forwarded from recent stores substantially reduced
- dynamic store count decreased by 36%
- back to bach register dependencies decreased by 10%
so, nun also zu den fragen. es geht ja augenscheinlich um die effektivität von x86-64 code.
"- average instruction lenght increased to 3.8 from 3.4 bytes". die code länge der befehle in diesem fall wächst also um knapp über 10%, wenn ich es richig verstehe. okay, viel weniger als bei ia64. dennoch beansprucht diese verlängerung platz im cache und bandbreite vom ram/cache zur cpu. ABER: da steht nun mal "instruction lenght". was ist mit den länge der zu verarbeitenden daten? bleibt die konstant? oder werden zb. 32 bit auf 64 aufgebläht. teilweise oder immer? oder hängt das von der intelligenz der programmierer/kompiler ab?
"- dynamic instruction count decreased by 10%
- dynamic load count decreased by 26%
...number of loads forwarded from recent stores substantially reduced
- dynamic store count decreased by 36%
- back to back register dependencies decreased by 10%"
was meint "dynamic? während der laufzeit eines programmes auftretend? sehe ich das richtig, daß gemeint ist mit ""- dynamic instruction count decreased by 10%", daß im 64bit modus zehn prozent weniger befehle verarbeitet werden müssen, um das gleiche ergebnis des programmes zu leisten?
und "- dynamic load count decreased by 26%" meint, es seien 26% weniger "nachlade"-operationen notwendig? vom ram? vom cache? und noch krasser: "- dynamic store count decreased by 36%" bedeutet entsprechend weniger speicheroperationen? und was heißt hier "number of loads forwarded from recent stores substantially reduced"? das da weitere reduzierungen hinzu kommen, die hier nicht beziffert werden konnten?
"back to back register dependencies decreased by 10%" sind das operationen, die notwendig sind, weil nicht genügend register vorhanden sind und diese reduzieren sich eben um 10%? wenn es sich verhält, wie stark beansprucht so ein "back to back register" eigentlich ram/cache bandbreite? einmal schreiben und einmal lesen mit jeweils 64bit/8 byte - und natürlich entsprechend langsam?
ich hatte eigentlich gedacht, unter 64bit sei mehr cache/ram-bandbreite zur cpu notwendig. das die zusätzlichen register dies dämpfen ist klar. aber soviel? kann es sein am ende, daß unter 64bit sogar weniger bandbreite notwendig ist? natürlich abhängig von dem programm, aber es geht ja auch um durchschnittswerte. also cracks: klärt uns dummys auf...
http://www.hotchips.org/archive/hc14/hc14pres_pdf/26_x86-64_ISA_HC_v7.pdf
das zu diskutierende (shit tipperei):
* specInt 2000 code quality, 64bits vs. 32bits (using gcc 3.1.1)
- average instruction lenght increased to 3.8 from 3.4 bytes
- dynamic instruction count decreased by 10%
- dynamic load count decreased by 26%
number of loads forwarded from recent stores substantially reduced
- dynamic store count decreased by 36%
- back to bach register dependencies decreased by 10%
so, nun also zu den fragen. es geht ja augenscheinlich um die effektivität von x86-64 code.
"- average instruction lenght increased to 3.8 from 3.4 bytes". die code länge der befehle in diesem fall wächst also um knapp über 10%, wenn ich es richig verstehe. okay, viel weniger als bei ia64. dennoch beansprucht diese verlängerung platz im cache und bandbreite vom ram/cache zur cpu. ABER: da steht nun mal "instruction lenght". was ist mit den länge der zu verarbeitenden daten? bleibt die konstant? oder werden zb. 32 bit auf 64 aufgebläht. teilweise oder immer? oder hängt das von der intelligenz der programmierer/kompiler ab?
"- dynamic instruction count decreased by 10%
- dynamic load count decreased by 26%
...number of loads forwarded from recent stores substantially reduced
- dynamic store count decreased by 36%
- back to back register dependencies decreased by 10%"
was meint "dynamic? während der laufzeit eines programmes auftretend? sehe ich das richtig, daß gemeint ist mit ""- dynamic instruction count decreased by 10%", daß im 64bit modus zehn prozent weniger befehle verarbeitet werden müssen, um das gleiche ergebnis des programmes zu leisten?
und "- dynamic load count decreased by 26%" meint, es seien 26% weniger "nachlade"-operationen notwendig? vom ram? vom cache? und noch krasser: "- dynamic store count decreased by 36%" bedeutet entsprechend weniger speicheroperationen? und was heißt hier "number of loads forwarded from recent stores substantially reduced"? das da weitere reduzierungen hinzu kommen, die hier nicht beziffert werden konnten?
"back to back register dependencies decreased by 10%" sind das operationen, die notwendig sind, weil nicht genügend register vorhanden sind und diese reduzieren sich eben um 10%? wenn es sich verhält, wie stark beansprucht so ein "back to back register" eigentlich ram/cache bandbreite? einmal schreiben und einmal lesen mit jeweils 64bit/8 byte - und natürlich entsprechend langsam?
ich hatte eigentlich gedacht, unter 64bit sei mehr cache/ram-bandbreite zur cpu notwendig. das die zusätzlichen register dies dämpfen ist klar. aber soviel? kann es sein am ende, daß unter 64bit sogar weniger bandbreite notwendig ist? natürlich abhängig von dem programm, aber es geht ja auch um durchschnittswerte. also cracks: klärt uns dummys auf...
rkinet
Grand Admiral Special
http://www.x86-secret.com/articles/cpu/k8-3/amd64-9.htm
Zumindest die Beispiel lt. Link belegen dies.
Zumindest die Beispiel lt. Link belegen dies.
@Treverer
decreased = reduziert = positiv/besser
Auf Seite 10 wird der Nutzen von den erweiterten Registern anschaulich gezeigt.
Frage mich bitte nicht, wie sie es schaffen solch ein Vergleich mit 6, 16, 32 und mehr als 32 Registern zu machen.
Aber das Diagramm zeigt den Zusatznutzen der verdoppelten Register.
Wozu sind denn eigentlich Register da?
Register sind extrem schnelle Zwischenspeicher für die Recheneinheiten des Prozessors. Genau dort spielt die Musik ... geht die Party ab, wenn heftig gerechnet wird.
Auch wenn x86 ab dem K5 P6 intern schon mehr interne Register hatte. Die Software kannte nach aussen hin nur einen sehr begrenzten Register-Raum.
RISC Architekuren wiesen schon sehr früh wesentlich mehr Register auf. Sie brauchten deswegen gar nicht so häufig auf den Level 1 Cache, L2 Cache zugreifen (dafür war der RISC-Code nicht so kompakt).
AMD zeigt auf Seite 10, dass eben dieser Nutzen voll durchschlägt. Es macht eben doch ein Unterschied aus, ob nun versteckt mehr Register vor sich hin werkeln, oder diese offen transparent für die Software vorliegen.
Man erkennt dass lediglich Ijepeg und Perl noch einen hohen Nutzen aus mehr Registern als 16 zieht. Aber schon bei 16 Registern sind diese Anwendungen nahe am Optimum.
SMT könnte da noch mehr den Badarf an Registern erhöhen, aber dies ist im Doku ja nicht drin. Es ist die Rede von einzelnen Programmen.
Einzelpunkte
RISC hat da ja eine nahezu vereinheitlichet Länge.
x86 mit seinem CISC- Ansatz hat dort ja erheblich extreme Unterschiede in der Bitelange ( 1-17? )
Dies ist eine gewisse Arbeitserleichterung für den "AMD64 CISC" Decoder. Intern wird ja eh in einem RISC-artigen Instruktionssatz gearbeitet (Stichwort Ops/Rops/Atom)
Nachteil ist demnach, dass die "Softwarekomprimierung" des CISC-Codes nicht mehr ganz so gross ist.
MFG Bokill
decreased = reduziert = positiv/besser
Auf Seite 10 wird der Nutzen von den erweiterten Registern anschaulich gezeigt.
Frage mich bitte nicht, wie sie es schaffen solch ein Vergleich mit 6, 16, 32 und mehr als 32 Registern zu machen.
Aber das Diagramm zeigt den Zusatznutzen der verdoppelten Register.
Wozu sind denn eigentlich Register da?
Register sind extrem schnelle Zwischenspeicher für die Recheneinheiten des Prozessors. Genau dort spielt die Musik ... geht die Party ab, wenn heftig gerechnet wird.
Auch wenn x86 ab dem K5 P6 intern schon mehr interne Register hatte. Die Software kannte nach aussen hin nur einen sehr begrenzten Register-Raum.
RISC Architekuren wiesen schon sehr früh wesentlich mehr Register auf. Sie brauchten deswegen gar nicht so häufig auf den Level 1 Cache, L2 Cache zugreifen (dafür war der RISC-Code nicht so kompakt).
AMD zeigt auf Seite 10, dass eben dieser Nutzen voll durchschlägt. Es macht eben doch ein Unterschied aus, ob nun versteckt mehr Register vor sich hin werkeln, oder diese offen transparent für die Software vorliegen.
Man erkennt dass lediglich Ijepeg und Perl noch einen hohen Nutzen aus mehr Registern als 16 zieht. Aber schon bei 16 Registern sind diese Anwendungen nahe am Optimum.
SMT könnte da noch mehr den Badarf an Registern erhöhen, aber dies ist im Doku ja nicht drin. Es ist die Rede von einzelnen Programmen.
Einzelpunkte
Könnte man so verstehen, dass das Entschlacken der ISA IA32 in AMD64 eine einheitlichere Bytelänge provoziert.
RISC hat da ja eine nahezu vereinheitlichet Länge.
x86 mit seinem CISC- Ansatz hat dort ja erheblich extreme Unterschiede in der Bitelange ( 1-17? )
Wenn die Register mehr zwischenspeichern können, so wird grundsätlich der Verkehr entlastet.
Ich verstehe die Aussage so, dass AMD den CISC Instruktionssatz RISC-ähnlicher gestaltet hat (einheitlicher)
Dies ist eine gewisse Arbeitserleichterung für den "AMD64 CISC" Decoder. Intern wird ja eh in einem RISC-artigen Instruktionssatz gearbeitet (Stichwort Ops/Rops/Atom)
Nachteil ist demnach, dass die "Softwarekomprimierung" des CISC-Codes nicht mehr ganz so gross ist.
Gewonnen wäre dafür eine höhere Übersichtlichkeit bei 64 Bit CISC-AMD64 Code und potentiell ein Leistungsfähigerer (weil vereinfacht) AMD64-Decoder.
MFG Bokill
Zuletzt bearbeitet:
NemesisTN
Vice Admiral Special
Hmm, Back to Back Register Dependencies sind wohl eher Abhängigkeiten statt Operationen.
Sprich:
Dank OoO-Execution hat ein moderner Prozessor alle Standard-Register (RAX..RDX usw.) mindestens so oft wie er Instruktionen gleichzeitig bearbeiten kann.
Schätze diese Register sind die Back-Register.
Wenn nun eine Instruktion von einer anderen, welche gleichzeitig abgearbeitet wird, abhängig ist, muss sie auf das Ergebnis eben dieser warten.
Dynamic meint in diesem Zusammenhang wohl Sprung-Instruktionen (JMP, Jcc, CALL usw.).
Eine Reduzierung dieser deutet auf verbesserte Sprungvorhersage hin.
Das sich die Instruction-Length nicht großartig ändert, liegt in der Natur der x86-Instruktionen.
Um die neuen Register anzusprechen ist ja nur ein neues Prefix nötig, das gibts aber auch schon um die Exx-Register anzusprechen.
Deswegen dürfte sich der 64bit-Code auch nur bei vielen Zeiger-Operationen stark vergrößern, da diese ja nun 64bittig sind.
Datenmäßig kommt es drauf an wie sie ausgerichtet werden müssen.
Aber seit dem PPro(?) werden eh viele Daten an 16Byte-Grenzen ausgerichtet.
Deswegen dürfte sich da auch nicht viel ändern.
Sprich:
Dank OoO-Execution hat ein moderner Prozessor alle Standard-Register (RAX..RDX usw.) mindestens so oft wie er Instruktionen gleichzeitig bearbeiten kann.
Schätze diese Register sind die Back-Register.
Wenn nun eine Instruktion von einer anderen, welche gleichzeitig abgearbeitet wird, abhängig ist, muss sie auf das Ergebnis eben dieser warten.
Dynamic meint in diesem Zusammenhang wohl Sprung-Instruktionen (JMP, Jcc, CALL usw.).
Eine Reduzierung dieser deutet auf verbesserte Sprungvorhersage hin.
Das sich die Instruction-Length nicht großartig ändert, liegt in der Natur der x86-Instruktionen.
Um die neuen Register anzusprechen ist ja nur ein neues Prefix nötig, das gibts aber auch schon um die Exx-Register anzusprechen.
Deswegen dürfte sich der 64bit-Code auch nur bei vielen Zeiger-Operationen stark vergrößern, da diese ja nun 64bittig sind.
Datenmäßig kommt es drauf an wie sie ausgerichtet werden müssen.
Aber seit dem PPro(?) werden eh viele Daten an 16Byte-Grenzen ausgerichtet.
Deswegen dürfte sich da auch nicht viel ändern.
rkinet
Grand Admiral Special
Ganz einfach:
- die Neuerungen (Register) gelten nur im 64 Bit-Modus
- SSE ist sowohl von 32 Bit, als auch 64 Bit Software 'gleichzeitig' nutzbar.
- im 64 Bit-Modus wurden einige redundante 8086er Anweisungen anders codiert und 1-Byte Präfixe ('REX') wurden verfügbar.
- Durch mehrere Tricks können Compiler den Sourcecode fast genauso in x86-64, wie x86 übersetzen.
- Betriebssystemaufrufe (incl. DirectX) erfolgen bei 8086ff durch spezielle Befehle, durch die für die 32 Bit Welt unsichtbar zwischen 64 Bit und 32 Bit gewechselt werden kann.
- im IA32e Modus laufen Teile der 64 Bit Einheiten für die 32 Bit Software unsichtbar mit.
Insgesamt war der Wechsel 16/20 Bit (Daten/Adressen) auf 32 Bit viel aufwendiger.
Win32 und Win64 haben das gleiche Design für die Programme/Programmierer.
NemesisTN
Vice Admiral Special
Das mit den Prefixen ist ja klar, Das die Neuerungen nur im 64bit- Mode benutze werden können auch.
Aber der alte 32bit ist der alte geblieben.
Wenn sie da was umgeändert hätten würde ned mal DOS drauf booten.
So war das eigentlich gemeint... =)
Aber der alte 32bit ist der alte geblieben.
Wenn sie da was umgeändert hätten würde ned mal DOS drauf booten.
So war das eigentlich gemeint... =)
@NemesisTN
Drum schrieb ich ja weiter unten...
Auf 32 Bit-Ebene haben sie ja nach aussen hin alles so belassen. Aber eben nicht auf der 64 Bit Ebene. Wird derzeit immer gerne ignoriert... aber könnte in ferner Zukunft noch ganz andere Möglickeiten bieten.
Man könnte ja auch MS mal fragen, ob sie nur sie alleine es waren, dass auf 64 bit-Ebene eben nicht mehr die FPU unterstützt wird in ihrem 64 Bit OS. Eine Antwort seitens MS erwarte ich naturgemäss nicht 8)
MFG Bokill
Drum schrieb ich ja weiter unten...
und...
...
Auf 32 Bit-Ebene haben sie ja nach aussen hin alles so belassen. Aber eben nicht auf der 64 Bit Ebene. Wird derzeit immer gerne ignoriert... aber könnte in ferner Zukunft noch ganz andere Möglickeiten bieten.
Man könnte ja auch MS mal fragen, ob sie nur sie alleine es waren, dass auf 64 bit-Ebene eben nicht mehr die FPU unterstützt wird in ihrem 64 Bit OS. Eine Antwort seitens MS erwarte ich naturgemäss nicht 8)
MFG Bokill
Zuletzt bearbeitet:
NemesisTN
Vice Admiral Special
Ahso.
Wie schon in dem anderem Thread beschrieben, ich bin heut ein wenig neben der Mütze, sorry.
Wegen der FPU und 64bit-Sache:
Schätze mal das nicht nur MS dran schuld ist, da SSE und Konsorten ja auch 128bit-Register unterstützen, welches ja nun größer/genauer ist als die 80bit der FP-Register.
Somit bleibt es dem Programmierer überlassen ob er lieber genau rechnen lässt (1x128bit), oder er mehr Geschwindigkeit auf Kosten der Genauigkeit haben will (2x64bit, 4x32bit, 8x16bit).
Schätze das wird von den Prozessorherstellern auch selbst mit forciert.
//edit:
Außerdem ist x87-Programmierung auf Assembler-Ebene ein "Pain-in-the-Ass".
Stichwort Stack...
Wie schon in dem anderem Thread beschrieben, ich bin heut ein wenig neben der Mütze, sorry.
Wegen der FPU und 64bit-Sache:
Schätze mal das nicht nur MS dran schuld ist, da SSE und Konsorten ja auch 128bit-Register unterstützen, welches ja nun größer/genauer ist als die 80bit der FP-Register.
Somit bleibt es dem Programmierer überlassen ob er lieber genau rechnen lässt (1x128bit), oder er mehr Geschwindigkeit auf Kosten der Genauigkeit haben will (2x64bit, 4x32bit, 8x16bit).
Schätze das wird von den Prozessorherstellern auch selbst mit forciert.
//edit:
Außerdem ist x87-Programmierung auf Assembler-Ebene ein "Pain-in-the-Ass".
Stichwort Stack...
was "increase" und "decrease" bedeutet, ist mir auch klar. LOL und seite zehn des pdf habe ich auch gelesen. das alles beantwortet aber nicht die offenen fragen - finde ich. das die instructions-länge vereinheitlicht wird, darauf deuten die angegeben werte nicht. nur auf länger...
reduziert sich die benötigte bandbreite in dem angegebenen beispiel? meint dynamic tatsächlich die benötigten befehle in laufzeit?
denn die gegebene antwort von nemesisTN überzeugt mich nicht - 10% oder ähnliches wären m.e. völlig utopisch hinsichtlich verbesserter sprungvorhersage. vielmehr denke ich, daß es eben darum geht, daß weniger befehle zur bearbeitung benötigt werden.
die erklärung zu "back and back register" könnte (!) tatsächlich hinkommen. wäre schön, wenn dieses näher erklärt werden könnte(!)
reduziert sich die benötigte bandbreite in dem angegebenen beispiel? meint dynamic tatsächlich die benötigten befehle in laufzeit?
denn die gegebene antwort von nemesisTN überzeugt mich nicht - 10% oder ähnliches wären m.e. völlig utopisch hinsichtlich verbesserter sprungvorhersage. vielmehr denke ich, daß es eben darum geht, daß weniger befehle zur bearbeitung benötigt werden.
die erklärung zu "back and back register" könnte (!) tatsächlich hinkommen. wäre schön, wenn dieses näher erklärt werden könnte(!)
BlackBirdSR
Commodore Special
128Bit register, die 2 64Bit Werte aufnehmen.
Aber keine 128Bit Genauigkeit.
NemesisTN
Vice Admiral Special
@BlackBirdSR:
Das kam wohl en wenig doof rüber.
Ich meinte EIN Datum mit 128bit (Genauigkeit sei mal dahingestellt)
oder ZWO Daten mit je 64bit (Genauigkeit wieder egal aber logischerweise geringer als bei 128bit)
usw...
Logisch das keine 128bit Genauigkeit gehen, dann müsste das Register ja breiter als 128bit sein um den Exponenten und das Vorzeichen mit aufzunehmen.
Das kam wohl en wenig doof rüber.
Ich meinte EIN Datum mit 128bit (Genauigkeit sei mal dahingestellt)
oder ZWO Daten mit je 64bit (Genauigkeit wieder egal aber logischerweise geringer als bei 128bit)
usw...
Logisch das keine 128bit Genauigkeit gehen, dann müsste das Register ja breiter als 128bit sein um den Exponenten und das Vorzeichen mit aufzunehmen.
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
@Treverer
> ABER: da steht nun mal "instruction lenght". was ist mit den länge der zu verarbeitenden daten? bleibt die konstant? oder werden zb. 32 bit auf 64 aufgebläht. teilweise oder immer?
Teilweise
> oder hängt das von der intelligenz der programmierer/kompiler ab?
Von beidem. Über weite strecken dürften die Daten gleich bleiben, was sich ändert ist fast ausschließlich Pointer.
> was meint "dynamic? während der laufzeit eines programmes auftretend? sehe ich das richtig, daß gemeint ist mit ""- dynamic instruction count decreased by 10%", daß im 64bit modus zehn prozent weniger befehle verarbeitet werden müssen, um das gleiche ergebnis des programmes zu leisten?
Jep. Dynamic Instruction = tatsächlich ausgeführte Instructions; Static Instructions = gesammter Programmcode.
Für dynamic loads und stores gilt analoges. Wobei ein Load/Store durchaus vom Cache kommen kann (d.h. der Einfluss auf die tatsächliche Run-Time ist nicht ohne weiteres Ersichtlich). Übrigens enthält normaler Code ca. 25% "silent stores". D.h. stores die nichts am Programmzustand ändern (rückschreiben des gleichen Werts, etc.).
> "back to back register dependencies
Das sind die Abhängigkeiten weil das Ergebnis einer Berechnung noch nicht im Zielregister vorliegt, aber schon die nächste Instruction vom Ergebins abhängt => kein OOO
Ein zugegebenermaßen dummes Beispiel:
addl $22,%rsp
addl $-4,%rsp
addl $-8,%rsp
> sind das operationen, die notwendig sind, weil nicht genügend register vorhanden sind
Darin könnte _ein_ Grund liegen.
> wie stark beansprucht so ein "back to back register" eigentlich ram/cache bandbreite?
Eigentlich gar nicht, es gibt nur einen Stall der Execution-Pipeline.
> ABER: da steht nun mal "instruction lenght". was ist mit den länge der zu verarbeitenden daten? bleibt die konstant? oder werden zb. 32 bit auf 64 aufgebläht. teilweise oder immer?
Teilweise
> oder hängt das von der intelligenz der programmierer/kompiler ab?
Von beidem. Über weite strecken dürften die Daten gleich bleiben, was sich ändert ist fast ausschließlich Pointer.
> was meint "dynamic? während der laufzeit eines programmes auftretend? sehe ich das richtig, daß gemeint ist mit ""- dynamic instruction count decreased by 10%", daß im 64bit modus zehn prozent weniger befehle verarbeitet werden müssen, um das gleiche ergebnis des programmes zu leisten?
Jep. Dynamic Instruction = tatsächlich ausgeführte Instructions; Static Instructions = gesammter Programmcode.
Für dynamic loads und stores gilt analoges. Wobei ein Load/Store durchaus vom Cache kommen kann (d.h. der Einfluss auf die tatsächliche Run-Time ist nicht ohne weiteres Ersichtlich). Übrigens enthält normaler Code ca. 25% "silent stores". D.h. stores die nichts am Programmzustand ändern (rückschreiben des gleichen Werts, etc.).
> "back to back register dependencies
Das sind die Abhängigkeiten weil das Ergebnis einer Berechnung noch nicht im Zielregister vorliegt, aber schon die nächste Instruction vom Ergebins abhängt => kein OOO
Ein zugegebenermaßen dummes Beispiel:
addl $22,%rsp
addl $-4,%rsp
addl $-8,%rsp
> sind das operationen, die notwendig sind, weil nicht genügend register vorhanden sind
Darin könnte _ein_ Grund liegen.
> wie stark beansprucht so ein "back to back register" eigentlich ram/cache bandbreite?
Eigentlich gar nicht, es gibt nur einen Stall der Execution-Pipeline.
Ähnliche Themen
