Kapitel 07 - Hardware-Sicht: Was CPU und RAM bei Funktionen und Closures treiben

Hallo! Schön, dass du den Weg in die Maschinenhalle des Buches gefunden hast. Wenn du zu den Leuten gehörst, die bei Code-Abstraktionen sofort unruhig werden und wissen wollen, welche Bits und Bytes die CPU eigentlich hin- und herschiebt, dann bist du hier goldrichtig.

Wir lassen in diesem Abschnitt die komfortable Welt der High-Level-Semantik hinter uns und steigen hinab ins Silizium. Wir schauen uns an, wie Rust Funktionen auf Assembler-Ebene abwickelt und warum Closures unter der Haube nichts anderes als stinknormale Strukturen sind, die der Compiler für uns zusammenzimmert. Legen wir die Sicherheitsgurte an und werfen einen Blick auf die nackte Hardware!

1. Lernziele für die Hardware-Sicht

In diesem Tiefenabschnitt wirst du lernen:

• Wie die CPU einen Stack-Rahmen (Stack Frame) aufbaut und wieder abbaut.
• Welche Rolle die calling conventions (Aufrufkonventionen) der System V AMD64 ABI auf x86_64-Systemen bei der Übergabe von Argumenten und Rückgabewerten spielen.
• Warum Funktionszeiger (fn) indirekte Sprünge erfordern und was das für die Pipeline-Vorhersage der CPU bedeutet.
• Wie der Compiler Closures in anonyme Structs übersetzt.
• Welches exakte Speicherlayout entsteht, wenn du Variablen per Referenz (&T), per veränderlicher Referenz (&mut T) oder per Move (T) einfängst.
• Wie das Schlüsselwort move das Stack- und Heap-Verhalten von Closures beeinflusst.
• Wie LLVM Closures mittels Inlining und SROA (Scalar Replacement of Aggregates) so optimiert, dass am Ende absolut null Laufzeit-Overhead übrig bleibt.

2. Die Hardware-Abwicklung von Funktionsaufrufen

Um zu verstehen, was bei einem Funktionsaufruf passiert, müssen wir uns die CPU wie eine extrem schnelle, aber auch extrem stupide Arbeitskraft vorstellen. Sie arbeitet Befehl für Befehl ab, die im Speicher (dem .text-Segment) liegen. Wenn wir eine Funktion aufrufen, müssen wir drei Probleme lösen:

1. Wie merkt sich die CPU, wo sie nach der Funktion weitermachen muss?
2. Wo lagert die Funktion ihre lokalen Variablen, damit sie sich nicht mit anderen Funktionen ins Gehege kommt?
3. Wie werden Argumente hinein- und Ergebnisse herausgereicht?

Die Schreibtisch-Analogie

Analogie: Stell dir vor, du sitzt an deinem Schreibtisch und bearbeitest deine Steuererklärung. Mitten in der Arbeit fällt dir ein, dass du den Benzinverbrauch deines Autos berechnen musst. Du nimmst einen leeren Notizzettel (einen Stack-Rahmen), schreibst die Rohdaten darauf (die Parameter) und legst diesen Zettel auf deinen aktuellen Arbeitsstapel. Dann holst du dir einen kleinen Taschenrechner (Register), tippst die Werte ein und rechnest. Sobald du fertig bist, schreibst du das Endergebnis auf einen kleinen Klebezettel (das RAX-Register), wirfst den Notizzettel in den Papierkorb (Stack-Rahmen abbauen) und makelst exakt an der Zeile deiner Steuererklärung weiter, an der du vorhin gestoppt hast (die Rücksprungadresse).

Der Stack-Rahmen (Stack Frame) im Detail

Jeder Thread in einem laufenden Programm besitzt einen eigenen Speicherbereich namens Stack. Dieser wächst auf fast allen modernen Architekturen (einschließlich x86_64) von hohen Speicheradressen hin zu niedrigeren Speicheradressen.

