mold 2.0.0 - éditeur de liens rapide

• La licence passe de l’AGPL à la MIT, ce qui constitue le principal changement de mold 2.0.0
• Correction d’un bug qui empêchait de créer, avec --relocatable, un fichier objet contenant plus de 65 520 sections
• -undefined est désormais interprété comme un synonyme de --undefined au lieu de -u ndefined, en alignement avec le comportement des linkers GNU et de LLVM lld
• -nopie est traité comme un synonyme de --no-pie
• Prise en charge, sur RISC-V, des types de relocalisation R_RISCV_SET_ULEB128 et R_RISCV_SUB_ULEB128
• Prise en charge, sur PPC64, du type de relocalisation R_PPC64_REL32

[GN⁺]

Avis sur Hacker News

• mold est vraiment un excellent travail pour les systèmes modernes.
  En essayant récemment d’accélérer la compilation d’un projet, j’ai constaté que l’étape d’édition des liens était un énorme goulet d’étranglement. Même avec 24 cœurs * 2 threads, environ 30 % des performances globales restent inutilisées à cause du linker.
  J’avais déjà essayé de compiler avec mold par le passé, mais ça n’avait pas bien fonctionné à l’époque ; je compte réessayer.

  • Mold est impressionnant. Il y a quelques mois, en bricolant O3DE, je suis passé à Mold pour voir si je pouvais réduire le cycle build-exécution, et c’est clairement devenu plus rapide.
    Je ne me souviens plus des chiffres exacts, mais c’était une différence assez nette : ce qui prenait quelques secondes avec gold et lld passait sous la seconde avec mold.
  • Au travail aussi, nous avons fait quelques preuves de concept, et sur une petite machine de build de test, le temps de build complet de la couche UI est passé de 44–45 minutes à 29 minutes en remplaçant lld par mold.
    C’était du code C++/Qt complexe.
  • mold -run ninja fonctionne très bien dans mon environnement.

• Je suis très content d’apprendre ce changement de licence. J’espère que le projet pourra aussi rapporter de l’argent, mais avec une licence MIT, il devient beaucoup plus probable qu’on puisse l’intégrer dans des projets professionnels.
  Si nous finissons par l’utiliser réellement, j’essaierai de convaincre mon entreprise de sponsoriser le projet.

  • La licence d’un linker ne devrait pas vraiment avoir d’importance. Il n’injecte pas de code soumis au droit d’auteur, et même dans l’écosystème GPL il existe déjà des précédents où de petits éléments de boilerplate sont considérés comme des exceptions ; il n’y a donc aucune raison que les binaires générés soient affectés par la licence copyleft de l’outil.
    L’AGPL ne poserait de restrictions que si l’on déployait comme service réseau un linker modifié de manière privée, ce qui n’est pas un scénario réaliste pour un outil de développement de base.

• Je m’interroge sur le changement de licence. Ce n’est pas un exécutable ? Appeler un processus séparé n’oblige pas le logiciel appelant à devenir GPL, donc dans les cas habituels, le passage à MIT ne devrait pas avoir d’impact.
  Si les auteurs voulaient vraiment une licence plus permissive, plutôt que de relicencier d’AGPL vers MIT, ils auraient dû passer à une AGPL avec exception de liaison. libgit2 est un exemple de projet GPL avec exception de liaison : https://github.com/libgit2/libgit2#license
  Ce type de licence est plus permissif tout en permettant encore de vendre une licence commerciale à ceux qui produisent des modifications non open source.

  • Le point essentiel semble être que les auteurs ne veulent plus continuer à vendre des licences. Apparemment, ça ne valait pas l’effort que cela demandait.
    La version macOS, sold, semble faire exception.

• Ce linker améliore nettement le confort de développement dans mon dépôt Rust d’exploration, qui est en train de devenir un gros monolithe web utilisant SeaORM et axum/tokio.
  Vous ne voulez probablement pas connaître la taille de mon répertoire target, mais les builds incrémentaux sont devenus bien plus réactifs.

  • Il va falloir que je joue un peu avec mold.
    15:55 $ du -Hs --si target/
11G target/

