Umstieg von Debian i386 auf amd64
Jan 'RedBully' Seiffert
redbully at cc.fh-luh.de
Wed Dec 28 15:10:29 CET 2005
Jan-Benedict Glaw wrote:
> On Wed, 2005-12-28 13:39:49 +0100, Andreas Kreisig <akreisig at versanet.de> wrote:
>
>>Jan-Benedict Glaw wrote:
>>
>>
>>>Ein normaler 08/15-Desktop kann aber auch langsamer
>>>werden. Da hilft letztlich nur das Ausprobieren.
>>
>>Einfache Frage: warum kann's langsamer werden?
>
>
> 64bit sind mehr als 32bit. Wenn Du bisher mit 32bit-Integer-Typen
> ausgekommen bist (und das auch weiterhin tust), aber jedesmal 64bit
> geladen werden, dann verschenkst Du Speicher-Bandbreite.
>
Hier mal einmisch...
der klassische C-'int' bleibt interresanterweise 32-Bit, darum knallt es
oft auch, wenn man versucht echte "Profi"-software auf 64-Bit zu
portieren. (irgendwo wird immer ein Pointer auf int gecastet...)
Schlimmer ist eher, das jeder popelige Speicherzeiger (Pointer) nun
doppelt so gross ist und doppelt so viel Platz braucht, hauptsaechlich
gefuellt mit Nullen.
Gesetz dem Fall, eine Anwendung benutzt viele Pointer, kann sie nun auf
zwei Arten darunter leiden:
1) Sie braucht (viel) mehr Speicher
Das wird erst Negativ wenn der Kernel swappen muss, dann aber richtig.
(oder man kann nicht so viele Instanzen gleichzeitig starten)
2) Sie fuellt die Speicherbandbreite
In wie weit das Negativ ist, haengt stark von der Anwendung ab.
Wenn ein DropDown-GUI-Widget beim iterrieren ueber die Pointer, die
seinen Inhalt ergeben, etwas laenger braucht, ja, dann koenntest du
denken "Oh, das ist langsamer" (nur ob das 1000nde Pointer sind?), aber
wenn ein "make" zum traversieren seiner DAG ein tucken laenger braucht,
wirst du es nicht mal merken (das geht im benoetigten Festplatten-I/O
unter).
Ueberhaupt bis das negativ auffaehlt ... denn:
Im 64-Bit modus bekommt die CPU 8 zusaetzliche Register
(In-CPU-Speicherstellen). Das beschleunigt eben auch einiges wieder.
In realen Anwedungen kommt es eben auf +/- 0 raus. Einige erfahren ein
leichtes Plus, einige sollen erheblich besser laufen (Cryptographie: SSH
SSL).
Wo es z.B. wohl negativ auffalen soll (so hab ich gehoert) ist der/die
GCC, der aber auch echt ins Fettnaepfchen tritt. Beim Kompilieren eines
Stueck Quellcode wandelt er die Eingabe in lauter (riesige) Listen, die
die einzelnen Befehle in ihrer Reihenfolge darstellen. Die einzelnen
Listenelemente werden nun groesser (mehr Speicherverbrauch) und die
Hauptaufgabe, das traversieren der Listen um sie
umzusortieren/umzuwandeln, braucht laenger.
Naja, fuer die meisten Anwendungen ist 64-Bit nicht wirklich interresant
(lies: kein muss), es fehlt da so eine Art mixed-Mode wie ihn IMHO Sparc
hatte.
> MfG, JBG
>
>
Gruss
Jan
--
Freiheit®
More information about the Linux
mailing list