Wenn wir eine Funktion aufrufen, reserviert die CPU einen neuen Abschnitt auf diesem Stack: den Stack-Rahmen. Hier ist eine schematische Skizze, wie so ein Rahmen im RAM aussieht:

                  Adresse (hoch)
                  +-----------------------------------+
                  | ... Vorheriger Stack-Rahmen ...   |
                  +-----------------------------------+
        RBP ----> | Gesicherter alter Frame Pointer   | <- Start des aktuellen Rahmens
                  +-----------------------------------+
                  | Rücksprungadresse (Return Addr)   | <- Wo geht es nach 'ret' weiter?
                  +-----------------------------------+
                  | Lokale Variablen der Funktion     |
                  | z. B. let x: i32 = 42;            |
                  +-----------------------------------+
                  | Temporäre Zwischenspeicher        |
        RSP ----> | Aktuelles Ende des Stacks         | <- Zeigt auf das letzte genutzte Byte
                  +-----------------------------------+
                  Adresse (niedrig)

Zwei CPU-Register steuern diesen Tanz auf dem Stack:

• RSP (Stack Pointer): Zeigt immer auf die niedrigste belegte Adresse des Stacks. Wenn wir Daten auf den Stack schieben (push), dekrementiert die CPU den Wert von RSP und schreibt die Daten an diese Adresse.
• RBP (Base / Frame Pointer): Zeigt auf den Anfang des aktuellen Stack-Rahmens. Er dient als stabiler Ankerpunkt, um auf lokale Variablen und Argumente über relative Offsets (z. B. [RBP - 8]) zuzugreifen, selbst wenn sich RSP während der Berechnungen ständig hin- und herbewegt. (Hinweis für Profiler: Bei optimierten Builds wird der Frame Pointer oft weggelassen, um ein weiteres Register für Berechnungen freizuschaufeln. Man spricht dann von -fomit-frame-pointer. Der Compiler berechnet die Offsets dann einfach relativ zu RSP.)

Die Calling Convention: System V AMD64 ABI

Wenn eine Funktion eine andere aufruft, müssen sich beide an ein Protokoll halten, das festlegt, wer welche CPU-Register verwenden darf. Unter Linux (und macOS) auf x86_64-Prozessoren ist dies in der System V AMD64 ABI geregelt.

Die Regeln für die Übergabe von Argumenten und Rückgabewerten sind extrem effizient:

1. Ganzzahlen und Zeiger (bis zu 64 Bit): Die ersten sechs Argumente werden nicht über den langsamen RAM (Stack) übergeben, sondern direkt in superschnelle CPU-Register geschrieben:
   • 1. Argument: RDI
   • 2. Argument: RSI
   • 3. Argument: RDX
   • 4. Argument: RCX
   • 5. Argument: R8
   • 6. Argument: R9
2. Fließkommazahlen: Die ersten acht Argumente landen in den SSE-Registern XMM0 bis XMM7.
3. Weitere Argumente: Erst wenn du sieben oder mehr Argumente übergibst, werden die überschüssigen Argumente auf den Stack geschoben. (Deshalb lautet eine goldene Regel der Systemprogrammierung: Halte die Anzahl der Funktionsparameter klein!)
4. Rückgabewerte: Das Ergebnis einer Funktion wird im Register RAX abgelegt. Ist das Ergebnis 128 Bit groß, wird zusätzlich RDX verwendet. Größere Strukturen werden meist über einen versteckten Zeiger zurückgegeben, den der Aufrufer in RDI bereitstellt.

Schauen wir uns ein einfaches, kompilierbares Rust-Beispiel an:

// Wir markieren die Funktion mit #[no_mangle], damit der Compiler
// den Funktionsnamen im Maschinencode nicht kryptisch verändert.
// So können wir den Assembly-Code leichter lesen.
#[no_mangle]
pub fn berechne_wert(a: i64, b: i64) -> i64 {
    let summe = a + b;
    summe * 2
}

fn main() {
    let ergebnis = berechne_wert(10, 20);
    println!("Ergebnis: {}", ergebnis);
}

Wenn wir diesen Code kompilieren (z. B. auf einem Linux x86_64 System), übersetzt der Rust-Compiler die Funktion berechne_wert in folgenden Assembler-Code (stark vereinfacht dargestellt):

berechne_wert:
    # 1. Parameter 'a' liegt laut ABI im Register RDI
    # 2. Parameter 'b' liegt im Register RSI
    
    mov rax, rdi    # Kopiere 'a' (RDI) nach RAX
    add rax, rsi    # Addiere 'b' (RSI) auf RAX. RAX enthält nun 'summe' (a + b)
    shl rax, 1      # Bitweise Linksverschiebung um 1. Das entspricht einer Multiplikation mit 2!
    
    # Der Rückgabewert muss laut ABI in RAX liegen. 
    # Da unser Ergebnis bereits in RAX liegt, sind wir fertig!
    ret             # Springe zurück zur Adresse, die auf dem Stack liegt

