Rust-Compiler: neues Span-Format interniert 1 % statt 20 bis 40 %, Diesel-Rückstand sinkt
Serguey Asael Shinder1 Min. LesezeitNicholas Nethercote hat seinen November-Bericht zur Performance des Rust-Compilers veröffentlicht, nach seinem ersten Monat in dieser Aufgabe für Hexcat. Die größte Änderung betrifft Spans, die Datenstruktur, die jeder AST-, HIR- und MIR-Knoten trägt, um Quellposition, Hygiene-Kontext und optional eine Elternposition festzuhalten.
Ein Span hat vier 32-Bit-Felder, zusammen 16 Byte, wird aber meist in eines von drei 8-Byte-Inline-Formaten komprimiert; der Rest landet in einer globalen Tabelle. Mit PR 163857 ersetzte Nethercote das Kompressionsschema durch ein einfacheres. Bei inkrementellen Builds interniert der Compiler nun typischerweise etwa 1 % der Spans statt 20 bis 40 %, bei nicht inkrementellen weniger als 0,1 %. Das Kontextfeld lässt sich jetzt immer inline speichern. Die Instruktionszahl sank in vielen Benchmarks, im besten Fall um mehr als 3 %, bei den Zyklen noch stärker; am meisten profitierten inkrementelle Builds. Josh Triplett nutzte das neue Layout in PR 163971 für weitere Mikro-Optimierungen von bis zu 2 %.
PR 163628 setzte einen Ein-Eintrag-Cache vor die Hashtabelle, die Metadaten-Kodierung und stabiles Hashing immer wieder nach demselben Eltern-Span fragen; das sparte im besten Fall mehr als 4 % Instruktionen, wieder vor allem inkrementell. Ein Versuch, Span eine Nische zu geben, damit ein optionaler Span keinen Platz kostet, funktionierte, half aber nicht und wurde verworfen.
Beim neuen Trait-Solver zielten drei PRs auf Diesel, wo er langsamer ist als der alte. Ein Dutzend Mikro-Optimierungen senkte den Mehraufwand bei einem vollen Check-Build von 1,49x auf 1,16x; auch typenum und nalgebra legten zu.
Was das bedeutet
Die Gewinne landen vor allem bei inkrementellen Builds, also dort, wo Entwickler am häufigsten warten. Der Rückstand des neuen Solvers bei generikalastigen Crates ist gemessen und schrumpft.