Re: Pro und Contra 64Bit?

Juergen Ilse wrote:
Martin Bock <mbock@xxxxxxxxxxxxx> wrote:
Matthias Wieser <matthias-usenet@xxxxxx> schrub:
Naja, was ich meinte war, dass es nicht Sinn der Sache ist, ein
64bit-OS zu verwenden, wenn man dann 32bit-Applikationen laufen lässt.
Doch, genau das ist Sinn der Sache, weil es nunmal Anwendungen gibt, die
in 32bit besser laufen oder nur als 32bit Version vorhanden sind.
Solaris und UltraSparc CPU unterstützen dies auch und dort wird dieses
Feature auch gerne genutzt.
Selbst als 64-bitter besser laufende Anwendungen kommen unter
Linux/sparc64 nicht über 32-bit hinaus, weil unter Linux/sparc64 nur der
Kernel -- sonst nichts, aber auch gar nichts -- nativ 64-bittig läuft.
Wenn du keine 64-Bit-Software suf Solaris-64-Bit laufen laesst, ist das
IMHO eher dein Problem. Es ist zwar richtig, dass binary-Pakete groessten-
teils als 32-Bit-Software daher kommt, aber zum einen gibt es auch 64-Bit
binary-Pakete, zum anderen haelt einen niemand davon ab, selbst in 64-Bit
zu compilieren (BTDT), wobei man dann allerdings einen hinreichend neuen
gcc oder den Sun-Compiler verwenden sollte (gcc-2.95 kann IIRC keine 64-Bit
binaries uebersetzen ...).

Es gibt aber auch einen gewichtigen Unterschied zwischen Sparc (und
PowerPC und MIPS) einerseits und AMD64 (und IA64) andererseits.

Wenn 32-Bit- und 64-Bit-Modus des Prozessors bis auf die Wortbreite
identisch sind, gibt es im Grunde genommen kaum einen Vorteil,
64-bittigen Code zu verwenden, dafür aber einen "großen" (im
wörtlichen Sinne) Nachteil: 64-bittiger Objektcode ist deutlich größer
als 32-bittiger, IIRC bis zu 30%, da alle Adressen und auch diverse
grundlegende Datentypen und Konstanten einfach doppelt so groß sind.
Das bedeutet, sie nehmen mehr Platz auf der Festplatte weg, mehr Platz
im RAM, mehr Platz im Cache, verbrauchen mehr Bandbreite auf den
Bussen und im Netzwerk und brauchen daher länger zum Laden und zum
Starten. Mithin gibt es keinen vernünftigen Grund, 64-bittigen Code
zu verwenden. Es sei denn natürlich, man braucht den
64-Bit-Adressraum. Bei manchen CPUs ist auch
64-Bit-Integer-Arithmetik im 64-Bit-Modus schneller.

Solange aber eine Anwendung nicht mehr als 3 GiByte adressieren muss
oder viel 64-Bit-Integer-Arithmetik betreibt, hat man eben nur
Nachteile.

Jetzt kommt jedoch das große "Aber": ich schrieb oben, das ganze gelte
nur, "wenn 32-Bit- und 64-Bit-Modus des Prozessors bis auf die
Wortbreite identisch" seien. Genau das ist bei Sparc, PowerPC und
IIRC auch MIPS der Fall. Bei AMD64 und IA64 aber eben nicht. AMD64
hat im Long-Mode doppelt so viele Allzweck-Register wie x86 und
lindert damit eines der größten Performance-Probleme des x86, nämlich
die Registerknappheit. Außerdem gibt es im Long-Mode das NX-Bit als
zusätzliches Sicherheitsmerkmal, das bei x86 nur im langsameren
PAE-Modus zur Verfügung steht. Und der IA64 hat gar keinen
32-Bit-Modus, lediglich eine grottenlahme x86-Software-Emulation.

Das ist also der wesentliche Unterschied: bei AMD64 und IA64 ist der
64-Bit-Code deutlich performanter, deswegen ergibt es Sinn, möglichst
viel 64-bittigen Code zu verwenden. Bei Sparc, PowerPC und MIPS sind
64-Bit-Code und 32-Bit-Code gleich schnell, daher ist es aufgrund des
kleineren Codes sinnvoll, 32-Bit-Code zu verwenden, es sei denn, man
benötigt den größeren Adressraum oder betreibt viel
64-Bit-Integer-Arithmetik.

jwm
.

Relevant Pages