In dit artikel beschrijft Nicholas Nethercote de voortgang in de snelheid van de Rust-compiler tussen juli en september 2026. De gemiddelde 'wall-time' is met 4,57% verminderd.
Belangrijke technische verbeteringen zijn onder andere:
- LLVM & Clippy: Een upgrade naar LLVM 23 en het inschakelen van Profile-Guided Optimization (PGO) voor Clippy hebben gezorgd voor meetbare winst.
- Borrow Checker & Trait Solver: De nieuwe borrow checker (Polonius Alpha) en trait solver (Pineapple Häagen-Dazs) zijn ingeschakeld op Nightly. Ondanks beginregressies zijn er significante optimalisaties doorgevoerd om de compilatietijd te drukken.
- Bijdragen van xmakro: Diverse optimalisaties in de specialisatiegrafiek en incrementele compilatiegegevens.
- Dataflow-analyse: Een nieuw CFG-traversal-algoritme zorgde voor een enorme snelheidswinst van circa 30% voor de
cranelift-codegen crate.
- Overig: Er is gebruikgemaakt van LLM's voor analysehulp en de standaard stackgrootte van de compiler is verhoogd om recursie-efficiëntie te verbeteren.
Hoe de Rust-compiler te versnellen in september 2026
Mijn laatste bericht over de prestaties van de Rust-compiler was twee maanden geleden en sindsdien is er veel gebeurd.
Algemene voortgang
De metingen voor de periode van 29 juli 2026 tot 28 september 2026 zijn beschikbaar. De gemiddelde vermindering van de wandtijd (wall-time) was 4,57%, wat een opmerkelijke verbetering is in slechts twee maanden. Van de 629 benchmarkmetingen verbeterden er 555 en waren er slechts 74 verslechterd. Een aantal benchmarks vertoonden percentages van dubbele cijfers in vermindering. De technische term voor dit resultaat is "een zee van groen".
rustdoc
In mijn vorige bericht noemde ik hoe Noah Lev enorme snelheidswinsten behaalde met rustdoc. Hij heeft onlangs een bericht geschreven waarin hij in detail uitlegt hoe hij dit heeft aangepakt. Het is een interessante en bevredigende lectuur.
Clippy
- PR #159642: In deze PR heeft Jakub Beránek PGO (Profile-Guided Optimization) ingeschakeld voor Clippy. Dit zorgde voor verbeteringen in de wandtijd over de meeste Clippy-benchmarks, met in het beste geval een winst van 18%.
LLVM-update
- PR #158734: In deze PR heeft Nikita Popov de LLVM-versie die door de compiler wordt gebruikt geüpgraded naar LLVM 23. Zoals vaak gebeurt bij een LLVM-upgrade, zagen we mooie snelheidswinsten. De gemiddelde vermindering van de wandtijd over alle benchmarks was 1,2%. Hoewel dat misschien weinig klinkt, is het zeer indrukwekkend voor een enkele PR. Uitstekend werk van de LLVM-ploeg.
De nieuwe borrow checker
De nieuwe borrow checker, Polonius Alpha (geen relatie met Napoleon Dynamite), is ingeschakeld op Nightly. Deze is nauwkeuriger dan de bestaande borrow checker en accepteert sommige geldige programma's die de oude borrow checker zou weigeren. Polonius Alpha voert echter meer werk uit, genoeg om in een minderheid van de gevallen een meetbaar verschil te maken in de compilatietijd, waaronder bij de populaire serde crate. Gelukkig is Jack Huey hiermee aan de slag gegaan:
- PR #161938: In deze PR heeft Jack sommige liveness computations lazy gemaakt, wat het aantal instructies voor
serde met 3-5% verminderde, en voor enkele andere benchmarks met minder dan 1%.
- PR #163027: In deze PR heeft Jack een datastructuur aangepast en sommige inlining getweakt, wat leidde tot reducties in het aantal instructies van grotendeels minder dan 1% over talrijke benchmarks.
Er moet meer werk worden gedaan om de resterende Polonius Alpha-regressies te verminderen, maar het is vermeldenswaard dat de "zee van groen" aantoont dat deze regressies werden overschaduwd door de vele andere recente verbeteringen.
De nieuwe trait solver
De nieuwe trait solver, Penelope Hammertime (zie postscriptum), is ook ingeschakeld op Nightly. Net als de nieuwe borrow checker is de nieuwe trait solver in een minderheid van de gevallen trager. Jana Dönszelmann heeft een gedetailleerd bericht geschreven over de inspanningen om de prestaties van deze nieuwe solver te verbeteren.
Vanwege de gedetailleerdheid van Jana's bericht zal ik niet veel meer zeggen over het grote amount aan lopend werk aan de nieuwe solver, maar ik noem terloops de PR's die ik heb gemaakt: #160479, #160605, #160801, #160892, #161077 en #161211.
Sommige hiervan verminderden de compilatietijden aanzienlijk voor bepaalde uitschieter-crates: 50% hier, 25% daar, 15% daar, en zelfs meer bij één stresstest. En ik ben niet de enige die hier progressie heeft geboekt; lees hiervoor Jana's bericht.
xmakro
De nieuwe contributor xmakro heeft zijn reeks goede verbeteringen voortgezet:
- PR #157281: In deze PR heeft xmakro de
impl-afhandeling geoptimaliseerd bij het bouwen van de specialisatiegrafiek. Dit resulteerde in een gemiddelde vermindering van het aantal cycli van 1,58% over alle benchmarks, wat enorm is voor een enkele PR.
- PR #158059: In deze PR optimaliseerde xmakro een aspect van het laden van incrementele compilatiegegevens, waardoor het aantal instructies over meerdere benchmarks werd verminderd, in het beste geval met 6%.
- PR #160473: In deze PR vermeed xmakro sommige allocaties in een intensief gebruikt pad voor het verwerken van obligations, wat het aantal instructies over talloze benchmarks verminderde, in het beste geval met 2%.
- PR #160268: In deze PR vermeed xmakro veel allocaties door de code voor de selectie tussen de oude en nieuwe trait solver te wijzigen van dynamische dispatch naar statische dispatch. Dit zorgde voor reducties in het aantal instructies van grotendeels minder dan 1% over een aantal benchmarks. Dit intensieve allocatiepad was al een tijdje zichtbaar in profielen en ik had eerder exact hetzelfde idee geprobeerd in #155714. Toen kreeg ik echter regressies bij een paar benchmarks, mogelijk door slightly verschillende keuzes in waar sommige
#[inline]-attributen werden geplaatst. Het was goed om te zien dat deze overduidelijke inefficiëntie is verholpen.
Dataflow-analyse
- PR #160193: In deze PR heb ik het CFG-traversal-algoritme gewijzigd dat wordt gebruikt door de dataflow-analyses in de compiler. Deze analyses itereren naar een fixpoint en het traversal-algoritme kan beïnvloeden hoe snel dit fixpoint wordt bereikt. Voor de meeste code maakt het nieuwe algoritme geen verschil, maar de
cranelift-codegen crate heeft één enorme functie met meer dan 18.000 basisblokken. Het oude algoritme vereiste 1,5 miljoen aanroepen van applyeffectsin_block om een fixpoint te bereiken voor de EverInitializedPlaces-analyse die door de borrow checker wordt gebruikt; het nieuwe algoritme vereist er 90.000. Dit zorgde voor een enorme vermindering van de wandtijd van ongeveer 30% voor een check-build van deze crate.
- PR #160033: In deze PR heb ik
EverInitializedPlaces opnieuw efficiënter gemaakt, ditmaal door geen onnodige gegevens voor projecties bij te houden. Dit verminderde het aantal instructies op de match-stress benchmark met 17%, en op een paar andere benchmarks met minder dan 1%.
LLM's
Ze zijn erg goed geworden in bepaalde soorten analyses. Ik schrijf nog steeds al mijn eigen code en tekst, omdat (a) dat essentieel is en (b) het projectbeleid dit vereist, maar ik heb nuttige LLM-analysehulp gehad bij verschillende van de PR's die in dit bericht worden genoemd.
Diversen
- PR #160535: In deze PR heeft Chris Denton de standaard stackgrootte die door de compiler wordt gebruikt verhoogd. Hierdoor kon
ensuresufficientstack worden verwijderd, een handmatig mechanisme voor stack-extensie dat op diverse plekken was verspreid die gevoelig zijn voor hoge niveaus van recursie. Er was veel discussie over deze PR, omdat het lastig kan zijn om te bepalen hoe je het beste met stack-uitputting omgaat. De prestatie-effecten zijn echter duidelijk, met een verminderd aantal instructies over veel benchmarks, in het beste geval met bijna 3%.
- PR #160506: Het project maakt veel gebruik van "rollup"-PR's, waarbij meerdere PR's samen worden samengevoegd. Dit komt doordat we onvoldoende CI-capaciteit hebben om elke PR individueel samen te voegen. Normaal gesproken worden PR's die de prestaties beïnvloeden afzonderlijk samengevoegd, zodat we hun effecten duidelijk kunnen meten. Voor het eerst hadden we echter zoveel prestatieverbeterende PR's in de merge-wachtrij staan dat Jonathan Brouwer een rollup maakte met 10 prestatieverbeterende PR's om de vaart erin te houden. Dit is een luxe-probleem. Later hadden we PR #162859, die vier prestatieverbeterende PR's bevatte. (Je hoeft je geen zorgen te maken over onverwachte effecten, want we kunnen de prestatie-benchmarksuite draaien op de individuele PR's na het samengevoegen om te controleren of elke PR het verwachte effect had).
- PR #162747: In deze PR heb ik enkele kleine verbeteringen aangebracht in de code die AST naar HIR verlaagt. Het was een opschoning waarvan niet werd verwacht dat het de prestaties zou beïnvloeden, maar het verminderde het aantal instructies over talloze benchmarks, in het beste geval met 1,5%. Soms heb je geluk.
Werkstatus
Morgen begin ik bij Hexcat aan het projectdoel voor optimalisaties van de compilerprestaties. Spannend! Veel dank aan Mara Bos, Predrag Gruevski en alle anderen die hebben geholpen om dit mogelijk te maken.
***
Postscriptum van de redacteur: De naam van de nieuwe solver is niet Penelope Hammertime; dat was een grap.
Postscriptum van de auteur: De echte naam is Pineapple Häagen-Dazs.
Hoe de Rust-compiler te versnellen in september 2026
Mijn laatste bericht over de prestaties van de Rust-compiler was twee maanden geleden en sindsdien is er veel gebeurd.
Algemene voortgang
De metingen voor de periode van 29 juli 2026 tot 28 september 2026 zijn beschikbaar. De gemiddelde vermindering van de wandtijd (wall-time) was 4,57%, wat een opmerkelijke verbetering is in slechts twee maanden. Van de 629 benchmarkmetingen verbeterden er 555 en waren er slechts 74 verslechterd. Een aantal benchmarks vertoonden percentages van dubbele cijfers in vermindering. De technische term voor dit resultaat is "een zee van groen".
rustdoc
In mijn vorige bericht noemde ik hoe Noah Lev enorme snelheidswinsten behaalde met rustdoc. Hij heeft onlangs een bericht geschreven waarin hij in detail uitlegt hoe hij dit heeft aangepakt. Het is een interessante en bevredigende lectuur.
Clippy
- PR #159642: In deze PR heeft Jakub Beránek PGO (Profile-Guided Optimization) ingeschakeld voor Clippy. Dit zorgde voor verbeteringen in de wandtijd over de meeste Clippy-benchmarks, met in het beste geval een winst van 18%.
LLVM-update
- PR #158734: In deze PR heeft Nikita Popov de LLVM-versie die door de compiler wordt gebruikt geüpgraded naar LLVM 23. Zoals vaak gebeurt bij een LLVM-upgrade, zagen we mooie snelheidswinsten. De gemiddelde vermindering van de wandtijd over alle benchmarks was 1,2%. Hoewel dat misschien weinig klinkt, is het zeer indrukwekkend voor een enkele PR. Uitstekend werk van de LLVM-ploeg.
De nieuwe borrow checker
De nieuwe borrow checker, Polonius Alpha (geen relatie met Napoleon Dynamite), is ingeschakeld op Nightly. Deze is nauwkeuriger dan de bestaande borrow checker en accepteert sommige geldige programma's die de oude borrow checker zou weigeren. Polonius Alpha voert echter meer werk uit, genoeg om in een minderheid van de gevallen een meetbaar verschil te maken in de compilatietijd, waaronder bij de populaire serde crate. Gelukkig is Jack Huey hiermee aan de slag gegaan:
- PR #161938: In deze PR heeft Jack sommige liveness computations lazy gemaakt, wat het aantal instructies voor
serde met 3-5% verminderde, en voor enkele andere benchmarks met minder dan 1%.
- PR #163027: In deze PR heeft Jack een datastructuur aangepast en sommige inlining getweakt, wat leidde tot reducties in het aantal instructies van grotendeels minder dan 1% over talrijke benchmarks.
Er moet meer werk worden gedaan om de resterende Polonius Alpha-regressies te verminderen, maar het is vermeldenswaard dat de "zee van groen" aantoont dat deze regressies werden overschaduwd door de vele andere recente verbeteringen.
De nieuwe trait solver
De nieuwe trait solver, Penelope Hammertime (zie postscriptum), is ook ingeschakeld op Nightly. Net als de nieuwe borrow checker is de nieuwe trait solver in een minderheid van de gevallen trager. Jana Dönszelmann heeft een gedetailleerd bericht geschreven over de inspanningen om de prestaties van deze nieuwe solver te verbeteren.
Vanwege de gedetailleerdheid van Jana's bericht zal ik niet veel meer zeggen over het grote amount aan lopend werk aan de nieuwe solver, maar ik noem terloops de PR's die ik heb gemaakt: #160479, #160605, #160801, #160892, #161077 en #161211.
Sommige hiervan verminderden de compilatietijden aanzienlijk voor bepaalde uitschieter-crates: 50% hier, 25% daar, 15% daar, en zelfs meer bij één stresstest. En ik ben niet de enige die hier progressie heeft geboekt; lees hiervoor Jana's bericht.
xmakro
De nieuwe contributor xmakro heeft zijn reeks goede verbeteringen voortgezet:
- PR #157281: In deze PR heeft xmakro de
impl-afhandeling geoptimaliseerd bij het bouwen van de specialisatiegrafiek. Dit resulteerde in een gemiddelde vermindering van het aantal cycli van 1,58% over alle benchmarks, wat enorm is voor een enkele PR.
- PR #158059: In deze PR optimaliseerde xmakro een aspect van het laden van incrementele compilatiegegevens, waardoor het aantal instructies over meerdere benchmarks werd verminderd, in het beste geval met 6%.
- PR #160473: In deze PR vermeed xmakro sommige allocaties in een intensief gebruikt pad voor het verwerken van obligations, wat het aantal instructies over talloze benchmarks verminderde, in het beste geval met 2%.
- PR #160268: In deze PR vermeed xmakro veel allocaties door de code voor de selectie tussen de oude en nieuwe trait solver te wijzigen van dynamische dispatch naar statische dispatch. Dit zorgde voor reducties in het aantal instructies van grotendeels minder dan 1% over een aantal benchmarks. Dit intensieve allocatiepad was al een tijdje zichtbaar in profielen en ik had eerder exact hetzelfde idee geprobeerd in #155714. Toen kreeg ik echter regressies bij een paar benchmarks, mogelijk door slightly verschillende keuzes in waar sommige
#[inline]-attributen werden geplaatst. Het was goed om te zien dat deze overduidelijke inefficiëntie is verholpen.
Dataflow-analyse
- PR #160193: In deze PR heb ik het CFG-traversal-algoritme gewijzigd dat wordt gebruikt door de dataflow-analyses in de compiler. Deze analyses itereren naar een fixpoint en het traversal-algoritme kan beïnvloeden hoe snel dit fixpoint wordt bereikt. Voor de meeste code maakt het nieuwe algoritme geen verschil, maar de
cranelift-codegen crate heeft één enorme functie met meer dan 18.000 basisblokken. Het oude algoritme vereiste 1,5 miljoen aanroepen van applyeffectsin_block om een fixpoint te bereiken voor de EverInitializedPlaces-analyse die door de borrow checker wordt gebruikt; het nieuwe algoritme vereist er 90.000. Dit zorgde voor een enorme vermindering van de wandtijd van ongeveer 30% voor een check-build van deze crate.
- PR #160033: In deze PR heb ik
EverInitializedPlaces opnieuw efficiënter gemaakt, ditmaal door geen onnodige gegevens voor projecties bij te houden. Dit verminderde het aantal instructies op de match-stress benchmark met 17%, en op een paar andere benchmarks met minder dan 1%.
LLM's
Ze zijn erg goed geworden in bepaalde soorten analyses. Ik schrijf nog steeds al mijn eigen code en tekst, omdat (a) dat essentieel is en (b) het projectbeleid dit vereist, maar ik heb nuttige LLM-analysehulp gehad bij verschillende van de PR's die in dit bericht worden genoemd.
Diversen
- PR #160535: In deze PR heeft Chris Denton de standaard stackgrootte die door de compiler wordt gebruikt verhoogd. Hierdoor kon
ensuresufficientstack worden verwijderd, een handmatig mechanisme voor stack-extensie dat op diverse plekken was verspreid die gevoelig zijn voor hoge niveaus van recursie. Er was veel discussie over deze PR, omdat het lastig kan zijn om te bepalen hoe je het beste met stack-uitputting omgaat. De prestatie-effecten zijn echter duidelijk, met een verminderd aantal instructies over veel benchmarks, in het beste geval met bijna 3%.
- PR #160506: Het project maakt veel gebruik van "rollup"-PR's, waarbij meerdere PR's samen worden samengevoegd. Dit komt doordat we onvoldoende CI-capaciteit hebben om elke PR individueel samen te voegen. Normaal gesproken worden PR's die de prestaties beïnvloeden afzonderlijk samengevoegd, zodat we hun effecten duidelijk kunnen meten. Voor het eerst hadden we echter zoveel prestatieverbeterende PR's in de merge-wachtrij staan dat Jonathan Brouwer een rollup maakte met 10 prestatieverbeterende PR's om de vaart erin te houden. Dit is een luxe-probleem. Later hadden we PR #162859, die vier prestatieverbeterende PR's bevatte. (Je hoeft je geen zorgen te maken over onverwachte effecten, want we kunnen de prestatie-benchmarksuite draaien op de individuele PR's na het samengevoegen om te controleren of elke PR het verwachte effect had).
- PR #162747: In deze PR heb ik enkele kleine verbeteringen aangebracht in de code die AST naar HIR verlaagt. Het was een opschoning waarvan niet werd verwacht dat het de prestaties zou beïnvloeden, maar het verminderde het aantal instructies over talloze benchmarks, in het beste geval met 1,5%. Soms heb je geluk.
Werkstatus
Morgen begin ik bij Hexcat aan het projectdoel voor optimalisaties van de compilerprestaties. Spannend! Veel dank aan Mara Bos, Predrag Gruevski en alle anderen die hebben geholpen om dit mogelijk te maken.
***
Postscriptum van de redacteur: De naam van de nieuwe solver is niet Penelope Hammertime; dat was een grap.
Postscriptum van de auteur: De echte naam is Pineapple Häagen-Dazs.
Groetjes,