How to speed up the Rust compiler in 2022
nnethercote.github.io
How to speed up the Rust compiler in 2022
1–10 of 23 posts
Re: How to speed up the Rust compiler in 2022
#2I tried....and it didn't work.
Thank you. I appreciate the description of what was tried and didn't work or didn't work as well as hoped. We need more of this so I don't waste time (or you don't too).
Re: How to speed up the Rust compiler in 2022
#3These posts are always a pleasure to read. it's great to see continuous work on improving compiler performance, and especially with good results too.
Re: How to speed up the Rust compiler in 2022
#4Anybody interested in speeding up the Rust compiler should be looking into generating a new JITted parser after each macro definition, and jumping into it to parse the remaining (and any other affected) code.
The time to compile a new parser ought to be much less than feeding literally all tokens into a runtime macro-definition interpreter.
Similar infrastructure might help with generics type calculus.
Re: How to speed up the Rust compiler in 2022
#5I really wonder how much these changes, especially seeing the numbers (4%, 5%), add up at scale. For example, from reading a comment on Hacker News[0], I'm told that small changes can save companies millions and millions on servers. It saves power, too.
Re: How to speed up the Rust compiler in 2022
#6I really wonder how much these changes, especially seeing the numbers (4%, 5%), add up at scale. For example, from reading a comment on Hacker News[0], I'm told that small changes can save companies millions and millions on servers. It saves power, too. [0]: https://news.ycombinator.com/item?id=30461201
Those are mostly compiler speedups, fewer compiled-code speedups. Since most code is executed more often than it is compiled the fleet-level savings will be much smaller. It helps with CI jobs and developer-cycles though.
Re: How to speed up the Rust compiler in 2022
#7> #93066: The Decoder trait used for metadata decoding was fallible, using Result throughout. But decoding failures should only happen if something highly unexpected happens (e.g. metadata is corrupted) and on failure the calling code would just abort. This PR changed Decoder to be infallible throughout—panicking immediately instead of panicking slightly later—thus avoiding lots of pointless Result propagation, for wins across many benchmarks of up to 2%.
Interesting insight into the cost of Result-based error handling.
Re: How to speed up the Rust compiler in 2022
#8> #93066: The Decoder trait used for metadata decoding was fallible, using Result throughout. But decoding failures should only happen if something highly unexpected happens (e.g. metadata is corrupted) and on failure the calling code would just abort. This PR changed Decoder to be infallible throughout—panicking immediately instead of panicking slightly later—thus avoiding lots of pointless Result propagation, for w…
not surprising though, this is the exact same scenario than with C++ exceptions. if your code is on the happy path, they are consistently faster than error codes
Re: How to speed up the Rust compiler in 2022
#9Anybody interested in speeding up the Rust compiler should be looking into generating a new JITted parser after each macro definition, and jumping into it to parse the remaining (and any other affected) code. The time to compile a new parser ought to be much less than feeding literally all tokens into a runtime macro-definition interpreter. Similar infrastructure might help with generics type calculus.
Rust macros only require special parsing for macro arguments, so most tokens don’t need to touch the macro engine.
Re: How to speed up the Rust compiler in 2022
#10I really wonder how much these changes, especially seeing the numbers (4%, 5%), add up at scale. For example, from reading a comment on Hacker News[0], I'm told that small changes can save companies millions and millions on servers. It saves power, too. [0]: https://news.ycombinator.com/item?id=30461201
Those are mostly compiler speedups, fewer compiled-code speedups. Since most code is executed more often than it is compiled the fleet-level savings will be much smaller. It helps with CI jobs and developer-cycles though.
Both threads are discussing compiler speedups.