mold 2.42: Ein Linker, der die Wartezeit beim Debuggen verkürzt

Das Problem: Warten auf den Linker

Jeder, der mit C, C++ oder Rust arbeitet, kennt den Ablauf: Der Compiler erzeugt Objektdateien, dann übernimmt der Linker und kombiniert sie zu einem ausführbaren Programm. Bei großen Projekten wie Chromium oder TensorFlow dauert dieser zweite Schritt oft mehrere Sekunden, manchmal Minuten. mold setzt genau hier an. Der README nennt als Zielgruppe Entwickler, die in schnellen Debug-Edit-Rebuild-Zyklen arbeiten. Wer ständig auf den Linker wartet, verliert Konzentration und Zeit. mold will diese Pause verkürzen, nicht die Compiler-Laufzeit. Das ist eine klare, enge Aufgabenstellung. Es geht nicht um allgemeine Build-Optimierung, sondern um den letzten Schritt vor dem Start des Programms.

Wie mold die Link-Zeit drückt

Die Geschwindigkeit kommt von zwei Prinzipien: massiver Parallelität und effizienten Datenstrukturen. Das README verweist auf ein Paper mit dem Titel "mold: A Massively Parallel Linker" (ASPLOS 2027). Die Idee ist, dass moderne Prozessoren viele Kerne haben, aber traditionelle Linker diese nicht ausnutzen. mold zerlegt die Arbeit in viele kleine Aufgaben, die gleichzeitig ablaufen können. Dazu kommen Algorithmen, die weniger Speicherzugriffe benötigen. Der Autor ist der ursprüngliche Entwickler von LLVM lld, dem Linker, der unter anderem für Android und Chrome verwendet wird. Er hat mold von Grund auf neu geschrieben, um die architektonischen Grenzen von lld zu umgehen. Das Ergebnis ist ein Linker, der bei großen Ausgaben wie TensorFlow (9.55 GiB) im Benchmark von 50.73 Sekunden bei lld auf 3.15 Sekunden kommt. Das ist kein kleiner Unterschied, sondern eine Größenordnung.

Benchmarks: Wo mold glänzt, wo nicht

Das README enthält eine umfangreiche Benchmark-Tabelle mit neun großen Programmen auf zwei Maschinen. Auf dem AMD Ryzen Threadripper 7980X mit 64 Kernen ist mold bei Debug-Builds zwischen 3.8x und 16.1x schneller als lld. Bei Release-Builds fällt der Vorteil geringer aus, aber immer noch deutlich. Auf dem Apple M1 Ultra sind die Gewinne kleiner: Bei Clang 21 im Debug-Build ist mold nur 1.5x schneller als lld, bei Blender sogar nur 1.5x. Bei kleinen Release-Builds wie Godot (0.15 GiB) ist mold nur 1.0x bis 2.3x schneller. Das zeigt: Der Vorteil hängt stark von der Anzahl der Kerne und der Größe der Ausgabe ab. Auf einem 64-Kern-Prozessor lohnt sich mold eher als auf einem Laptop mit wenigen Kernen. Die Zahlen stammen aus dem August 2026 und sind Mediane von drei Läufen. Sie sind also nicht statistisch abgesichert, aber die Tendenz ist klar.

Installation und erste Schritte

Die README gibt keine konkreten Installationsbefehle, aber das Repository ist auf GitHub verfügbar und wird als C++-Projekt gebaut. Der übliche Weg ist, den Quellcode zu klonen und mit make zu kompilieren. Nach dem Bau erhalten Sie eine ausführbare Datei, die Sie anstelle von ld.lld oder ld.gold verwenden können. Die Integration in ein Build-System erfolgt über die Compiler-Flags: Bei GCC und Clang setzen Sie -fuse-ld=mold, um mold als Linker zu verwenden. Bei CMake können Sie den Linker über die Variable CMAKE_LINKER setzen. Die genauen Schritte hängen von Ihrem Betriebssystem ab; für Ubuntu gibt es oft ein Paket mold, das Sie mit apt installieren können. Die README erwähnt, dass mold als Drop-in-Ersatz für bestehende Unix-Linker gedacht ist, also sollte die Umstellung ohne Änderungen an den Objektdateien funktionieren.