Beachte, wie extrem effizient Rust und LLVM das gelöst haben: Es wurde für berechne_wert kein einziger Byte auf dem Stack reserviert! Die CPU arbeitet ausschließlich im Register-Satz. Das ist maximale Performance.

3. Funktionszeiger (fn) und indirekte Sprünge

Im Hauptkapitel hast du gelernt, dass wir Funktionen auch als Werte speichern und übergeben können. Der Typ dafür lautet fn (kleingeschrieben).

Auf Hardware-Ebene ist ein Funktionszeiger nichts anderes als eine 64-Bit-Ganzzahl, die die Speicheradresse des ersten CPU-Befehls der Funktion im .text-Segment enthält.

Wenn wir einen normalen Funktionsaufruf schreiben (z. B. berechne_wert(10, 20)), generiert der Compiler einen direkten Sprung:

call berechne_wert  # Die CPU springt zu einer festen, bekannten Adresse

Verwenden wir hingegen einen Funktionszeiger, muss die CPU einen indirekten Sprung ausführen. Die Adresse der Zielfunktion ist zur Kompilierzeit nicht starr bekannt, sondern wird erst zur Laufzeit aus einem Register oder dem Speicher geladen:

# Der Funktionszeiger wurde zuvor in das Register RAX geladen
call rax  # Indirekter Aufruf: Springe zu der Adresse, die in RAX steht

Warum indirekte Sprünge die Hardware ins Schwitzen bringen

Moderne CPUs nutzen eine technik-nahe Eigenschaft namens Instruction Pipelining. Sie lesen Befehle bereits ein und verarbeiten sie vor, noch bevor der aktuelle Befehl komplett abgeschlossen ist. Bei einem direkten Sprung weiß die CPU genau, welche Befehle als Nächstes kommen.

Bei einem indirekten Sprung (call rax) weiß sie das jedoch erst, wenn der Wert von RAX berechnet und geladen wurde. Um nicht warten zu müssen (was zu einem Pipeline Stall führen würde), greift die CPU auf den Branch Predictor (Zweigvorhersage) zurück. Dieser versucht zu erraten, wohin die Reise geht.

• Liegt der Branch Predictor richtig: Super, kein Zeitverlust.
• Liegt er falsch (Branch Misprediction): Die CPU must all fälschlicherweise bereits teilgeladenen Befehle verwerfen, die Pipeline leeren und von der korrekten Adresse neu starten. Das kostet etwa 10 bis 20 wertvolle CPU-Taktzyklen.

Fazit für den Systemprogrammierer: Funktionszeiger sind mächtig, aber sie bremsen die CPU-interne Optimierung leicht aus. Verwende sie also bewusst.

4. Das Speicherlayout von Closures: Die anonymen Structs

Jetzt kommen wir zum spannendsten Teil: Closures. In vielen Sprachen (wie Java oder C#) sind Lambdas mit spürbarem Laufzeit-Overhead verbunden (Garbage Collection, Boxing auf dem Heap). Rust geht hier einen radikal anderen Weg: Eine Closure hat keinen magischen Laufzeit-Zustand. Sie ist auf Hardware-Ebene ein einfaches Struct auf dem Stack.

Wenn du eine Closure schreibst, macht der Compiler im Wesentlichen zwei Dinge:

1. Er generiert eine anonyme Struktur, in der die eingefangenen Variablen als Felder gespeichert werden.
2. Er implementiert für diese Struktur einen der Traits Fn, FnMut oder FnOnce über eine normale Methode.

Schauen wir uns die drei Capture-Szenarien und ihr exaktes Speicherlayout im RAM an.

Szenario A: Einfangen per Referenz (&T)

Wenn deine Closure die Variablen aus dem äußeren Scope nur liest, fängt der Compiler sie per Referenz ein.

fn main() {
    let x: i32 = 42;
    let y: i64 = 100;
    
    // Die Closure fängt x und y lesend ein
    let mein_leser = || {
        println!("x: {}, y: {}", x, y);
    };
    
    mein_leser();
}

Wenn der Compiler diesen Code sieht, übersetzt er mein_leser unter der Haube in eine Struktur, die ungefähr so aussieht:

#![allow(unused)]
fn main() {
// Vom Compiler generierte anonyme Struktur (vereinfacht)
struct AnonymeClosure<'a> {
    x: &'a i32, // Unveränderlicher Zeiger auf die Stack-Variable x
    y: &'a i64, // Unveränderlicher Zeiger auf die Stack-Variable y
}

impl<'a> Fn<()> for AnonymeClosure<'a> {
    extern "rust-call" fn call(&self, _args: ()) {
        // Der Code der Closure greift über Dereferenzierung auf die Felder zu
        println!("x: {}, y: {}", *self.x, *self.y);
    }
}
}

