Re: 64 Bit auf WebServer

till toenges <tt(at)kyon.de> wrote:
> Bernd Walter wrote:
> > Ja, wobei auch meist übersehen wird, dass gerade die 64 bit Pointer
> > der eigendliche Vorteil von 64 bit Maschinen sind.
> > Wie viele und wie große Register es gibt ist durch Compiler
> > transparent, aber wenn der Addressraum nicht mehr reicht ist selbst
> > in Hochsprachen Trickserei angesagt, um das zu umgehen.
> > Und das hat nichts mit der Menge an installiertem RAM zu tun.
>
> Geht so. Klar sind 64 Bit Pointer superbequem für Programmierer, wenn
> man es tatsächlich mit großen Datenmengen zu tun bekommt. In vielen
> Fällen ist das aber gar nicht relevant.

In vielen Fällen ist das sehr wohl relevant.

Daß der Adreßraum bei i386 auf 32 Bit beschränkt ist (und
dafür gibt es _keine_ Lösung oder Work-around!), ist schon
seit mehreren Jahren eines der größeren Probleme dieser
Architektur, unter der auch schon viele FreeBSD-Server
litten. Und man braucht nicht unbedingt mehr als 4 Gbyte
RAM, um an dieses Limit zu stoßen.

Das oftmals angeführte PAE ist ein Workaround für den
Fall, daß man auf einer i386-Plattform mehr als 4 Gbyte
RAM ansprechen möchte. Es hebt jedoch _nicht_ die Be-
schränkung des Adreßraums auf 32 Bit auf. (Und davon
abgesehen ist PAE ohnehin ein ganz schauerlicher Hack.)

> Die zusätzlichen Register bringen da schon mehr. Die x86 Architektur
> leidet nämlich ziemlich unter Registermangel, es gibt für "normale"
> Daten gerade mal 8 Register. In x86-64 sind das immerhin schon 16 (hatte
> mein Amiga damals auch schon...).

Naja, das muß man jetzt mal relativieren (in beiden
Fällen).

i386 hat eigentlich nur vier allgemein verwendbare Re-
gister. BP, SI und DI (bzw. E-) werden meistens für
Adressierungszwecke verwendet (weil dafür keines der
anderen Register verwendet werden kann) und stehen daher
nicht für allgemeine Zwecke zur Verfügung. Und E(SP)
ist ohnehin nicht frei verfügbar.

Beim alten Amiga-Prozessor (680x0) gab es genau acht
allgemein verwendbare Register. Darüberhinaus gab es
noch sieben Adressregister, für die im Grunde genommen
das gleiche galt wie oben für BP, SI und DI. Darüber-
hinaus konnten mit den Adressregistern nicht alle Opera-
tionen durchgeführt werden (z.B. keine Multiplikation);
sie waren daher nicht allgemein verwendbar. Das achte
Adressregister war der Stackpointer und daher auch nicht
frei verwendbar.

Eine Anzahl von vier bis acht Registern ist übrigens
typisch für CISC-Architekturen wie x86 und 68k. RISC-
Architekturen haben da deutlich mehr, wobei allerdings
auch das Handling meistens anders ist. Eine typische
Implementation ist das Register-Windowing. Bei SPARC-
Prozessoren hast Du eine große Anzahl Register, z.B.
64 Stück (je nach Prozessorgeneration), wobei aber die
aktuelle Funktion nur Zugriff auf einen Ausschnitt von
acht Registern davon hat (Register-Window), sowie auf
die acht vorhergehenden Register, die der aufrufenden
Funktion gehören, und die acht nachfolgenden Register,
mit denen man Werte an eine Funktion übergeben kann,
die man selbst aufruft. Bei einem Funktionsaufruf
füllt man also diese nachfolgenden Register und schiebt
dann einfach das Register-Window um acht Plätze weiter.
Das ist höchst effizient, da keinerlei Stack oder
sonstige Speicherplätze im RAM involviert sind (außer
natürlich, wenn größere Datenmengen übergeben werden
müssen, oder wenn bei tieferer Schachtelung die Register
ausgehen und in den RAM »gepaged« werden müssen).

> Das bringt bei der typischen C-Programmierweise, wo jede kleine Funktion
> in einzelnen Files compiliert und dann erst gelinkt wird, noch nicht so
> viel. In anderen Sprachen, oder wenn der Compiler größere Funktionen
> bzw. mehrere zusammen compiliert und Inlining verwendet, machen sich
> zusätzliche Register sehr, sehr nützlich bemerkbar.

Nach meiner Erfahrung macht sich Inlining in vielen
Fällen eher negativ bemerkbar, da die Caches schneller
überlaufen (das ist auch der Grund, weshalb bei gcc
häufig die Optimierung -Os empfohlen wird). Früher war
das anders, weil da der Overhead durch Funktionsaufrufe
im Vergleich recht groß war. Heutzutage ist das nicht
mehr so tragisch. Moderne Prozessoren haben da schon
in Hardware zahlreiche Optimierungen, so daß bei »kurzen«
Funktionsaufrufen oft gar keine Speicherzugriffe (auch
nicht im Level1-Cache) stattfinden.

> Die 64 Bit Breite der Register kann u.U. auch noch für einige Tricks
> genutzt werden.

Naja, hauptsächlich für den »Trick«, 64-Bit-Werte zu
speichern und zu bearebiten. :-) Solche kommen ja in
der Praxis durchaus häufig vor, allein schon im FreeBSD-
Kernel: Ein »off_t« ist 64 Bit groß, der wird z.B. für
Dateigrößen verwendet (in inodes u.a.), Seek-Pointer usw.;
die Byte- und Paketzähler von IPFW, IPF und PF sind 64 Bit
groß etc.

Es macht schon einen spürbaren Unterschied, ob man einen
64-Bit-Wert »native« mit einer Maschineninstruktion bear-
beiten kann, oder ob man es mit 32-Bit-Werten emulieren
muß. Insbesondere wenn noch Locking ins Spiel kommt, weil
auf einem SMP-System oder in einer Multithreaded-Anwendung
ein 64-Bit-Wert atomar bearbeitet werden muß, nimmt der
Performance-Unterschied beträchtliche Dimensionen an.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als
wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen
pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht,
was ich damit soll." -- Frank Klemm, de.comp.os.unix.discussion
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message