11–20 of 61 posts
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.
How hasn’t Google taken over and hired the Rust team? Weren’t they practically funding them by funding their parent, Mozilla?
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/
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).
> 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,…
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.
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.
> 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,…
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.