Don Lino schrieb am 16. April 2008 13:52
> > Das eigentliche Problem ist nicht die x86-Kompatibilität,
> > sondern das abstruse Registermodell des x86: lauter Spezial-
> > register, etliche davon gibt es sogar nur einmal.
>
> Das einzige was für den Compiler zählt ist, dass man nur mit CL
> shiften kann und Multiplikation sowie Division nur mit bestimmten
> Registern möglich sind; damit kommt ein Compiler aber zurecht.
Ah, dann sind sie doch deutlich flexibler geworden, als ich dachte.
Was bleibt, sind unnötig lange Instruktionen (weil die
ein-Byte-Befehle zu einem erheblichen Anteil von eher uninteressanten
MOV-Instruktionen belegt sind). D.h. der Maschinencode ist länger,
als er sein müsste (doppelt so lang vielleicht, wenn ich mal
gefühlsmäßig schätzen müsste), womit dann der Befehlscache doppelt so
schnell voll ist, wie er sein müsste.
Ist natürlich nicht die große Katastrophe, die x86 mal war, schlägt
sich aber wohl mit merklichen Einbußen nieder, wenn ein Anwender mal
ziemlich viele Programme gleichzeitig aktiv hat (Audioplayer,
Download, Rechtschreibprüfung, Betriebssystem... da kann's schon
langsam eng werden, jedenfalls, bis sich die Cachegröße mal wieder
verdoppelt hat).
> Die
> Performance der x86er ist immer noch sehr gut und mit dem Nehalem
> kann es gut sein, dass x86 wieder vor POWER6 und UltraSparc-T2 liegt.
Man muss halt die technischen Hindernisse dagegen abwägen, dass die
Standardisierung Intel sagenhafte Gewinne beschert, die zu einem
guten Teil auch wieder in die Anwendungsforschung fließen.
D.h. die Probleme der eigentlich schlechteren Architektur werden mit
Ingenieursstunden totgeworfen.
Oder, anders formuliert: hätte Intel am Anfang kein so grottiges
Registermodell gehabt, wäre die x86-Architektur endgültig
uneinholbar. So haben Sparc&Co. zumindest den Anschein einer Chance.
> > Das bedeutet, dass dem Compiler die Register rasch
> > ausgehen, und er muss die Daten ins RAM verschieben.
>
> Das ist garnicht so das große Problem, was sich schon daran zeigt,
> dass die doppelte Register-Anzahl bei Intel 64 bzw AMD64 nicht viel
> bringt.
Da muss man wohl vorsichtig sein. Die amd64 wird einfach nicht so
viel optimiert, weil die Architektur (noch) nicht so verbreitet ist.
> > Eine vernünftige Registerarchitektur hat einen Sack
> > austauschbarer Universalregister und drei oder vier
> > Spezialregister (Statusregister, Program Counter,
> > Stack Pointer, eventuell noch einen Frame Pointer).
> > Bei amd64 haben sie ein paar zusätzliche Universal-
> > register spendiert, aber wozu noch die Spezialregister?
>
> Welche Spezialregister meinst Du?
BX, CX, DX. Jedes für einen anderen Zweck (jedenfalls bei den
ältesten Maschinenbefehlen, wo man dann die wenigsten Präfixe
braucht).
Immerhin - schön, dass sie die Register allmählich zu
Universalregistern ausgebaut haben.
Andererseits lese ich in den einschlägigen Compiler-Newsgroups immer
wieder, dass die x86-Architektur als "register-starved" bezeichnet
wird (und zwar ohne dass sich Widerspruch regt). Soo universell
scheinen die amd64-Register dann doch nicht zu sein.
Aber ich müsste mir wirklich mal die Assemblerunterlagen zu amd64
antun.
> > Das eigentliche Problem ist nicht die x86-Kompatibilität,
> > sondern das abstruse Registermodell des x86: lauter Spezial-
> > register, etliche davon gibt es sogar nur einmal.
>
> Das einzige was für den Compiler zählt ist, dass man nur mit CL
> shiften kann und Multiplikation sowie Division nur mit bestimmten
> Registern möglich sind; damit kommt ein Compiler aber zurecht.
Ah, dann sind sie doch deutlich flexibler geworden, als ich dachte.
Was bleibt, sind unnötig lange Instruktionen (weil die
ein-Byte-Befehle zu einem erheblichen Anteil von eher uninteressanten
MOV-Instruktionen belegt sind). D.h. der Maschinencode ist länger,
als er sein müsste (doppelt so lang vielleicht, wenn ich mal
gefühlsmäßig schätzen müsste), womit dann der Befehlscache doppelt so
schnell voll ist, wie er sein müsste.
Ist natürlich nicht die große Katastrophe, die x86 mal war, schlägt
sich aber wohl mit merklichen Einbußen nieder, wenn ein Anwender mal
ziemlich viele Programme gleichzeitig aktiv hat (Audioplayer,
Download, Rechtschreibprüfung, Betriebssystem... da kann's schon
langsam eng werden, jedenfalls, bis sich die Cachegröße mal wieder
verdoppelt hat).
> Die
> Performance der x86er ist immer noch sehr gut und mit dem Nehalem
> kann es gut sein, dass x86 wieder vor POWER6 und UltraSparc-T2 liegt.
Man muss halt die technischen Hindernisse dagegen abwägen, dass die
Standardisierung Intel sagenhafte Gewinne beschert, die zu einem
guten Teil auch wieder in die Anwendungsforschung fließen.
D.h. die Probleme der eigentlich schlechteren Architektur werden mit
Ingenieursstunden totgeworfen.
Oder, anders formuliert: hätte Intel am Anfang kein so grottiges
Registermodell gehabt, wäre die x86-Architektur endgültig
uneinholbar. So haben Sparc&Co. zumindest den Anschein einer Chance.
> > Das bedeutet, dass dem Compiler die Register rasch
> > ausgehen, und er muss die Daten ins RAM verschieben.
>
> Das ist garnicht so das große Problem, was sich schon daran zeigt,
> dass die doppelte Register-Anzahl bei Intel 64 bzw AMD64 nicht viel
> bringt.
Da muss man wohl vorsichtig sein. Die amd64 wird einfach nicht so
viel optimiert, weil die Architektur (noch) nicht so verbreitet ist.
> > Eine vernünftige Registerarchitektur hat einen Sack
> > austauschbarer Universalregister und drei oder vier
> > Spezialregister (Statusregister, Program Counter,
> > Stack Pointer, eventuell noch einen Frame Pointer).
> > Bei amd64 haben sie ein paar zusätzliche Universal-
> > register spendiert, aber wozu noch die Spezialregister?
>
> Welche Spezialregister meinst Du?
BX, CX, DX. Jedes für einen anderen Zweck (jedenfalls bei den
ältesten Maschinenbefehlen, wo man dann die wenigsten Präfixe
braucht).
Immerhin - schön, dass sie die Register allmählich zu
Universalregistern ausgebaut haben.
Andererseits lese ich in den einschlägigen Compiler-Newsgroups immer
wieder, dass die x86-Architektur als "register-starved" bezeichnet
wird (und zwar ohne dass sich Widerspruch regt). Soo universell
scheinen die amd64-Register dann doch nicht zu sein.
Aber ich müsste mir wirklich mal die Assemblerunterlagen zu amd64
antun.