Das Speicherlayout auf dem Stack:

Das Objekt mein_leser ist auf Hardware-Ebene genau so groß wie seine Felder. Auf einem 64-Bit-System belegt ein Zeiger 8 Byte. Die Struktur AnonymeClosure enthält zwei Zeiger. Ihre Größe auf dem Stack beträgt somit exakt 16 Byte.

Stack-Rahmen von main():
+-----------------------------------+
| x = 42 (4 Byte)                   | <======+
+-----------------------------------+        | (Zeiger x zeigt hierhin)
| y = 100 (8 Byte)                  | <===+  |
+-----------------------------------+     |  |
| mein_leser (Closure Struct):      |     |  |
| - Feld 'x': Zeiger auf x (8 Byte) | ----+--+
| - Feld 'y': Zeiger auf y (8 Byte) | ----+
+-----------------------------------+

Szenario B: Einfangen per veränderlicher Referenz (&mut T)

Wenn die Closure den Wert einer Variable modifiziert, muss sie exklusiven Schreibzugriff haben. Der Compiler fängt die Variable daher per &mut ein.

fn main() {
    let mut counter: i32 = 10;
    
    // Die Closure modifiziert 'counter'. 
    // Da sie counter exklusiv ausleiht, muss sie selbst als 'mut' deklariert sein!
    let mut inkrementor = || {
        counter += 1;
    };
    
    inkrementor();
}

Der Compiler generiert daraus folgende Struktur und Implementierung:

#![allow(unused)]
fn main() {
struct AnonymeClosureMut<'a> {
    counter: &'a mut i32, // Veränderlicher Zeiger auf 'counter'
}

impl<'a> FnMut<()> for AnonymeClosureMut<'a> {
    extern "rust-call" fn call_mut(&mut self, _args: ()) {
        *self.counter += 1; // Dereferenzieren und Wert erhöhen
    }
}
}

Das Speicherlayout:

Die Struktur enthält einen einzigen veränderlichen Zeiger (&mut i32). Auf einem 64-Bit-System belegt diese Closure somit exakt 8 Byte auf dem Stack!

Szenario C: Einfangen per Move (T)

Wenn wir das Schlüsselwort move verwenden oder die eingefangenen Variablen in der Closure konsumiert werden, übernimmt die Closure das komplette Eigentum (Ownership) an den Variablen. Sie werden direkt in die Struktur kopiert oder verschoben.

fn main() {
    let daten: Vec<u8> = vec![1, 2, 3];
    
    // 'move' erzwingt die Verschiebung der Daten in das Struct der Closure
    let drucker = move || {
        println!("Daten: {:?}", daten);
    };
    
    drucker();
}

Hieraus generiert der Compiler:

#![allow(unused)]
fn main() {
struct AnonymeClosureMove {
    daten: Vec<u8>, // Der komplette Vector-Deskriptor wurde verschoben!
}

impl FnOnce<()> for AnonymeClosureMove {
    type Output = ();
    extern "rust-call" fn call_once(self, _args: ()) {
        println!("Daten: {:?}", self.daten);
    } // Am Ende dieses Scopes wird self (und damit daten) gedroppt!
}
}

Das Speicherlayout im RAM:

Ein Vec in Rust besteht auf dem Stack immer aus einem 24-Byte-Deskriptor (8 Byte Zeiger auf den Heap-Speicher, 8 Byte Kapazität, 8 Byte Länge).

Durch das move wandert dieser 24-Byte-Deskriptor direkt in die AnonymeClosureMove-Struktur auf den Stack. Die ursprüngliche Variable daten in main() ist danach ungültig.

Stack-Rahmen von main():
+-----------------------------------+
| drucker (Closure Struct):         |
| - Feld 'daten' (24 Byte)          |
|   - Zeiger auf Heap (8 Byte) -----+======+
|   - Kapazität = 3 (8 Byte)        |      |
|   - Länge = 3 (8 Byte)            |      |
+-----------------------------------+      |
                                           |
