Kapitel 12 - Hardware-Sicht: Enumerationen unter der Lupe von CPU und RAM

Hallo Thorsten! Nachdem wir uns im Hauptkapitel mit der logischen Eleganz und den vielseitigen Einsatzmöglichkeiten von Enumerationen (Enums) beschäftigt haben, reißen wir jetzt die Motorhaube auf.

Als Systemprogrammierer gibst du dich verständlicherweise nicht mit dem abstrakten Konzept „Es ist eine von mehreren Varianten“ zufrieden. Du willst wissen: Wie sieht das im RAM aus? Wie viele Bytes wandern über den Datenbus? Und wie optimiert der Compiler die Bitmuster, um auch das letzte Fünkchen Performance und Speicherplatz herauszukitzeln?

Schnapp dir einen Kaffee (oder Tee) – wir steigen tief in die Hardware-Ebene ab!

1. Das Tagged-Union-Prinzip: Wie Rust Enums speichert

Wenn du aus der C- oder C++-Welt kommst, kennst du wahrscheinlich union. Eine union ermöglicht es, verschiedene Datentypen an derselben Speicheradresse zu lagern. Das ist extrem speichereffizient, hat aber einen gigantischen Haken: Die Hardware hat keine Ahnung, welcher Typ gerade aktiv ist. Liest du den Speicher als f32 aus, obwohl dort ein i32 abgelegt wurde, interpretierst du die Bits falsch. Die Folge? Unvorhersehbares Verhalten und rauchende Compiler-Köpfe.

Rust löst dieses Problem mit sogenannten Tagged Unions (oft auch sichere Unions oder sum types genannt). Unter der Haube kombiniert Rust eine C-ähnliche union mit einem Zustandsindikator, dem sogenannten Diskriminant (oder einfach Tag).

Alltagsanalogie: Die beschriftete Werkzeugkiste

Stell dir eine Werkzeugkiste vor. In dieser Kiste liegt entweder ein großer Drehmomentschlüssel (eine Variante mit viel Speicherbedarf) oder eine kleine Packung Bits (eine Variante mit wenig Speicherbedarf). Damit du nicht jedes Mal den Deckel öffnen und die Kiste durchsuchen musst, gibt es an der Außenseite einen kleinen Drehschalter (das Tag). Zeigt der Schalter auf „Drehmomentschlüssel“, weißt du sofort, was drin liegt. Die Kiste muss natürlich immer groß genug sein, um den Drehmomentschlüssel aufzunehmen – selbst wenn aktuell nur die kleinen Bits darin liegen. Zudem verbraucht der Drehschalter an der Außenseite ebenfalls ein klein wenig Platz.

Auf die Hardware übertragen bedeutet das:

Der Diskriminant (Tag): Ein kleiner ganzzahliger Wert (standardmäßig meist 1 Byte groß), der angibt, welche Variante des Enums aktuell aktiv ist.
Die Payload (Nutzlast): Der Speicherplatz für die Daten der aktivierten Variante.
Das Alignment und Padding: Füllbits, die sicherstellen, dass die CPU effizient auf die Daten zugreifen kann.

2. Speicherbedarf berechnen: Größe und Alignment

Um die Größe eines Enums im RAM zu bestimmen, müssen wir zwei Faktoren verstehen: Größe (Size) und Ausrichtung (Alignment).

Note

Was war noch mal Alignment? CPUs greifen am liebsten auf Speicheradressen zu, die Vielfache ihrer eigenen Breite oder der Breite des Datentyps sind. Ein u32 (4 Bytes) liegt idealerweise an einer Adresse, die durch 4 teilbar ist. Ein f64 (8 Bytes) an einer durch 8 teilbaren Adresse. Liegt ein Wert „schief“ im Speicher (unaligned), muss die CPU im schlimmsten Fall zwei Speicherzugriffe statt einem durchführen. Um das zu verhindern, fügt der Compiler ungenutzte Füllbytes ein – das sogenannte Padding.

Für die Berechnung eines Standard-Enums gilt folgende Faustregel:

$$\text{Größe des Enums} = \text{Größe des Tags} + \text{Größe der größten Variante} + \text{Padding (für das Alignment)}$$