Grenzen und falsche Anwendungsfälle

Nicht jedes Projekt profitiert von mold. Wenn Ihre Build-Ausgabe klein ist, unter 100 MB, ist der Unterschied oft vernachlässigbar. Die Benchmarks zeigen, dass mold auf dem M1 Ultra bei Blender Release nur 0.25 Sekunden braucht, lld 0.56 Sekunden, das ist eine Ersparnis von 0.31 Sekunden. Für viele Entwickler ist das nicht spürbar. Ein weiteres Problem: mold unterstützt zwar viele Architekturen, aber nicht alle. Die Liste im README umfasst x86-64, ARM, RISC-V, PowerPC, s390x, LoongArch, SPARC64, m68k und SH-4. Wenn Sie eine exotische Plattform verwenden, die nicht aufgeführt ist, müssen Sie bei lld bleiben. Außerdem gibt es Fälle, in denen mold eine Funktion nicht implementiert hat. Im Benchmark wird wild bei Chromium Release als N/A markiert, weil wild --icf=all nicht unterstützt. mold unterstützt das offenbar, aber es zeigt, dass nicht alle Linker alle Optionen können. Prüfen Sie also, ob Ihr Build bestimmte Linker-Flags benötigt, die mold nicht kennt.

Alternativen: lld und wild

Der natürliche Vergleich ist LLVM lld, der Standard-Linker vieler Projekte. lld ist ebenfalls schnell, aber laut Benchmark bei großen Binärdateien deutlich langsamer als mold. Der Unterschied liegt in der Architektur: lld wurde entwickelt, um bestehende Funktionen zu unterstützen, während mold von Grund auf auf Parallelität ausgelegt ist. Eine neuere Alternative ist wild, ein Linker, der im Benchmark auf dem Threadripper bei Blender 1.98 Sekunden braucht, mold 0.86 Sekunden. wild ist also schneller als lld, aber langsamer als mold. Der README erwähnt, dass wild bei Chromium Release nicht funktioniert, weil es --icf=all nicht implementiert. Das ist ein praktischer Unterschied: Wenn Sie Chromium bauen wollen, ist mold die einzige Wahl unter den getesteten Linkern. Für kleinere Projekte kann wild ausreichen, wenn Sie keine exotischen Flags benötigen. Die Wahl hängt also von Ihren Anforderungen ab, nicht von der reinen Geschwindigkeit.

Wartung, Lizenz und Risiken

mold wird aktiv gepflegt, die letzte Veröffentlichung v2.42.0 stammt vom 12. August 2026. Die Versionsnummern steigen regelmäßig, was auf kontinuierliche Entwicklung hinweist. Die Lizenz ist MIT, das erlaubt Ihnen, mold in eigenen Projekten zu verwenden, auch kommerziell, ohne den Quellcode offenzulegen. Das ist ein Vorteil gegenüber Linkern mit restriktiveren Lizenzen. Allerdings müssen Sie bei Updates mit Änderungen rechnen, da mold noch nicht als stabil gilt. Die README sagt, dass mold seit 2021 in Produktion ist, aber die Architektur ist neu und kann in Randfällen Fehler haben. Bevor Sie mold in Ihrer CI-Pipeline einsetzen, sollten Sie einen Testlauf mit Ihrem konkreten Build machen. Das Risiko ist gering, aber nicht null. Wenn Sie auf eine Funktion angewiesen sind, die mold nicht unterstützt, kann das Ihren Build blockieren.

Redaktionelles Fazit

mold eignet sich für Entwickler, die große C++-, C- oder Rust-Projekte bauen und unter langen Link-Zeiten leiden. Wer mit kleinen Binärdateien arbeitet oder auf exotischen Architekturen unterwegs ist, sollte zuerst prüfen, ob mold die benötigten Features unterstützt. Vor der Einführung sollten Sie die Benchmark-Umgebung reproduzieren und testen, ob mold in Ihrem Build-System als Drop-in funktioniert. Die Lizenz ist MIT, aber die Architektur setzt viele Kerne voraus; auf schwacher Hardware kann der Vorteil schrumpfen.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes