mold 2.0.0 - schneller Linker

• Die Lizenz wurde von AGPL auf MIT umgestellt und ist damit die wichtigste Änderung in mold 2.0.0
• Ein Bug wurde behoben, durch den bei Verwendung von --relocatable keine Objektdatei mit mehr als 65520 Sektionen erzeugt werden konnte
• -undefined wird als Synonym für --undefined statt für -u ndefined interpretiert und entspricht damit dem Verhalten von GNU-Linkern und LLVM lld
• -nopie wird als Synonym für --no-pie behandelt
• Unterstützung für die Relocation-Typen R_RISCV_SET_ULEB128 und R_RISCV_SUB_ULEB128 auf RISC-V
• Unterstützung für den Relocation-Typ R_PPC64_REL32 auf PPC64

[GN⁺]

Meinungen auf Hacker News

• mold ist auf modernen Systemen wirklich eine hervorragende Arbeit.
  Als ich kürzlich versucht habe, Builds in einem Projekt schneller zu machen, stellte ich fest, dass der Link-Schritt ein enormer Flaschenhals ist. Obwohl ich 24 Kerne * 2 Threads nutze, liegen wegen des Linkers etwa 30 % der Gesamtleistung brach.
  Ich hatte früher schon einmal versucht, mit mold zu bauen, aber damals funktionierte es nicht richtig; ich werde es erneut ausprobieren.

  • Mold ist großartig. Als ich vor ein paar Monaten mit O3DE gearbeitet habe, habe ich auf Mold umgestellt, um zu sehen, ob sich der Build-Run-Zyklus verkürzen lässt, und es wurde tatsächlich schneller.
    An die genauen Zahlen erinnere ich mich nicht, aber es war ein ziemlich großer Unterschied: Was mit gold und lld ein paar Sekunden dauerte, fiel mit mold auf unter 1 Sekunde.
  • Auch in der Firma haben wir ein paar Proofs of Concept gemacht, und auf einer kleinen Test-Build-Maschine sank die vollständige Build-Zeit der UI-Schicht beim Wechsel von lld zu mold von 44–45 Minuten auf 29 Minuten.
    Es war komplexer C++/Qt-Code.
  • mold -run ninja funktioniert in meiner Umgebung sehr gut.

• Die Nachricht zur Lizenzänderung freut mich sehr. Ich hoffe, dass das Projekt auch Geld verdienen kann, aber mit einer MIT-Lizenz steigt die Chance deutlich, es in Arbeitsprojekte zu integrieren.
  Falls wir es tatsächlich einsetzen, werde ich versuchen, meine Firma davon zu überzeugen, das Projekt zu sponsern.

  • Die Lizenz eines Linkers sollte eigentlich keine große Rolle spielen. Er injiziert keinen urheberrechtlich geschützten Code, und selbst im GPL-Ökosystem gibt es bereits Präzedenzfälle, bei denen triviales Boilerplate als Ausnahme gilt; es gibt also keinen Grund, warum erzeugte Binärdateien von der Copyleft-Lizenz des Tools betroffen sein sollten.
    AGPL würde wohl nur dann Einschränkungen machen, wenn man einen privat modifizierten Linker als Netzwerkdienst bereitstellt; bei einem grundlegenden Entwicklungstool ist das kein realistisches Szenario.

• Die Lizenzänderung macht mich neugierig. Ist das nicht eine ausführbare Datei? Software, die sie als separaten Prozess aufruft, muss dadurch nicht GPL werden; in den üblichen Fällen sollte die Umstellung auf MIT also keine Auswirkungen haben.
  Wenn die Autoren wirklich eine freizügigere Lizenz wollten, hätten sie statt einer Relizenzierung von AGPL auf MIT zu AGPL mit Linking Exception wechseln sollen. Ein Beispiel für ein GPL-Projekt mit Linking Exception ist libgit2: https://github.com/libgit2/libgit2#license
  Eine solche Lizenz ist freizügiger und erlaubt es trotzdem weiterhin, kommerzielle Lizenzen an diejenigen zu verkaufen, die proprietäre Änderungen vornehmen.

  • Der Kern scheint zu sein, dass die Autoren keine Lizenzen mehr verkaufen wollen. Offenbar war es den Aufwand nicht wert.
    Die macOS-Version sold scheint eine Ausnahme zu sein.

