gg man. Really enjoyed your posts since starting rust.
How to speed up the Rust compiler one last time
31–40 of 61 posts
Re: How to speed up the Rust compiler one last time
#32> 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…
[deleted]
Re: How to speed up the Rust compiler one last time
#33> 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.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.
Re: How to speed up the Rust compiler one last time
#34Earlier quoted context omitted.
What about the Servo team? Wouldn't they have an impact on Rust development?
They 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.
It’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.
Re: How to speed up the Rust compiler one last time
#35Hmmm... Rust needs alot more given its slow reputation
Don't know why I get down votes for pointing out the slowness of Rust which is well known
Re: How to speed up the Rust compiler one last time
#36> 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,…
> 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..
There are some fun cases where that is definitely true, to whit pdep / pexp on Zen based architectures. https://dolphin-emu.org/blog/2020/02/07/dolphin-progress-rep...
https://twitter.com/uops_info/status/1202950247900684290
> I just ran some tests: the performance seems to depend heavily on the value in the last operand; this is also the case for the register variants. If the last operand is set to -1 (i.e., all bits are 1), the instr. has 518 uops and needs more than 289 cycles!
Re: How to speed up the Rust compiler one last time
#37Re: How to speed up the Rust compiler one last time
#38> 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…
the early neovim posts were very absorbing too
Re: How to speed up the Rust compiler one last time
#39Earlier quoted context omitted.
Thank 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.
Rust'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 enti…
I'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.
Re: How to speed up the Rust compiler one last time
#40> 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,…
> 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.. There are some fun cases where that is definitely true, to whit pdep / pexp on Zen based architectures. https://dolphin-emu.org/blog/2020/02/07/dolphin-progress-rep... https://twitter.com/uops_info/status/1202950247900684290 > I jus…
From what I can tell, Zen based architectures have a slow compatibility-only emulation of those two instructions because the fast implementation is patented - and it's patented by a university who've got some kind of deal with Intel involving co-development of the instruction, rather than by Intel themselves, so AMD's patent cross-license doesn't cover it.