Heap-Speicher:                             v
+--------------------------------------------+
| [1, 2, 3] (3 Byte belegt)                  |
+--------------------------------------------+

Was passiert nun mit dem Stack-Heap-Verhalten?

• Wenn wir die Closure drucker als lokale Variable auf dem Stack behalten, liegen auch die eingefangenen Daten (daten) auf dem Stack (während die eigentlichen Elemente [1, 2, 3] auf dem Heap liegen).
• Wenn wir die Closure nun in eine Box packen (z. B. let boxed_closure = Box::new(drucker);), verschiebt Rust das gesamte Closure-Struct (die 24 Byte) auf den Heap. Wir haben dann einen Zeiger auf dem Stack, der auf den 24-Byte-Deskriptor auf dem Heap zeigt, welcher wiederum auf die 3 Byte Elementdaten auf dem Heap verweist.

5. Warum eine Closure mit Zustand kein Funktionszeiger ist

Ein extrem häufiger Compilerfehler bei Rust-Einsteigern entsteht, wenn man versucht, eine Closure, die Variablen einfängt, dort zu verwenden, wo ein normaler Funktionszeiger (fn) erwartet wird.

Hier ist das klassische Drama im Code:

// Diese Funktion erwartet einen normalen Funktionszeiger
fn fuehre_aus(operation: fn(i32) -> i32) {
    println!("Ergebnis: {}", operation(10));
}

fn main() {
    let faktor = 3;
    
    // DIESER CODE KOMPILIERT NICHT!
    // Wir versuchen eine Closure mit Zustand (faktor) als fn-Zeiger zu übergeben.
    fuehre_aus(|x| x * faktor);
}

Der Compiler weist uns barsch ab:

error[E0308]: mismatched types
  --> src/main.rs:11:16
   |
11 |     fuehre_aus(|x| x * faktor);
   |     ---------- ^^^^^^^^^^^^^^ expected fn pointer, found closure
   |     |
   |     arguments to this function are incorrect
   |
   = note: expected fn pointer `fn(i32) -> i32`
                  found closure `[closure@src/main.rs:11:16:11:19]`
note: closures can only be coerced to `fn` types if they do not capture any variables

Die Hardware-Erklärung für diesen Fehler

Warum ist der Compiler hier so stur? Schauen wir uns die Größe der Typen im Speicher an:

• Ein Funktionszeiger fn(i32) -> i32 ist genau 8 Byte groß (eine reine Codeadresse). Er hat keinerlei Speicherplatz, um irgendwelche Variablen zu sichern.
• Unsere Closure fängt die Variable faktor (ein i32, also 4 Byte) per Referenz ein. Das anonyme Struct der Closure enthält also einen Zeiger auf faktor und belegt somit 8 Byte an Speicherdaten.
• Wenn wir die Closure aufrufen wollen, müssen wir ihr zwingend die Adresse dieses anonymen Structs als verdecktes Argument (den self-Zeiger) übergeben, damit sie weiß, mit welchem faktor sie multiplizieren soll.

Ein Funktionszeiger weiß aber gar nichts von einem self-Zeiger! Er erwartet einfach nur ein i32 im Register RDI und springt stur los. Hätten wir Zustand in der Closure, gäbe es für die Zielfunktion keine Möglichkeit, an diesen Zustand heranzukommen.

Die Ausnahme von der Regel: Wenn eine Closure keine Variablen einfängt, hat ihr anonymes Struct die Größe 0 Byte (ZST - Zero Sized Type). In diesem Fall gibt es keinen Zustand, der übergeben werden müsste. Daher erlaubt der Compiler in diesem speziellen Szenario eine automatische Konvertierung (Coercion) in einen normalen Funktionszeiger fn!

6. LLVM, Inlining und die Magie der Null-Kosten-Abstraktion

Bisher klingt das alles nach einer Menge Zeiger-Dereferenzierungen und Struct-Aufbauten auf dem Stack. Man könnte meinen: “Das kostet doch Laufzeit!”

Die sensationelle Nachricht ist: In der Release-Kompilierung (cargo build --release) optimiert LLVM diesen Overhead in fast allen Fällen komplett weg. Das Prinzip dahinter nennt sich Zero-Cost Abstractions.