• Dieser Linker hat die Developer Experience in meinem explorativen Rust-Repository, das zu einem großen Web-Monolithen mit SeaORM und axum/tokio werden soll, spürbar verbessert.
  Die Größe meines target-Verzeichnisses wollt ihr gar nicht wissen, aber inkrementelle Builds fühlen sich deutlich flotter an.

  • Ich sollte mir mold wohl mal genauer ansehen.
    15:55 $ du -Hs --si target/
11G target/

• Mold ist großartig, und ich habe ein paar Lieblingsanwendungen dafür.

  1. Rust-Builds werden schneller.
     [target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
"-C", "link-arg=-fuse-ld=mold",
"-C", "target-cpu=native"
]
  2. Unter ArchLinux wird auch makepkg schneller, wenn man "-fuse-ld=mold" zu den CFLAGS hinzufügt.
  • Gibt es eine Möglichkeit, diese Linker-Einstellung nur für die lokale Installation zu überschreiben? Ich möchte den Produktionscode oder die Binärdateien nicht ändern, aber schnellere Builds wären schön.
  • Ich frage mich, wie sehr sich die Link-Zeit bei Rust vorher/nachher verändert hat.
  • Wie schlägt sich dieses neueste Release im Vergleich zu lld? Läuft es auch auf alpine/musl?

• Eine sehr kluge Entscheidung. Auch bei meinen Produkten oder meinem Code gibt es manchmal schwierige Momente, in denen man anerkennen muss, dass bestimmte Dinge nicht zur Monetarisierung taugen.
  Der Markt sagt einem das, und so schade es ist: Statt dagegen anzukämpfen, ist es wichtig, etwas anderes zu finden, das der Markt belohnt.

• Weiß jemand, ob diese Änderung der Lizenz-/Geschäftsstrategie auch auf sold angewendet werden soll? sold ist mold für macOS.
  https://github.com/bluewhalesystems/sold

  • Apple hat einen neuen parallelen Linker, der interessant sein könnte oder auch nicht.
    https://twitter.com/davidecci/status/1665835119331135488
  • Wenn man sich den Anfang der mold-README ansieht, würde ich vermuten, dass es nicht Open Source wird.
    „Dieses Repository enthält die kostenlose Version des mold-Linkers. Wenn Sie eine kommerzielle Version mit macOS-Unterstützung suchen, besuchen Sie das Repository des sold-Linkers.“
  • Ich verstehe nicht, warum Apple dieses Projekt nicht sponsert und es zum Standard-Linker von Xcode macht.
    Sie könnten für die Arbeit ordentlich Geld zahlen und die Welt besser machen.
    Für Apple wäre das doch viel zu einfach.

• Die Lizenz wechselt von AGPL zu MIT.
  Aber wie sollte ein so hervorragender Handwerker eigentlich entlohnt werden, und warum passiert das noch nicht? Unternehmen sollten, unabhängig von ihrer Größe, ein gewisses Budget für zentrale Abhängigkeiten oder Tools bereitstellen und das auf ihrer offiziellen Website veröffentlichen. Es braucht wohl mehr von einer Art kultureller Norm.

• Ich hatte vergessen, dass das ein schneller Linker war
  „Mold 2.0.0 ist das neue Major Release unseres schnellen Linkers. In diesem Release haben wir die Lizenz von AGPL auf MIT umgestellt, mit dem Ziel, die Nutzerbasis zu vergrößern. Wer die Entwicklung verfolgt hat, weiß, dass das keine leichte Entscheidung war, weil wir versucht hatten, das Produkt über ein Dual-Licensing-Modell aus AGPL und kommerzieller Lizenz zu monetarisieren. Leider hat dieser Ansatz die Erwartungen nicht erfüllt. Die Lizenzänderung ist das Ergebnis, diese Realität zu akzeptieren. Wir wollen nicht weiter an einer Strategie festhalten, die nicht gut funktioniert hat.“

  • Erinnert sich noch jemand an die Zeiten, als man unter Solaris für cc bezahlen musste? https://unix.stackexchange.com/questions/12731/usr-ucb-cc-la...
    Das war furchtbar und auch eine miserable Art, mit Entwicklern umzugehen, die Software für das eigene OS schreiben.
    Wir sind schon sehr lange daran gewöhnt, für Low-Level-Entwicklungswerkzeuge nicht zu bezahlen und stattdessen für Support zu zahlen. Dass überhaupt versucht wurde, so eine Lizenzierung zu machen, ist erstaunlich.

