Twitter und Facebook-Anbindung
X
Tweet Follow @twitterapi
!!! Anbindung an twitter und facebook öffnen !!!

Wenn Ihnen mein Online-Buch gefällt,
dann bedanken Sie sich doch mit einer kleinen Spende...

8.4.2 Byte Padding

8.4.2 Byte Padding

Bisher habe ich ein paar Sachen verschwiegen, welche essentiell sind, wenn man richtig schnelle und performante Programme entwickeln möchte. Und zwar geht es mir um die interne Speicherverwaltung. Ich werde jetzt nicht die komplette Speicherverwaltung erklären. Abgesehen davon, dass ich Sie damit jetzt nur langweilen würde, ist dies auch nicht notwendig.

Ich hatte ja schon erwähnt, dass ein Boolean ein Byte groß ist, obwohl ein Bit ausreichend wäre und hatte dies ein wenig darauf geschoben, dass dieser Datentyp neu sei und aus Abwärtskompatibilitätsgründen so groß ist. Nun, eigentlich steckt dahinter noch ein weiterer viel wichtigerer Grund. Der Arbeitsspeicher ist u.a. in Blöcke eingeteilt, welche ein Byte oder ein vielfaches von einem Byte groß sind. Dies liegt daran, dass jeder Bereich adressiert werden muss, um Daten abzulegen bzw. sie holen zu können. Würde man jedes einzelne Bit adressieren wollen, bräuchte man viel größere Adressräume und viel Sinn würde dies auch nicht machen, da man eh in 99,99% der Fälle größere Bereiche benötigt.

Des Weiteren werden Daten immer erst auf Größe analysiert, bevor sie abgelegt werden. Zudem werden sie immer so platziert, dass sie immer an einer Adresse liegen, welche ein Vielfaches ihrer Größe entspricht. Wie Sie sich denken können folgt daraus, dass die Daten nicht ganz zusammenhängend im Speicher liegen. Man spricht von einer Fragmentierung. Der Platz zwischen den Variablen kann jetzt aber nicht einfach so genutzt werden, sondern wird mit Nullen aufgefüllt. Dies nennt man das Byte Padding.

Speicherverwaltung mit unterschiedlichen Datentypen

Aber warum werden die Variablen so im Speicher abgelegt, wenn man doch dadurch Platz verschwendet? Der Grund ist genauso einfach wie genial. Immer wenn die CPU auf den RAM zugreift, bzw. Daten verlangt, werden intern immer gleich mehrere Blöcke mit einem Schlag geholt (meistens 64 oder 128, je nach Busbreite). Das macht auch Sinn, weil viele Variablen eh größer als ein Block sind und so wird sie mit einem einzigen s.g. "fetch" geholt, statt vieler einzelner. Warum das gut ist? Die Zeitspanne zwischen dem Anfordern und dem Erhalt, dauert für die CPU eine halbe Ewigkeit und je mehr Zugriffe man benötigt, desto langsamer wird ein Programm (und das erheblich – deshalb gibt es in der CPU auch einen Cache).

Aber was hat das damit zu tun, dass die Variablen dann an einer bestimmten Adresse stehen müssen? Stellen Sie sich vor, die CPU kann immer nur 64 Blöcke mit einem mal holen und Sie hätten eine Variable, welche vier Blöcke benötigt und an den Adressen 62 bis einschließlich 65 stehen würde. Die Konsequenz daraus ist, dass man zwei Zugriffe benötigen würde (den von 0 bis 63 und den von 64 bis 127), obwohl einer reichen würde. Wenn diese Variable also an einer durch vier teilbaren Stelle liegt (60 oder 64), reicht wieder ein Zugriff. Sie fragen sich jetzt vielleicht, warum dann nicht z.B. Block 10 bis 73 geholt wird? Abgesehen von anderen Mechanismen bei der Speicherverwaltung (siehe Paging und Cachingverfahren) hat dies einen ganz einfachen Grund. Der Computer kann super gut mit Werten umgehen, welche einer Zweierpotenz entsprechen. Rechenoperationen mit diesen Werten können sehr effizient durchgeführt werden und sind leicht in Hardware zu gießen. Alle Anderen Zahlen würden einen viel höheren Rechenaufwand bedeuten und das gesamte System ausbremsen.

Zum Seitenanfang
Zum Inhaltsverzeichnis

© Copyright by Thomas Weiß, 2009 - 2012