Kapitel 15 - Hardware-Sicht: Iteratoren unter der Lupe von CPU und RAM

Hallo Thorsten! Nachdem wir uns mit der mathematischen Eleganz und den deklarativen Mustern von Iteratoren beschäftigt haben, reißen wir jetzt die Motorhaube auf.

In vielen Programmiersprachen sind Iteratoren ein zweischneidiges Schwert: Sie machen den Code zwar schöner, kosten aber CPU-Zyklen und RAM, da für jeden Schritt Objekte allokiert und virtuelle Methoden aufgerufen werden müssen. Rust verspricht hier Zero-Cost Abstractions (abstraktionsfreie Laufzeitkosten).

Lass uns untersuchen, wie der Compiler Iteratoren übersetzt und warum sie auf Hardware-Ebene oft schneller sind als klassische Schleifen.

1. Die Vermeidung von Bounds Checking (Sicherheitsüberprüfungen)

Ein großer Unterschied zwischen einer klassischen indizierten Schleife und einem Iterator betrifft die Sicherheitsprüfungen des Compilers.

Die klassische Index-Schleife:

#![allow(unused)]
fn main() {
let daten = [1, 2, 3, 4, 5];
for i in 0..daten.len() {
    let x = daten[i]; // Zugriff über Index
    // ...
}
}

Da Rust Speichersicherheit garantiert, darf das Programm niemals über die Grenzen des Arrays hinauslesen (Buffer Overflow). Der Compiler muss daher bei jedem einzelnen Schleifendurchlauf zur Laufzeit prüfen: Ist der Index i kleiner als daten.len()?

• Hardware-Auswirkung: Diese ständigen Vergleiche und Verzweigungen (Bounds Checking) kosten CPU-Zyklen und können das Pipelining des Prozessors stören.

Die Iterator-Alternative:

#![allow(unused)]
fn main() {
let daten = [1, 2, 3, 4, 5];
for x in daten.iter() {
    // Direkter Zugriff über den Iterator
}
}

Ein Iterator weiß intern durch seine Struktur genau, wie viele Elemente er hat. Er greift über sichere, rohe Zeiger auf die Elemente zu und stoppt exakt am Ende.

• Hardware-Auswirkung: Der Compiler analysiert die Iterator-Struktur und entfernt sämtliche Bounds Checks vollständig aus dem Maschinencode. Es gibt keine Laufzeitprüfungen mehr. Das Programm läuft auf nackter Hardware-Geschwindigkeit!

2. Inlining und Loop Unrolling: Der Weg zum flachen Maschinencode

Wenn du Adapterketten mit Closures wie map(|x| x * 2) schreibst, sieht das nach viel Arbeit für die CPU aus. Doch der Compiler optimiert dies radikal:

1. Closure Inlining: Der Compiler kopiert den Code der Closure direkt in den Schleifenkörper. Es gibt keinen Funktionsaufruf, keine Registerverschiebungen und keinen Stack-Overhead.
2. Monomorphisierung des Modul-Typs: Ein Iterator wie Map<Filter<Iter<i32>, Closure1>, Closure2> ist ein extrem komplexer, verschachtelter Typ zur Compilezeit. Der Compiler löst diese Verschachtelung vollständig auf und generiert eine flache, lineare Assemblerschleife.

Tatsächlich kompiliert eine Iterator-Kette im Release-Modus (cargo build --release) zu exakt demselben, hocheffizienten Assembler-Code wie eine handgeschriebene, optimierte C-Schleife.

3. Statischer vs. Dynamischer Dispatch bei Iteratoren

Manchmal steht man vor dem Problem, dass man je nach Bedingung unterschiedliche Iteratoren zurückgeben möchte:

#![allow(unused)]
fn main() {
// Das funktioniert standardmäßig NICHT, da die beiden Zweige 
// unterschiedliche konkrete Typen erzeugen!
/*
fn erstelle_iterator(cond: bool) -> impl Iterator<Item = i32> {
    let daten = vec![1, 2, 3];
    if cond {
        daten.into_iter().map(|x| x * 2) // Typ A
    } else {
        daten.into_iter().filter(|x| x % 2 == 0) // Typ B
    }
}
*/
}

Da Rust zur Compilezeit die exakte Größe und den Typ des Rückgabewerts kennen muss (Statischer Dispatch), verbietet der Compiler das.

Die Lösung: Dynamic Dispatch auf dem Heap

Um dieses Problem zu lösen, müssen wir den Iterator hinter einem Smart Pointer auf dem Heap verstecken (Box) und dynamischen Dispatch nutzen (dyn):

#![allow(unused)]
fn main() {
fn erstelle_iterator(cond: bool) -> Box<dyn Iterator<Item = i32>> {
    let daten = vec![1, 2, 3];
    if cond {
        Box::new(daten.into_iter().map(|x| x * 2))
    } else {
        Box::new(daten.into_iter().filter(|x| x % 2 == 0))
    }
}
}

Die Hardware-Kosten von Dynamic Dispatch:

Wenn Sie Box<dyn Iterator> verwenden, geben Sie das Versprechen der Zero-Cost Abstraction teilweise auf:

1. Heap-Allokation: Die Box erzwingt das Speichern des Iterators auf dem Heap statt auf dem Stack. Das Erstellen kostet Allokationszeit.
2. Vtable-Dereferenzierung: Jeder Aufruf von .next() erfolgt über einen Zeiger in eine virtuelle Methodentabelle (Vtable). Die CPU kann den Aufruf nicht vorab optimieren (Inlining ist unmöglich).
3. Instruction Cache Misses: Der Sprung über die Vtable kann das Vorladen von Instruktionen im CPU-Cache erschweren.

Systemprogrammierer-Regel: Nutzen Sie statischen Dispatch (impl Iterator) wann immer möglich. Verwenden Sie Dynamic Dispatch (Box<dyn Iterator>) nur dann, wenn unterschiedliche Pfade zur Laufzeit unumgänglich sind.