3 ms·

> Is it an unpopular opinion to say 75% of “a lot” is still “a lot” I don’t know if it’s unpopular, but it may be inaccurate. OP claims that they improved by 7

> Is it an unpopular opinion to say 75% of “a lot” is still “a lot” I don’t know if it’s unpopular, but it may be inaccurate. OP claims that they improved by 75%, so you probably meant “25% of a lot is still a lot”. > I would expect incremental build speedup to be prioritized, and steadily improving. But clearly it isn’t moving very fast in that direction. So why not? Is this assessment based on something? For what it’s worth, people have been working on it for years, with varying approaches and levels of success. The recent spate of articles you’ve seen is precisely because these approaches are bearing fruit. Several folks have worked on making a previously single threaded frontend multithreaded, others have added an option to swap the LLVM backend out for a much faster one (cranelift), and yet others are working on moving to a faster linker by default. The net gain from all of these once they land could be as much as 30–50%, depending on the project, mode of compilation (clean or incremental) and hardware (single/multiple cores). That is a pretty fantastic improvement, considering the whole year improvements in the last 4 years have been 7%, 17%, 13% and 15%, for an overall speed gain of 37%. If all of this doesn’t sound impressive, I’d encourage you to read nnethercote’s annual reports which explain how much effort went into making compile times faster. 2023’s report - https://nnethercote.github.io/2024/03/06/how-to-speed-up-the-rust-compiler-in-march-2024.html https://nnethercote.github.io/2024/03/06/how-to-speed-up-the... Ultimately, all of these improvements might not be enough for the people who need HMR to be productive. That’s possible. But the idea isn’t to get to a point where every line of code written in the world is Rust. There’s plenty of Rust development happening today. When the compile times drop as hoped, more people join and that grows the ecosystem.

dist1ll 3y ago
I have a feeling many of the common multithreading optimizations carry the same flaw as incremental compilation: they give you good speed-ups in the short term, but potentially mask deeply flawed architectural decisions. Essentially improving perf by digging yourself into a deeper grave.
klabb3 3y ago
> you probably meant “25% of a lot is still a lot” Yeah exactly. This was afaik a fairy small sized application (where the majority was probably framework code) which went from 20s to 5s for incremental compilation on a very beefy desktop rig. Those absolute numbers are important to grok the situation. > That is a pretty fantastic improvement, considering the whole year improvements in the last 4 years have been 7%, 17%, 13% and 15%, for an overall speed gain of 37%. > If all of this doesn’t sound impressive, I’d encourage you to read nnethercote’s annual reports which explain how much effort went into making compile times faster It’s not at all that it’s unimpressive. It’s abundantly clear that extremely bright minds are putting a ton of effort into it, consistently and over time. I’ve worked personally with some of these people and they are insanely talented and knowledgeable… Which is precisely why I’m concerned that we’re not seeing the big boosts that comes with picking low hanging fruit, perhaps there isn’t any left. Optimization tends to yield lower results over time (although the recent advances are great to see and I wish it continues). From the outside though, it appears like either inherent constraints that limit how far you can go, or at least initial compiler design reasons that would be cost-prohibitive to change.
- nindalf 3y ago
  > big boosts that comes with picking low hanging fruit, perhaps there isn’t any left. Optimization tends to yield lower results over time As the link I shared says > For the first time ever, I’m writing one of these posts without having made any improvements to compile speed myself. I have always used a profile-driven optimization strategy, and the profiles you get when you measure rustc these days are incredibly flat. It’s hard to find improvements when the hottest functions only account for 1% or 2% of execution time. Because of this I have been working on things unrelated to compile speed. > That doesn’t mean there are no speed improvements left to be made, as the previous section shows. But they are much harder to find, and often require domain-specific insights that are hard to get when fishing around with a general-purpose profiler. And there is always other useful work to be done. --- > From the outside though, it appears like either inherent constraints that limit how far you can go, or at least initial compiler design reasons that would be cost-prohibitive to change. Also correct. Rust prioritised faster run time over fast compilation times. For example, monomorphization is something used pervasively in most Rust code. Fast at run time, but slow to compile. The fact that the entire crate needs to be compiled if a line is changed is yet another issue. Everything indicates that even if Rust improves, it will never reach that 2 second recompile for large projects. But fortunately the experience of the last few years suggests that it's still possible to succeed despite (or maybe because of) prioritising runtime over compile time.

dist1ll 3y ago

I have a feeling many of the common multithreading optimizations carry the same flaw as incremental compilation: they give you good speed-ups in the short term, but potentially mask deeply flawed architectural decisions. Essentially improving perf by digging yourself into a deeper grave.

klabb3 3y ago

> you probably meant “25% of a lot is still a lot” Yeah exactly. This was afaik a fairy small sized application (where the majority was probably framework code) which went from 20s to 5s for incremental compilation on a very beefy desktop rig. Those absolute numbers are important to grok the situation. > That is a pretty fantastic improvement, considering the whole year improvements in the last 4 years have been 7%, 17%, 13% and 15%, for an overall speed gain of 37%. > If all of this doesn’t sound impressive, I’d encourage you to read nnethercote’s annual reports which explain how much effort went into making compile times faster It’s not at all that it’s unimpressive. It’s abundantly clear that extremely bright minds are putting a ton of effort into it, consistently and over time. I’ve worked personally with some of these people and they are insanely talented and knowledgeable… Which is precisely why I’m concerned that we’re not seeing the big boosts that comes with picking low hanging fruit, perhaps there isn’t any left. Optimization tends to yield lower results over time (although the recent advances are great to see and I wish it continues). From the outside though, it appears like either inherent constraints that limit how far you can go, or at least initial compiler design reasons that would be cost-prohibitive to change.

nindalf 3y ago
> big boosts that comes with picking low hanging fruit, perhaps there isn’t any left. Optimization tends to yield lower results over time As the link I shared says > For the first time ever, I’m writing one of these posts without having made any improvements to compile speed myself. I have always used a profile-driven optimization strategy, and the profiles you get when you measure rustc these days are incredibly flat. It’s hard to find improvements when the hottest functions only account for 1% or 2% of execution time. Because of this I have been working on things unrelated to compile speed. > That doesn’t mean there are no speed improvements left to be made, as the previous section shows. But they are much harder to find, and often require domain-specific insights that are hard to get when fishing around with a general-purpose profiler. And there is always other useful work to be done. --- > From the outside though, it appears like either inherent constraints that limit how far you can go, or at least initial compiler design reasons that would be cost-prohibitive to change. Also correct. Rust prioritised faster run time over fast compilation times. For example, monomorphization is something used pervasively in most Rust code. Fast at run time, but slow to compile. The fact that the entire crate needs to be compiled if a line is changed is yet another issue. Everything indicates that even if Rust improves, it will never reach that 2 second recompile for large projects. But fortunately the experience of the last few years suggests that it's still possible to succeed despite (or maybe because of) prioritising runtime over compile time.