7 ms·
How to speed up the Rust compiler one last time
- Ar-Curunir 6y agoThank you for your excellent work over the years! Your efforts have gone a long way to making Rust enjoyable to write =) If there are any smart rust-using company, they should definitely hire nnethercote to continue their excellent work!
- dblohm7 6y agoConsidering that nnethercote is still with us at Mozilla, I sure hope that he doesn’t get hired away! :-)
- Ar-Curunir 6y agoOops, missed that part :)
- __s 6y agoNicholas Nethercote didn't just speed up Rust. He went in & did the dirty work of dredging through Firefox profiling > It’s rare that a single micro-optimization is a big deal, but dozens and dozens of them are. Persistence is key Persistence is work. Mozilla is cutting the people who put in the work of staving off bitrot
- nnethercote 6y agoThank you for the kind words. To clarify: I am still at Mozilla! But I will be working fully on Firefox for the foreseeable future. I have edited the opening paragraph of the post to make this clearer.
- __s 6y agoGlad to hear, as someone who continues to use Firefox it's reassuring to know we'll continue to benefit from your skills
- qzw 6y agoRust's loss is Firefox's gain. I'm sorry to see you leave your Rust work, but I think Mozilla is right to have their best engineers focus on their core product. If we hope to see Firefox survive and remain relevant, then Mozilla really needed to refocus their energies onto it. Also, I assume someone of Nicholas's caliber has a great deal of agency over their own career path, so perhaps a return to Firefox is not entirely unwelcomed by him.
- Ygg2 6y agoI'd honestly rather see Rust survive, than Mozilla. Mozilla is few years away from going Blink, and on deathbed. Rust is up and coming language.
- dividedbyzero 6y agoI'd like to see Mozilla focus on Firefox, so that there it remains a viable alternative to Blink-based browsers for as long as possible. I think that may yet become really important as the effects of the incredible dominance of Google in the WWW become more apparent. I'd also like to see the Rust ecosystem prosper, but I guess others can take up the slack, it is gaining considerable momentum and quite a few places are looking into it, or using it already. If that isn't possible, is there much hope for it anyway?
- pedrocr 6y agoWhile I'd begrudgingly agree the two are not independent. I moved back to Firefox from Chrome exactly because Firefox became once again performance competitive thanks to Quantum. Most (all?) the big Firefox improvements were integrations of Rust code pioneered in servo. The only chance I see for Firefox is doubling down on that and replacing more and more components with those Rust rewrites. If not for that I don't see Firefox remaining competitive with Chrome for long.
- Ygg2 6y agoDidn't Mozilla like fire all of their Rust devs? There is no plans for supporting Rust in Firefox AFAIK.
- agumonkey 6y agoI still remember your blog entries about chasing memory use in firefox before quantum :)
- exmozilla 6y agoGlad you're still there. I had 10 years of time with Mozilla but was let go with the layoffs. First contribution was 20 years ago. From the folks I still stay in touch with morale is at an all time low but I hope Firefox recovers.
- sieabahlpark 6y agoMozilla is a terrible company, shame a lot of the people working on rust won't be able to do that anymore. Don't know who else is going to pick up the slack to continue progressing the language.
- steveklabnik 6y agoThanks for all you've done over the years here. I'm sad you won't be able to do more of it.
- k__ 6y agoThe title made it sound like the Rust compiler is at its performance limit and they doing the last possible optimization.
- The_rationalist 6y agoNnerthercote own the best blog on performance profiling that I've ever seen, congrats to your huge skill set, Firefox, chromium, and programming languages need more people like you.
- est31 6y agoIt's sad to see your rustc contributions stop, nnethercote. I guess rustc now has to run an experiment on how quickly performance improves without you :(. IMO compiler speed still remains the main ergonomics hurdle in developing Rust software.
- alex_reg 6y ago> ... Perhaps this relates to the high level of interest in Rust ... I would have loved these blog posts regardless of what code was actually being optimised. They offer a fascinating glimpse into a workflow that requires expertise, experimentation and creativity. Sadly something that most developers can't engage in very often, due to the nature of their work or time constraints.
- jimbob45 6y agoHow hasn’t Google taken over and hired the Rust team? Weren’t they practically funding them by funding their parent, Mozilla?
- steveklabnik 6y agoWell, most of the Rust team was not employed by Mozilla, so that’s one reason why they have not.
- nanagojo 6y agoWhat about the Servo team? Wouldn't they have an impact on Rust development?
- steveklabnik 6y agoThey certainly contributed, yes, but there are like two hundred people total on all of the Rust teams. Losing them hurts, they’re fantastic folks, but Rust is just way bigger these days.
- jimbob45 6y agoIt’s just that the team is right there for the taking and it’s so easy to hold control over the most exciting language of the next five years as Google instead of MS EEE’ing Rust soon.
- FartyMcFarter 6y agoDoes Google care about Rust?
- pjmlp 6y agoThey use it on ChromeOS, Fuchsia, are thinking of introducing it on Android, and driving the conversations of using Linux kernel modules written in Rust.
- vlovich123 6y ago> Contrary to what you might expect, instruction counts have proven much better than wall times when it comes to detecting performance changes on CI, because instruction counts are much less variable than wall times (e.g. ±0.1% vs ±3%; the former is highly useful, the latter is barely useful). Using instruction counts to compare the performance of two entirely different programs (e.g. GCC vs clang) would be foolish, but it’s reasonable to use them to compare the performance of two almost-identical programs (e.g. rustc before PR #12345 and rustc after PR #12345). It’s rare for instruction count changes to not match wall time changes in that situation. If the parallel version of the rustc front-end ever becomes the default, it will be interesting to see if instruction counts continue to be effective in this manner. This is a supremely surprising conclusion, especially in 2020. Is instruction count really still tied to wall clock count? I would have thought that some instructions could be slower than others (especially on x86) so that using more faster individual instructions could be faster than 1 slower instruction. Similarly, cache effects & data dependencies can result in more instructions being faster than fewer instructions. I think what the author is trying to say is that when evaluating micro-optimizations, cycle counts are pretty valuable still because you're making a small intentional change & evaluating its impact & usually the correlation holds. The dashboard clearly still measures wall-clock since just comparing instruction count over time would be misleading. I'm curious if the Rust team has evaluated stabilizer to be more robust about the optimizations they choose: https://emeryberger.com/research/stabilizer/ https://emeryberger.com/research/stabilizer/
- nnethercote 6y ago> This is a supremely surprising conclusion That's why I started the paragraph with "Contrary to what you might expect". As for Stabilizer: "Stabilizer eliminates measurement bias by comprehensively and repeatedly randomizing the placement of functions, stack frames, and heap objects in memory." Those placements can affect cycle counts and wall times a lot, but don't affect instruction counts.
- vlovich123 6y agoSo have you not found in practice any data dependencies or cache issues show up as bottle necks? Or do current tools just make this more of a blind spot for optimization? Also is there any work to multi-thread the Rust compiler on a more fine-grained level like the recent GCC work? I know you allude to that potentially that would make the instruction counts potentially less reliable so wondering if that's something being explored. Finally, while I have you, I'm wondering if there's been any exploration of the idea of keeping track of information across builds so that incremental compilation is faster (i.e. only bother recompiling/relinking the parts of the code impacted by a code change). I've always thought that should almost completely eliminate compilation/linking times (at least for debug builds where full utmost optimization is less important).
- xiaodai 6y agoHmmm... Rust needs alot more given its slow reputation
- cp-r 6y agoYes, compilation got a lot slower in 1.46 https://github.com/rust-lang/rust/issues/75992 https://github.com/rust-lang/rust/issues/75992 and there has been some breakage with `type_length_limit` errors.
- xiaodai 6y agoDon't know why I get down votes for pointing out the slowness of Rust which is well known
- lucozade 6y agoProbably because you just stated something that is well known without adding anything constructive?
- cesarb 6y ago> I was surprised by how many people said they enjoyed reading this blog post series. The appetite for “I squeezed some more blood from this stone” tales is high. There's something satisfying about seeing code get cleaned up and optimized. I also enjoyed following the LibreOffice commits back when they were in their "heavy cleanup" phase after it became clear OpenOffice was dead (which meant they didn't have to worry about diverging from the upstream anymore).
- deleted 6y ago[deleted]
- zem 6y agothe early neovim posts were very absorbing too
- oshea64bit 6y agoThis is a fascinating blog series. I've been dabbling in Rust lately and really appreciate how powerful and helpful the compiler is even to beginners. > Due to recent changes at Mozilla my time working on the Rust compiler is drawing to a close. This sort of statement makes me a bit worried though. I don't mean to echo what a lot of the community has said over the past month, but I really hope that development on Rust doesn't stagnate because of the layoffs.
- stackzero 6y agogg man. Really enjoyed your posts since starting rust.
- ndesaulniers 6y ago> The improvements I did are mostly what could be described as “bottom-up micro-optimizations”. > I also did two larger “architectural” or “top-down” changes My summer intern started doing profiling work on compile times with clang: https://lists.llvm.org/pipermail/llvm-dev/2020-July/143012.html https://lists.llvm.org/pipermail/llvm-dev/2020-July/143012.h... Some things we found: * for a large C codebase like the Linux kernel, we're spending way more time in the front-end (clang) than the backend (llvm). This was surprising based on rustc's experience with llvm. Experimental patches simplifying header inclusion dependencies in the kernel's sources can potentially cut down on build times by ~30% with EITHER gcc or clang. * There's a fair amount of low hanging fruit that stands out from bottom up profiling. We've just started fixing these, but the most immediate was 13% of a Linux kernel build recomputing target information for every inline assembly statement in a way that was accidentally quadratic and not being memoized when it could be (in fact, my intern wrote patches to compute these at compile time, even). Fixed in clang-11. That was just the first found+fixed, but we have a good list of what to look at next. The only real samples showing up in the llvm namespace (vs clang) is llvm's StringMap bucket lookup but that's from clang's preprocessor. * GCC beats the crap out of Clang in compile times of the Linux kernel; we need to start looking for top down optimizations to do less work overall. I suspect we may be able to get some wins out of lazy parsing at the cost of missing diagnostics (warnings and errors) in dead code. * Don't speculate on what could be slow; profiles will surprise you. > Using instruction counts to compare the performance of two entirely different programs (e.g. GCC vs clang) would be foolish, but it’s reasonable to use them to compare the performance of two almost-identical programs Agree. We prefer cycle counts via LBR, but only for comparing diffs of the same program, as you describe.
- epage 6y ago> for a large C codebase like the Linux kernel, we're spending way more time in the front-end (clang) than the backend (llvm). This was surprising based on rustc's experience with llvm. rustc sends large, generally unoptimized chunks to llvm, compared to clang. In Rust, the translation unit is at the crate level, causing llvm to do more analysis. MIR is also still relatively new and I think there is still work to be done doing optimizations in it to get less data sent to llvm.
- deleted 6y ago[deleted]