Das Alignment des gesamten Enums entspricht dabei dem strengsten Alignment (der größten Ausrichtungsanforderung) seiner Varianten.

Schritt-für-Schritt-Beispiel

Betrachten wir das folgende Enum:

#![allow(unused)]
fn main() {
enum HardwareBeispiel {
    Leer,                // Variante ohne Daten
    Zahl(u32),           // Benötigt 4 Bytes, Alignment 4
    Koordinaten(f64, f64)// Benötigt 16 Bytes (2 * 8 Bytes), Alignment 8
}
}

Wie berechnet der Rust-Compiler hier das Layout im RAM auf einem 64-Bit-System?

Größte Variante ermitteln:
- Leer benötigt 0 Bytes.
- Zahl(u32) benötigt 4 Bytes (Alignment 4).
- Koordinaten(f64, f64) benötigt 16 Bytes (Alignment 8).
- Die größte Variante ist somit Koordinaten mit 16 Bytes und einem Alignment von 8.
Alignment des Enums festlegen:
- Da die Variante Koordinaten ein Alignment von 8 fordert, muss das gesamte Enum HardwareBeispiel ein Alignment von 8 haben. Das bedeutet, jede Instanz dieses Enums im RAM muss an einer Adresse liegen, die durch 8 teilbar ist, und seine Gesamtgröße muss ebenfalls ein Vielfaches von 8 sein.
Tag-Platzierung:
- Rust reserviert 1 Byte für den Diskriminanten-Tag (z. B. 0 für Leer, 1 für Zahl, 2 für Koordinaten).
Padding berechnen:
- Legen wir das Tag an den Anfang (Offset 0). Das Tag belegt Byte 0.
- Die Daten der Variante müssen nun folgen. Da das Alignment des Enums 8 ist, müssen die Daten von Koordinaten (welche an Offset 8 beginnen müssen, um korrekt ausgerichtet zu sein) passend platziert werden.
- Der Compiler fügt daher 7 Bytes Padding nach dem Tag ein, um von Byte 1 bis Byte 7 aufzufüllen.
- Ab Byte 8 folgen dann die 16 Bytes der Koordinaten.
- Gesamtgröße: 1 Byte (Tag) + 7 Bytes (Padding) + 16 Bytes (Payload) = 24 Bytes.

Grafisch sieht das im RAM so aus:

Byte-Offset:  0   1   2   3   4   5   6   7   8               15  16              23
            +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Inhalt:     |Tag|      Padding (7 Bytes)    |          Payload (16 Bytes)           |
            +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
             \_____________________________/ \_____________________________________/
                      Tag-Bereich                     Größte Variante (Koordinaten)

Wenn nun die Variante Zahl(u32) aktiv ist, wird der Tag auf 1 gesetzt. Der u32-Wert wird in den Payload-Bereich geschrieben. Die verbleibenden Bytes der 24 Bytes großen Struktur bleiben einfach ungenutzt. Sicherheit hat ihren Preis in Form von ein paar ungenutzten Bytes, aber dafür stürzt dein Programm nicht ab!

3. Die Magie der Nischen-Optimierung (Niche Optimization)

Jetzt kommen wir zu einem echten Meisterstück des Rust-Compilers. In vielen Programmiersprachen führt das Einpacken eines Werts in ein Enum (wie das allgegenwärtige Option\<T\>) unweigerlich zu zusätzlichem Speicherbedarf (dem Tag-Byte) und schlechterem Alignment.

Rust hasst unnötigen Speicherverbrauch. Deshalb nutzt der Compiler sogenannte Nischen im Wertebereich von Datentypen aus. Eine Nische ist ein Bitmuster, das für einen bestimmten Typ ungültig ist.

Alltagsanalogie: Der Schlüsselhaken

