Headstart : compiler les dépendances en parallèle sur leurs métadonnées pour accélérer Rust
Sommaire
En bref
- Headstart émet les métadonnées du compilateur (.rmeta) dès que l'interface d'une caisse est vérifiée, bien avant que ses corps de fonction soient analysés.
- Les caisses dépendantes commencent alors à compiler en parallèle sur ces métadonnées précoces au lieu d'attendre la vérification complète.
- Sur 13 projets réels (rust-analyzer, Bevy, Zed), les gains mesurent 24–54 % pour `cargo check` et 13–42 % pour `cargo build` sur 16 cœurs.
- Le coût : travail en aval parfois jeté, erreurs signalées légèrement plus tard, mémoire accrue en vol.
Ce que dit la source
L'auteur constate que la chaîne de compilation Rust impose une dépendance séquentielle stricte : chaque caisse ne peut démarrer sa vérification de type qu'une fois sa dépendance entièrement typée (interface et corps des fonctions inclus). Or, pour vérifier ses propres types, une caisse n'a besoin que de l'interface (le fichier .rmeta). Les corps ne sont nécessaires que lors de la génération de code. Headstart propose donc d'émettre les métadonnées en deux étapes : d'abord une version précoce dès la fin de la vérification d'interface, puis la version complète après l'analyse des corps. Cargo lance alors les dépendances en parallèle sur la version précoce, libérant les cœurs inutilisés du compilateur.
- Le gain provient de la parallélisation des phases de vérification et d'analyse de corps : pendant qu'une caisse analyse ses fonctions, ses dépendants font déjà progresser leur propre vérification de type sur l'interface découverte.
- 13 projets réels (rust-analyzer, Bevy, Zed, Lemmy, Polars, etc.) mesurés en builds propres ; aucun plus lent qu'avant.
- Sur 16 cœurs, les gains s'amenuisent sur 4 cœurs (24 % pour rust-analyzer en check, 14 % pour certains projets larges) : le bénéfice dépend de la concurrence de cœurs disponibles.
- Les caisses dépendantes font toute leur analyse sur les métadonnées précoces (`cargo check`), puis attendent la version complète avant génération de code (`cargo build`) ; pendant cette attente, elles libèrent leur créneau de compilateur à d'autres travaux.
- Deux ensembles de patchs mineurs : 6 patches rustc (-Zearly-metadata : divise l'analyse en interfaces/corps de fonction, écrit .early-rmeta, charge et bascule les métadonnées) ; 3 patches cargo (-Zheadstart : lances les dépendants, gère les créneaux, rapporte la sortie à la fin).
- Les erreurs de corps sont toujours détectées et font échouer le build avec le même statut de sortie ; seule la progression et l'ordre des messages JSON diffèrent légèrement.
Dans les commentaires
Débat partag", le fil apprécie l'idée mais soulève des cas limites sérieux (trait impl opaque, generic monomorphization) que l'auteur ne traite qu'esquissé.
- Un commentateur relève une tension réelle : les retours de type `impl Trait` et les `async fn` fuient les propriétés `Send`/`Sync` du type concret, ce qui exige l'analyse du corps en amont, contredisant le cœur de la proposition. L'auteur énonce qu'une duplication ou un traitement sélectif du travail pour ces cas est possible mais admet « likely have further complications ».
- Quelques commentateurs se demandent si ce n'est pas une forme de cache ou de construction incrémentale déjà explorée (un lien vers un fil antérieur sur l'optimisation du compilateur, une comparaison avec Turborepo pour TypeScript).
- Un commentaire critique le choix de distribuer les patches sous forme de fichiers plutôt que de vraies branches ou PRs Git, considérant cela comme une regression du contrôle de version.
Notre lecture
Headstart adresse un problème d'ordonnancement réel du compilateur Rust et apporte un cas d'usage convaincant : libérer des cœurs inutilisés sur les builds large/larges. Les chiffres sont solides sur 16 cœurs. Cependant, le fil met au jour des limites non triviales (types opaques, génériques) que la documentation décrit comme « possibles mais complexes ». Ce n'est pas du bruit, mais pas non plus une victoire certaine : le passage upstream dépendra de la robustesse de ces cas limites et de la volonté des équipes Rust de maintenir ce changement sémantique subtil. Pour les projets larges aujourd'hui, c'est une expérience intéressante à tenter avec les scripts fournis.