• Über einen langen Zeitraum habe ich viele Diskussionen über schnelle Linker gesehen und mehrfach gehört, dass das Ersetzen eines Linkers durch einen schnelleren die Kompilierzeit deutlich reduziert habe, aber normalerweise wusste ich nicht genau, warum Linker langsam sind.
  Es wäre schön, wenn das jemand erklären könnte.

  • Das ist keine vollständige Erklärung, aber Linken ist CPU-intensiv, und ältere Linker sind meist Single-Threaded.
    Ein großer Teil der Performance-Gewinne entsteht dadurch, dass die Arbeit parallel verarbeitet wird, was auf modernen, leistungsstarken Multicore-CPUs zu großen Verbesserungen führt.
    Wenn du mehr wissen willst: Rui hat einen guten Vortrag über Mold gehalten: https://www.youtube.com/watch?v=hAt3kCalE0Y
  • Im Idealfall sollte ein Linker so schnell sein wie cat. Er müsste die Binärdateien nur aneinanderhängen, und fertig. In Zeiten rotierender Festplatten war Disk-I/O ein Problem, heute weniger.
    Der Teil, der Zeit kostet, ist das Umschreiben von Inhalten während des Vorgangs. Durch die Relocation-Tabellen zu gehen und Adressen in den Code einzutragen, ist billig, und Dead Stripping auf Section-Ebene ist auch recht billig; wenn man aber einzelne Basic Blocks innerhalb von Funktionen dead-strippen will, braucht das deutlich mehr Analyse und kostet Zeit.
    Das Deduplizieren konstanter Strings ist eine gute Idee, aber dafür muss alles in irgendeine Form von Hash-Tabelle geleitet werden. Wenn man auch gemeinsame Suffixe teilen möchte, wird es noch mehr Arbeit.
    Deduplizierung, Dead Stripping und das Umschreiben von Debug-Informationen kosten ebenfalls Zeit. Debug-Builds können mehrere GB DWARF enthalten, die umgeschrieben werden müssen.
    Interessanterweise scheint es kein großer Kostenfaktor zu sein, dass Linker skriptbar sind und man ihnen ein Programm zur Interpretation übergeben kann. Vermutlich liegt das daran, dass diese Skripte ziemlich kurz und ihre Möglichkeiten in gewissem Maß begrenzt sind.
    Historisch war lld vor allem deshalb sehr schnell, weil es kaum Debug-Informationen bearbeitet oder andere Deduplizierung vorgenommen hat. lld lief schnell, aber die ausgegebenen Binärdateien waren groß.
    Ich bin seit einigen Jahren nicht mehr im Bereich Link-Performance aktiv und kenne den aktuellen Stand daher nicht gut. Insbesondere weiß ich nicht, wo mold oder lld heute im Spannungsfeld zwischen Ausgabequalität und eigener Performance stehen.
  • Das beste Material, das ich gelesen habe, war Ian Taylors Blog über seine Arbeit am gold-Linker.
    https://www.airs.com/blog/archives/38
    „Noch einmal: Das Ziel ist Geschwindigkeit. In diesem Fall schneller als mein zweiter Linker. Dieser Linker ist über die Jahre erheblich langsamer geworden, als Unterstützung für ELF und Shared Libraries hinzugefügt wurde. Diese Unterstützung war nicht von Anfang an entworfen, sondern nachträglich angebaut. Zu den künftigen Plänen für den neuen Linker gehört auch Unterstützung für inkrementelles Linken, was ebenfalls eine weitere Möglichkeit ist, die Geschwindigkeit zu erhöhen.“
    Man kann sich Apps aus den frühen Unix-Zeiten vorstellen: einfache Single-Purpose-Apps, vermutlich eine Quelldatei, ein Objekt, nur gegen libc gelinkt, und keine Dinge wie Shared Libraries.
    Danach wuchs der Linker-Code organisch, als „unverzichtbare“ Features hinzukamen. Besonders in der Zeit, als rotierende Festplatten der Flaschenhals waren, war die Korrektheit der Features wichtiger als Geschwindigkeit.