Stell dir ein Schlüsselbrett an der Wand vor. Es gibt einen Haken für den Autoschlüssel. Wenn der Haken leer ist, hängt kein Schlüssel da. Wir müssen nicht extra ein Schildchen „Schlüssel ist da / ist nicht da“ daneben nageln. Der Zustand des Hakens selbst (entweder hängt ein Schlüssel dran oder eben nicht) gibt uns diese Information. Das funktioniert allerdings nur, weil ein „leerer Haken“ ein eindeutiger Zustand ist. In der Software-Entwicklung entspricht das der Adresse 0x0 (Null-Pointer). Da eine gültige Speicheradresse niemals 0 sein darf, ist 0 unsere Nische!

3.1 Die Null-Pointer-Optimierung (NPO)

Ein Zeiger (wie eine Referenz &T, ein veränderlicher Zeiger &mut T oder ein Smart Pointer wie Box\<T\>) darf in Rust niemals auf die Speicheradresse 0x0 (Null) zeigen. Das wird vom Compiler und der Runtime streng garantiert.

Wenn du nun Folgendes schreibst:

#![allow(unused)]
fn main() {
let optionale_referenz: Option<&i32> = None;
}

Normalerweise müsste Option\<&i32\> Speicher für die Referenz (8 Bytes auf 64-Bit) plus 1 Byte für den Tag benötigen. Wegen des Alignments von 8 würde das gesamte Enum auf 16 Bytes anwachsen.

Doch hier greift die Null-Pointer-Optimierung:

Für Some(&T) speichert Rust die tatsächliche Speicheradresse (z. B. 0x7fffde20). Diese ist garantiert ungleich 0.
Für None speichert Rust einfach den Wert 0x0 (Bitmuster komplett auf Null).

Der Compiler weiß: Wenn an dieser Stelle im Speicher eine 0 steht, bedeutet das None. Steht dort eine Zahl ungleich 0, ist es eine gültige Referenz. Das Resultat? Option\<&T\> belegt exakt 8 Bytes im Speicher – keinen einzigen Bit-Overhead gegenüber einem rohen C-Zeiger!

3.2 Nischen-Optimierung bei Booleans und Enums

Die Nischen-Optimierung beschränkt sich nicht nur auf Zeiger. Betrachten wir den Typ bool. Ein bool belegt im Speicher 1 Byte (8 Bits). Allerdings gibt es für einen Wahrheitswert nur zwei gültige Bitmuster:

0x00 für false
0x01 für true

Das bedeutet, dass die Bitmuster 0x02 bis 0xFF (254 freie Werte!) völlig ungenutzt sind. Das sind unsere Nischen! Wenn wir nun ein Option\<bool\> erstellen:

#![allow(unused)]
fn main() {
let wert: Option<bool> = None;
}

Rust nutzt eine dieser freien Nischen (typischerweise den Wert 2), um None darzustellen.

Some(false) im Speicher: 0x00
Some(true) im Speicher: 0x01
None im Speicher: 0x02

Daher ist Option\<bool\> exakt 1 Byte groß! Keine zusätzliche Diskriminante, kein Padding. Das ist hocheffiziente Bit-Jonglage auf Systemebene.

3.3 Eigene Nischen schaffen mit Non-Zero-Typen

Du kannst dem Compiler aktiv helfen, solche Nischen zu finden. Die Standardbibliothek bietet dafür spezielle Typen im Modul std::num an, wie z. B. NonZeroU32 oder NonZeroUsize.

Ein normaler u32 belegt 4 Bytes und kann jeden Wert von 0 bis $2^{32}-1$ annehmen. Es gibt keine Nische. Option\<u32\> benötigt daher 8 Bytes Speicher (4 Bytes für die Zahl + 1 Byte für den Tag + 3 Bytes Padding).

Verwendest du stattdessen NonZeroU32, versprichst du dem Compiler, dass dieser Wert niemals 0 sein wird. Dadurch wird die 0 zur Nische:

#![allow(unused)]
fn main() {
use std::num::NonZeroU32;

// Größe von NonZeroU32: 4 Bytes
// Größe von Option<NonZeroU32>: 4 Bytes!
}

4. Das Attribut `#[repr(...)]`: Volle Kontrolle über das Layout

Standardmäßig behält sich der Rust-Compiler das Recht vor, das Speicherlayout von Enums nach Belieben zu optimieren und die Felder im RAM so anzuordnen, wie es am effizientesten ist (das sogenannte repr(Rust)-Layout). Das bedeutet aber auch, dass sich das Layout zwischen verschiedenen Compiler-Versionen ändern kann.

Wenn du FFI (Foreign Function Interface) betreibst, also mit C-Bibliotheken kommunizierst, oder Binärdaten direkt über das Netzwerk schickst, benötigst du ein stabiles und exakt definiertes Layout. Hier kommen die Repräsentations-Attribute ins Spiel.

4.1 `#[repr(C)]`

Dieses Attribut zwingt den Compiler, das Enum so zu strukturieren, wie es ein C-Compiler tun würde.

Für Enums ohne assoziierte Werte (C-Style Enums) entspricht das der Größe des Standard-Integers von C.
Für Enums mit Payload (oft als tagged unions in C nachgebaut) wird ein festes Speicherlayout erzwungen: Zuerst kommt das Tag (als int), gefolgt vom Padding, gefolgt von der Payload der Union. Das verhindert zwar Rust-spezifische Speicheroptimierungen (wie Nischen), garantiert aber FFI-Kompatibilität.

4.2 `#[repr(u8)]`, `#[repr(i32)]`, etc.

Hiermit bestimmst du exakt die Größe und den Typ des Diskriminanten-Tags.

#![allow(unused)]
fn main() {
#[repr(u8)] // Der Tag soll exakt 1 Byte (u8) groß sein!
enum Signal {
    Rot = 10,
    Gelb = 20,
    Gruen = 30,
}
}

Wenn du dieses Enum an C-Code übergibst, weiß das FFI-System exakt, dass dieses Enum als ein einzelnes Byte im Speicher interpretiert werden muss.

5. Vollständiges Demoprogramm zur Speicherinspektion

Genug der grauen Theorie! Lass uns den Speicher direkt vermessen. Wir schreiben ein vollständiges, kompilierbares Programm, das uns die exakten Größen und Alignments unserer Enums im Terminal ausgibt.

Erstelle eine Datei (oder betrachte diesen Code im Detail) und führe ihn aus:

use std::mem::{size_of, align_of};
use std::num::Zeroable; // Für FFI-Vergleiche nützlich

// 1. Ein klassisches Enum ohne Daten
enum EinfachesEnum {
    Eins,
    Zwei,
    Drei,
}

// 2. Ein Enum mit verschiedenen Datenfeldern (Tagged Union)
enum KomplettesEnum {
    Nichts,
    Zahl(u32),
    Koordinaten(f64, f64),
}

// 3. Ein Enum mit erzwungener Tag-Größe
#[repr(u8)]
enum ReprU8Enum {
    A(u32),
    B(u32),
}

fn main() {
    println!("=== RUST ENUM MEMORY INSPECTOR ===");
    println!();

    // --- Sektion 1: Einfaches Enum ---
    println!("--- 1. Einfaches Enum (ohne Daten) ---");
    println!("Größe von EinfachesEnum: {} Byte", size_of::<EinfachesEnum>());
    println!("Alignment von EinfachesEnum: {} Byte-Alignment", align_of::<EinfachesEnum>());
    println!();

    // --- Sektion 2: Tagged Union Speicheranalyse ---
    println!("--- 2. Komplettes Enum (mit Payload) ---");
    println!("Größe von KomplettesEnum: {} Bytes", size_of::<KomplettesEnum>());
    println!("Alignment von KomplettesEnum: {} Byte-Alignment", align_of::<KomplettesEnum>());
    println!("Erklärung: Die größte Variante (f64, f64) benötigt 16 Bytes.");
    println!("Dazu kommt 1 Byte Tag. Wegen des 8-Byte-Alignments wird auf 24 Bytes aufgefüllt.");
    println!();

    // --- Sektion 3: Nischen-Optimierung ---
    println!("--- 3. Nischen-Optimierung (Niche Optimization) ---");
    println!("Größe von &i32: {} Bytes", size_of::<&i32>());
    println!("Größe von Option<&i32>: {} Bytes (Null-Pointer-Optimierung!)", size_of::<Option<&i32>>());
    println!();
    
    println!("Größe von bool: {} Byte", size_of::<bool>());
    println!("Größe von Option<bool>: {} Byte (Nischen-Optimierung!)", size_of::<Option<bool>>());
    println!();

    println!("Größe von u32: {} Bytes", size_of::<u32>());
    println!("Größe von Option<u32>: {} Bytes (Keine Nische vorhanden -> Tag + Padding nötig!)", size_of::<Option<u32>>());
    println!();

    // --- Sektion 4: Eigene Nische mit NonZero ---
    println!("--- 4. Nischen-Optimierung mit NonZero-Typen ---");
    println!("Größe von std::num::NonZeroU32: {} Bytes", size_of::<std::num::NonZeroU32>());
    println!("Größe von Option<std::num::NonZeroU32>: {} Bytes (Optimierung greift!)", size_of::<Option<std::num::NonZeroU32>>());
    println!();

    // --- Sektion 5: FFI & repr(...) ---
    println!("--- 5. Repräsentations-Attribute ---");
    println!("Größe von ReprU8Enum: {} Bytes", size_of::<ReprU8Enum>());
    println!("Alignment von ReprU8Enum: {} Byte-Alignment", align_of::<ReprU8Enum>());
    println!("Erklärung: Tag (1 Byte u8) + 3 Bytes Padding + u32 Payload (4 Bytes) = 8 Bytes.");
}

Detaillierte Code-Erklärung:

use std::mem::{size_of, align_of};: Wir importieren diese beiden unschätzbar wertvollen Funktionen. size_of::<T>() liefert uns die exakte Größe des Typs T in Bytes zur Kompilierzeit. align_of::<T>() zeigt uns das geforderte Byte-Alignment des Typs.
EinfachesEnum: Da dieses Enum keine Daten trägt, sondern nur Zustände repräsentiert, benötigt es auf Hardware-Ebene lediglich Platz für den Diskriminanten-Tag. Da 3 Zustände problemlos in ein einzelnes Byte passen, ist das Enum 1 Byte groß und hat ein Alignment von 1.
Option\<&i32\> vs. &i32: Hier siehst du die Null-Pointer-Optimierung in Aktion. Beide haben exakt die Größe von 8 Bytes. Die Adresse 0 steht für None, jede andere Adresse für die Referenz.
Option\<bool\>: Da bool nur 0 und 1 belegt, wird 2 für None genutzt. Größe: 1 Byte.
Option\<u32\>: Da ein normaler u32 alle Bitmuster belegt, muss Rust einen separaten Tag anlegen. Größe: 8 Bytes (4 Bytes Payload + 1 Byte Tag + 3 Bytes Alignment-Padding).
ReprU8Enum: Durch #[repr(u8)] erzwingen wir, dass der Tag 1 Byte groß ist. Die Variante hält einen u32 (Alignment 4). Um den u32 korrekt im Speicher auszurichten, werden nach dem 1-Byte-Tag exakt 3 Bytes Padding eingefügt, bevor die 4 Bytes des u32 folgen. Das ergibt zusammen 8 Bytes.

6. Fazit: Speicherbewusstsein macht dich zum Rust-Profi

Rust-Enums zeigen eindrucksvoll, dass Abstraktion und Sicherheit nicht auf Kosten der Hardware-Effizienz gehen müssen. Durch Konzepte wie Tagged Unions und clevere Nischen-Optimierungen sorgt der Compiler im Hintergrund dafür, dass deine Datenstrukturen so kompakt und CPU-freundlich wie möglich im Arbeitsspeicher abgelegt werden.

Wenn du das nächste Mal ein Enum schreibst, denke kurz daran:

Kann ich Zeigertypen (&, Box, Rc) verwenden, um die Null-Pointer-Optimierung zu triggern?
Kann ich über NonZero-Typen Nischen für Option schaffen?
Benötige ich #[repr(...)] für die Kommunikation mit der C-Welt?

Mit diesem Hardware-Wissen im Gepäck wirst du hocheffizienten Systemcode schreiben, bei dem sich selbst alte C-Veteranen anerkennend zunicken. Viel Spaß beim Optimieren!

Keyboard shortcuts

Rust-Lernpfad & Lehrbuch