Wie LLVM Closures auflöst

Da jede Closure in Rust einen einzigartigen anonymen Typ besitzt, weiß der Compiler beim Aufruf einer generischen Funktion ganz genau, um welche Closure es sich handelt. Es gibt keine Mehrdeutigkeit (keinen dynamischen Dispatch zur Laufzeit).

Schauen wir uns an, wie das in der Praxis abläuft. Nehmen wir an, wir haben folgenden Code:

#[inline(never)] // Wir verbieten das Inlining für diese Funktion zum Testen
pub fn filtere_wert<F>(wert: i32, filter: F) -> bool 
where 
    F: Fn(i32) -> bool 
{
    filter(wert)
}

fn main() {
    let limit = 100;
    // Closure fängt 'limit' (4 Byte) per Referenz ein
    let ist_groesser = |x| x > limit;
    
    let ergebnis = filtere_wert(50, ist_groesser);
    println!("Ergebnis: {}", ergebnis);
}

Wenn du diesen Code mit Optimierungen übersetzen lässt, führt LLVM folgende Schritte aus:

1. Monomorphisierung: Der Compiler generiert eine exakte Kopie der Funktion filtere_wert, die speziell für den anonymen Typ unserer Closure ist_groesser optimiert ist.
2. Inlining der Closure: LLVM sieht den Aufruf filter(wert) innerhalb dieser spezialisierten Funktion. Da der exakte Typ bekannt ist, ersetzt LLVM den Funktionsaufruf direkt durch den Körper der Closure: wert > limit.
3. Scalar Replacement of Aggregates (SROA): LLVM erkennt, dass das anonyme Closure-Struct nur kurz erzeugt wird, um auf limit zuzugreifen. LLVM bricht das Struct komplett auf und lädt den Wert von limit direkt in ein CPU-Register. Das Struct auf dem Stack wird rückstandslos gelöscht.
4. Inlining von filtere_wert: Wenn LLVM nun auch noch die Funktion filtere_wert in main inlined, verschwindet der gesamte Funktionsaufruf.

Am Ende bleibt im Maschinencode oft nur noch ein einziger Assembler-Vergleichsbefehl übrig:

# Der gesamte Aufruf von filtere_wert und der Closure wurde zu diesem Vergleich reduziert:
cmp edi, 100    # Vergleiche den übergebenen Wert (EDI) direkt mit dem Limit (100)
setg al         # Schreibe 1 nach AL (Rückgabewert), wenn der Wert größer war, sonst 0

Es gibt zur Laufzeit kein Struct, keinen Zeiger, keinen Funktionsaufruf und keinen Stack-Rahmen für die Closure. Der Code läuft exakt so schnell, als hättest du den Vergleich 50 > 100 manuell hartcodiert an Ort und Stelle hingeschrieben. Das ist die wahre Power von Rust!

7. Zusammenfassung der Hardware-Sicht

Zusammenfassend können wir festhalten:

1. Funktionsaufrufe werden auf Hardware-Ebene über Stack-Rahmen organisiert. Register (RDI, RSI etc.) transportieren Argumente blitzschnell zur Funktion, RAX bringt das Ergebnis zurück.
2. Funktionszeiger (fn) sind reine 64-Bit-Speicheradressen im Code-Segment. Sie zwingen die CPU zu indirekten Sprüngen, was die Pipeline-Vorhersage erschweren kann.
3. Closures sind keine Magie, sondern anonyme Strukturen, die der Compiler baut. Jede Closure hat einen einzigartigen Typ.
4. Das Speicherlayout einer Closure entspricht exakt den Variablen, die sie einfängt:
   • &T fängt Zeiger ein (8 Byte pro Zeiger auf einem 64-Bit-System).
   • &mut T fängt veränderliche Zeiger ein.
   • move T verschiebt den kompletten Wert (inklusive eventueller Heap-Deskriptoren) in das Struct.
5. Closures mit Zustand können nicht als normale Funktionszeiger (fn) verwendet werden, da fn-Zeiger keinen Speicherplatz für den Zustand (die eingefangenen Variablen) besitzen.
6. Dank Monomorphisierung, Inlining und modernster LLVM-Optimierungen verschwindet die Struktur von Closures in optimierten Builds meist vollständig aus dem Maschinencode. Du bezahlst keinen einzigen Taktzyklus extra für diese elegante Abstraktion!