Mold, le linker ultra-rapide pour Linux, a été réécrit en Rust

Mold, le linker ultra-rapide qui accélère la compilation des projets C, C++ et Rust sous Linux, est sorti ce lundi 5 octobre en version 3.0.

Ceux qui l'utilisent ne verront aucune différence. Son code, lui, a pourtant été entièrement réécrit du C++ vers Rust.

Cette 3.0 se veut un remplacement direct de la 2.42.1, la dernière version en C++ : mêmes options, mêmes architectures, même résultat (à quelques bugfix près) et même vitesse. Pour le vérifier, le projet a notamment recompilé l'intégralité des paquets de Gentoo, sans constater la moindre régression.

Un linker, c'est quoi chef ?

Petite piqûre de rappel pour celles et ceux qui ont peu prêté l'oreille pendant les cours de compilation, ou qui n'ont jamais quitté le douillet confort des langages interprétés : le compilateur transforme chaque fichier source en fichier objet (les fameux .o).

Le linker assemble ensuite tous ces morceaux en un seul exécutable, en reliant chaque appel de fonction à son code, qu'il se trouve dans un autre fichier du projet ou dans une bibliothèque. Sur un projet mastodonte, comme Chromium par exemple, vous subissez cette étape à chaque ligne modifiée.

C'est pour régler ce problème que le développeur Rui Ueyama, déjà à l'origine de LLD (pas la location longue durée, le linker de LLVM : l'infra de compilation sur laquelle reposent Clang, Rust ou Swift), a lancé mold en 2020.

D'après les benchmarks du projet, mold va généralement près de cinq fois plus vite que LLD. Sur la version debug de Chromium (plus de 4 Go), il boucle le travail en 1,65 seconde sur une grosse station de travail à 64 cœurs, contre 16,64 secondes pour LLD.

Pourquoi tant de Rust ?

Mold rejoint la longue liste des briques de l'écosystème Linux qui passent à Rust. Le mouvement est remonté jusqu'au noyau depuis que Linus Torvalds a donné son feu vert en 2022, et Canonical s'y est carrément engagé en rejoignant la Rust Foundation.

Sauf qu'ici, la réécriture ne fait rien gagner en vitesse.

Pour Rui Ueyama, l'enjeu est ailleurs : un outil comme mold doit pouvoir rester en service pendant des décennies, alors autant changer de fondations maintenant.

Quand il a lancé mold en 2020, Rust lui semblait encore trop récent (sa version 1.0 stable ne datait que de 2015). Depuis, le langage est devenu selon lui un choix tout à fait pratique pour le logiciel système, avec des performances comparables au C++, la sécurité mémoire en prime.

Face à un fichier d'entrée corrompu, la version C++ pouvait par exemple lire hors des zones prévues et finir en segfault. La version Rust, elle, s'arrête proprement, avec un message d'erreur précis.

L'IA en renfort

Un peu plus de trois semaines séparent l'annonce de la réécriture, dans les notes de la version 2.42.1 du 11 septembre, et la sortie de la 3.0.

De quoi faire tiquer, jusqu'à ce que Rui Ueyama précise sur Hacker News que le portage était alors déjà presque terminé.

Si le chantier a avancé aussi vite, l'IA n'y est pas pour rien : il explique qu'elle rend désormais les réécritures à grande échelle bien plus jouables, même si elle n'en efface pas les risques.

Venant du créateur de deux des linkers les plus rapides du marché, l'avis pèse un peu plus lourd que celui d'un influvoleur qui vient de vibecoder sa première todo-app — et qui veut surtout vendre ses formations toutes pétées. Comment ça, vous avez déjà quelques noms en tête ? 😏

Prochain arrêt : /usr/bin/ld

Avec la série 3.x, le projet veut ouvrir la voie à l'adoption de mold comme linker par défaut des distributions Linux, celui qui répond quand un build appelle /usr/bin/ld.

Sur la plupart d'entre elles, ce rôle revient encore à GNU ld, nettement plus lent : là où mold boucle certaines liaisons en quelques centaines de millisecondes, GNU ld peut mettre plusieurs secondes, voire plusieurs minutes.

Le gros morceau sera le support complet des linker scripts, ces fichiers qui décrivent où ranger chaque morceau du programme en mémoire, indispensables pour lier un noyau ou un firmware.

Si le pari réussit, une bonne partie des builds Linux pourrait finir par passer par du code Rust sans que personne ne s'en rende compte. Après tout, les meilleurs chantiers sont parfois ceux qui refont les fondations sans qu'on entende les travaux. 😉