• Mold est excellent, et j’ai quelques usages préférés.

  1. Il accélère les builds Rust.
     [target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = [
"-C", "link-arg=-fuse-ld=mold",
"-C", "target-cpu=native"
]
  2. Sur ArchLinux, ajouter "-fuse-ld=mold" aux CFLAGS accélère aussi makepkg.
  • Existe-t-il un moyen de surcharger ce réglage du linker uniquement pour une installation locale ? Je ne veux pas modifier le code de production ni les binaires, mais j’aimerais que les builds soient plus rapides.
  • Je suis curieux de savoir à quel point le temps de liaison en Rust a changé avant/après.
  • Comment cette dernière release se compare-t-elle à lld ? Peut-elle aussi tourner sur alpine/musl ?

• C’est une décision très sage. Il m’arrive aussi d’avoir des moments difficiles où je dois reconnaître que certaines choses, dans mon produit ou mon code, ne se prêtent pas à la monétisation.
  Le marché parle, et même si c’est regrettable, plutôt que de lutter contre lui, il est important de trouver autre chose que le marché récompense.

• Quelqu’un sait-il si ce changement de licence/de stratégie commerciale s’appliquera aussi à sold ? sold est mold pour macOS.
  https://github.com/bluewhalesystems/sold

  • Apple dispose d’un nouveau linker parallèle, qui pourrait ou non intéresser certains.
    https://twitter.com/davidecci/status/1665835119331135488
  • En regardant tout en haut du README de mold, j’imagine qu’il ne deviendra pas open source.
    « Ce dépôt contient la version gratuite du linker mold. Si vous cherchez une version commerciale prenant en charge macOS, consultez le dépôt du linker sold. »
  • Je ne comprends pas pourquoi Apple ne sponsorise pas ce projet pour en faire le linker par défaut de Xcode.
    Ils pourraient payer généreusement le travail effectué et rendre le monde meilleur.
    Pour Apple, ce serait tellement facile.

• La licence passe de l’AGPL à MIT.
  Mais comment des artisans aussi talentueux devraient-ils être rémunérés, et pourquoi ne le sont-ils pas encore ainsi ? J’ai l’impression que les entreprises, quelle que soit leur taille, devraient allouer un certain budget à leurs dépendances ou outils essentiels et le publier sur leur site officiel. Il faudrait davantage une sorte de norme culturelle en ce sens.

• J’avais oublié que c’était un linker rapide
  « Mold 2.0.0 est la nouvelle version majeure de notre linker rapide. Avec cette version, nous avons changé la licence d’AGPL à MIT afin d’élargir notre base d’utilisateurs. Comme le savent celles et ceux qui ont suivi nos progrès, ce n’a pas été une décision facile, car nous avions tenté de monétiser le produit avec un double modèle de licence AGPL/commerciale. Malheureusement, cette approche n’a pas été à la hauteur de nos attentes. Ce changement de licence est le résultat de l’acceptation de cette réalité. Nous ne voulons pas continuer à nous accrocher à une stratégie qui ne fonctionnait pas bien. »

  • Quelqu’un se souvient de l’époque où il fallait payer le coût de cc sur Solaris ? https://unix.stackexchange.com/questions/12731/usr-ucb-cc-la...
    C’était horrible, et c’était aussi une bien mauvaise façon de traiter les développeurs qui écrivaient des logiciels pour son propre OS.
    Depuis très longtemps, nous sommes habitués à ne pas payer pour les outils de développement bas niveau, mais plutôt pour le support. Le simple fait qu’ils aient essayé ce type de licence est surprenant.

• J’ai souvent vu, pendant longtemps, des discussions sur les linkers rapides et des témoignages disant qu’en remplaçant un linker par un autre plus rapide, le temps de compilation diminuait fortement, mais en général je ne comprenais pas bien pourquoi un linker est lent.
  Ce serait bien si quelqu’un pouvait l’expliquer.

  • Ce n’est pas une explication complète, mais l’édition de liens est intensive en CPU, et les anciens linkers sont généralement monothread.
    Une grande partie des gains de performances vient du fait de paralléliser le travail, ce qui apporte de grosses améliorations sur les CPU multicœurs modernes et puissants.
    Si vous voulez en savoir plus, Rui a fait une bonne présentation sur Mold : https://www.youtube.com/watch?v=hAt3kCalE0Y
  • Dans le cas idéal, un linker devrait être aussi rapide que cat. Il suffirait de concaténer des binaires et ce serait terminé. À l’époque des disques rotatifs, les E/S disque posaient problème, mais c’est moins le cas aujourd’hui.
    Ce qui prend du temps, c’est de réécrire des contenus au fil du processus. Parcourir les tables de relocalisation pour insérer des adresses dans le code est peu coûteux, et le dead stripping au niveau des sections l’est aussi assez, mais faire du dead stripping sur des blocs de base individuels à l’intérieur des fonctions demande beaucoup plus d’analyse, donc prend du temps.
    La déduplication des chaînes constantes est une bonne idée, mais il faut toutes les faire passer dans une forme de table de hachage. Si l’on veut aussi partager les suffixes communs, cela ajoute encore du travail.
    La déduplication, le dead stripping et la réécriture des informations de débogage prennent aussi du temps. Les builds de débogage peuvent contenir plusieurs Go de DWARF à réécrire.
    Fait intéressant, le fait qu’un linker soit scriptable et qu’on puisse lui fournir un programme à interpréter ne semble pas coûter très cher. C’est sans doute parce que ces scripts sont assez courts et que leurs fonctionnalités sont relativement limitées.
    Historiquement, si lld était très rapide, c’est parce qu’il faisait assez peu de traitement des informations de débogage ou d’autres déduplications. lld s’exécutait rapidement, mais les binaires produits étaient gros.
    Cela fait quelques années que je ne travaille plus sur les performances d’édition de liens, donc je ne connais pas bien l’état actuel. En particulier, je ne sais pas où se situent aujourd’hui mold ou lld dans le compromis entre qualité de sortie et performances propres.
  • La meilleure ressource que j’aie lue est le blog d’Ian Taylor sur son travail sur le linker gold.
    https://www.airs.com/blog/archives/38
    « Encore une fois, l’objectif est la vitesse. Dans ce cas, il s’agit d’être plus rapide que mon deuxième linker. Celui-ci est devenu nettement plus lent au fil des ans avec l’ajout de la prise en charge d’ELF et des bibliothèques partagées. Cette prise en charge n’a pas été conçue dès le départ, elle a été ajoutée après coup. Parmi les projets futurs du nouveau linker figure aussi la prise en charge de l’édition de liens incrémentale, qui est une autre façon d’augmenter la vitesse. »
    Il suffit de penser aux applications des débuts d’Unix. Des applications simples, à usage unique, probablement avec un seul fichier source, un seul objet, seulement libc à lier, et pas de bibliothèques partagées.
    Ensuite, à mesure que des fonctionnalités « indispensables » ont été ajoutées, le code du linker a grandi de manière organique. Surtout à l’époque où les disques rotatifs constituaient le goulot d’étranglement, l’exactitude des fonctionnalités comptait plus que la vitesse.