21–30 of 61 posts
Thank 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!
> 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,…
> 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.
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).
Thank 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!
Considering that nnethercote is still with us at Mozilla, I sure hope that he doesn’t get hired away! :-)
Earlier quoted context omitted.
> 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.
So 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 b…
There is an experimental parallel rustc front-end, e.g. see https://internals.rust-lang.org/t/help-test-parallel-rustc/1...
> any exploration of the idea of keeping track of information across builds so that incremental compilation is faster
That's exactly what incremental compilation does.
Nicholas 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
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.
> 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.
How hasn’t Google taken over and hired the Rust team? Weren’t they practically funding them by funding their parent, Mozilla?
Well, most of the Rust team was not employed by Mozilla, so that’s one reason why they have not.
Earlier quoted context omitted.
Well, most of the Rust team was not employed by Mozilla, so that’s one reason why they have not.
What about the Servo team? Wouldn't they have an impact on Rust development?
Hmmm... Rust needs alot more given its slow reputation
> 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,…
> We see that something external and orthogonal to the program, i.e., changing the size (in bytes) of an unused environment variable, can dramatically (frequently by about 33% and once by almost 300%) change the performance of our program. This phenomenon occurs because the UNIX environment is loaded into memory before the call stack. Thus, changing the UNIX environment size changes the location of the call stack which in turn affects the alignment of local variables in various hardware structures.
From https://www.inf.usi.ch/faculty/hauswirth/publications/asplos....