Comment by klabb3 | Hacker News Reader

Comment by klabb3 | Hacker News Reader

Is it an unpopular opinion to say 75% of “a lot” is still “a lot”, plus now you have to keep track of the knobs and constantly monitor for and be conscious about not wrecking build times as you’re maintaining and developing.

I’ve found in 10+ years of software development that speed of iteration cycle is highly correlated with productivity. Compile times is not the only input into this cycle time, but it’s a big one, and importantly, it’s within the control of the language tooling itself to solve. The human idle attention time of 1-2 seconds should be the gold standard to strive for, even if not always achievable.

There seems to be quite a bit of cope around Rust build times in the community, which was natural a few years ago (a lot of people used to “blame” llvm, but it doesn’t seem to be as big of a culprit) but things are different now, no? Given the maturity, growing ecosystem and corporate investment, 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?

> I’ve found in 10+ years of software development that speed of iteration cycle is highly correlated with productivity.

I agree, though in practice with many Rust programs that iteration cycle is actually not "edit, compile, run", it's "edit, save, wait for rust-analyzer to update" which is generally much quicker (even if it is sometimes still a little slow).

In most cases, Rust's very strong type system means you spend a lot less time actually running your program.

There are definitely exceptions though. E.g. if you're making a web app and editing CSS or whatever then the Rust compiler isn't going to tell you if you've got the colour wrong.

> a lot of people used to “blame” llvm, but it doesn’t seem to be as big of a culprit

It still is; there was a post here really recently where someone broke down the time spent in various phases. LLVM is still the vast majority, though apparently that is partly due to Rust generating a lot of work for it.

> I would expect incremental build speedup to be prioritized, and steadily improving.

It is.

> But clearly it isn’t moving very fast in that direction. So why not?

Because Rust's unit of compilation (a crate) is very large. In C/C++ it's a single file.

> I agree, though in practice with many Rust programs that iteration cycle is actually not "edit, compile, run", it's "edit, save, wait for rust-analyzer to update" which is generally much quicker (even if it is sometimes still a little slow).

This is one area that I think Dart did a good job on. They support both a JIT (I am not sure if it’s tiered) and AOT modes of compiling, the JIT targeted for development and AOT for production. This is the ultimate extreme of optimizing for both use cases, obviously it’s a ton of work, but I would love more languages to be like this. (I believe the JIT mode works directly on the source so there isn't an intermediate compilation step like Java, but it’s been a few years since I’ve used Dart)

[1]: https://dart.dev/overview#native-platform

I agree. And Dart's VSCode extension is suspiciously fast. Like it accurately finds compile errors in easily 100ms. I don't know what they've done so differently to pretty much every other system, where you're talking ~1-2s typically. It's very nice though.

This is the best of both worlds, that traces back to Lisp and BASIC environments.

Have all variants available and allow the devs to pick the right one for their current workflow.

Java, .NET, Eiffel, Common Lisp, Scheme, C++ (via stuff like ROOT and Live++, VC++ hot reload isn't that full proof), OCaml, Haskel, are all examples of these mixed tooling approach.

It is a single file, but when you include header files which get dropped in they can get to many hundreds of thousands of lines of code in practice per corresponding .o file.

But the level of parallelism possible is downright insane with C++ because of this property... once, out of anger at my build time on something I was working on back in 2016/2017, I set up a AWS Lambda as a compilation server (fully generic: all it had was my toolchain, not the code in question or even the build scripts) for something akin to ccache and successfully managed to build my project with a pipeline (I use that word as I was still doing the preprocessing locally) of at least a hundred simultaneous jobs: good luck ever pulling that off with Rust.

It is also generally very easy to break apart any file or decouple any header files using various techniques that don't affect your project layout or require any mental maintenance once done. In contrast, with Rust, you have to essentially refactor what your project even "means" to pull that off as you now need to be juggling a ton of microcrates (and then it seems like there is some inherent crate overhead so this becomes a painful tradeoff plane you need to optimize; compilation units have to become degenerated small before that matters in C++).

And, even then, the remaining slowest file in my insanely complex C++ project does tend to take a ridiculously long time to build (I have a 30-60 second long compile for one small component) and I have run out of low-hanging fruit; but, I honestly hardly ever actually have to build it: the coupling of header files is massively overstated as when you are in a tight build/update cycle you are generally modifying a single function in a source code file, not changing some header file of basic data types that will affect the code generation of literally the entire rest of the project.

Like, I get it: thinking about code as a merged set of linear forward passes is sometimes annoying, but it doesn't just enable massive gains in compile time... it also encourages more legitimate coupling between components as circular dependencies require extra code and upkeep for prototypes and that's good because circular dependencies are bad. Rust thereby is doing something that frankly feels super awkward: it is elevating behavior that frankly makes more sense only within a single file or at best a single object to a project organizational unit, which suddenly makes this all seem much more complicated to handle correctly.

> In most cases, Rust's very strong type system means you spend a lot less time actually running your program.

That just sounds wrong to me TBH. IME it never pays off to 'front-load' too much, you might get a working implementation of your original idea without ever running the code, but that original idea will almost certainly be "wrong" once you see it in action and you just wasted a lot of time agonizing over your type structure which turned out to implement a quickly outdated idea.

Nothing beats quick iteration on a running program when it comes to productivity.

> Because Rust's unit of compilation (a crate) is very large. In C/C++ it's a single file.

If the a C++ file includes any C++ stdlib header it will also also become very large (tens of thousands of lines of gnarly template code for common headers like <vector> or <string>). If the unit of compilation is a crate in Rust it should actually be faster to build than typical C++ projects which often put the implementation for one class into one source file (and each of those source files is expanded to tens of thousands of lines of code after includes are resolved).

C mostly doesn't suffer from this problem though, since C header typically are only a couple dozen or hundred lines of API declarations.

> If the a C++ file includes any C++ stdlib header it will also also become very large (tens of thousands of lines of gnarly template code for common headers like <vector> or <string>). If the unit of compilation is a crate in Rust it should actually be faster to build than typical C++ projects which often put the implementation for one class into one source file (and each of those source files is expanded to tens of thousands of lines of code after includes are resolved).

> C mostly doesn't suffer from this problem though, since C header typically are only a couple dozen or hundred lines of API declarations.

But then, there's no reason why Rust couldn't be like C. The issue comes from the dependencies and libraries bundled, which is not an issue per se of the language.

This sounds overblown to me, TBH. IME you hardly need to agonize over type structure for common day to day code. The benefits of the type system are highly advantageous to refactoring without causing breakage, so I become more nimble in getting towards the proper structure. This is precisely what allows me to iterate more quickly and is a benefit.

I had lots of coffee pauses when doing builds back in 2000, where our C bindings for the Tcl based server, used as Apache and IIS modules, across Aix, HP-UX, Solaris, Windows 2000/NT, Red-Hat Linux would take one hour per platform on average.

> in practice with many Rust programs that iteration cycle is actually not "edit, compile, run", it's "edit, save, wait for rust-analyzer to update" which is generally much quicker

Rust-analyzer is struggling significantly on larger repos, to the point of being barely usable.

Is this with the likes of Leptos? The fancy HTML macros add a ton of compilation time (and are an antipattern IMO).

No, just ordinary distributed systems stuff. tokio, serde, bincode, error/logging/testing crates, and stdlib.

> Because Rust's unit of compilation (a crate) is very large. In C/C++ it's a single file.

What do you mean exactly here?

In C++ you can compile each file independently from every other file. You can't do that in Rust; you can only compile crates (which are made of many files) independently. Within a crate you can have circular references for example.

So the smallest chunk of work that can be parallelised is much bigger in Rust than in C++. (Unless you are writing atypically small Rust crates and atypically enormous C++ files.)

I understand that's not a language limitation, but rather a compiler/toolset/ecosystem issue (like not having a standard ABI?).

I ask becasue I wonder what's the real culprit here and whether it can be solved or if it's due to the language.

It is like you say, mostly compiler/toolset/ecosystem, all 3.

While staying in the same ecosystem you can split your application into smaller crates, which many are doing. It's just not that ergonomic.

It kind of is a language limitations. They could have said "no circular dependencies at all!" (which is quite reasonable) and then it would be easier to deal with.

> In most cases, Rust's very strong type system means you spend a lot less time actually running your program.

> There are definitely exceptions though.

I mean.. I know what you mean but this is kinda what I meant with cope. Putting “running code” aside as an edge case seems like a dangerous moving-the-goalpost kind of Rustism that kinda grew out of the “Rust is so safe that if it compiles it’s correct”-meme. Once we’re doing serious and boring good old development, it’s a redeeming quality at best, imo. Not to mention that rust analyzer also suffers slowdowns in similar ways.

> LLVM is still the vast majority

That’s interesting. So why the meager numbers from cranelift then, judging by the post? Granted, I’m not doing Rust day-to-day anymore so I’ve been ootl.

> Because Rust's unit of compilation (a crate) is very large. In C/C++ it's a single file.

Isn’t this the same for Go? Sure, it’s a simpler language but we’re talking many, many times on similar sized projects (wish I could link to something but unfortunately anecdotally only). Is it monomorphization, macros, or just everything combined?

> So why the meager numbers from cranelift then

People are seeing 20-30% improvements thanks to Cranelift. Not sure why you think that’s meagre.

> edge case

It’s not an edge case but it is valid to say that the pattern of development is different. You’re right that people need feedback that what they’re doing is right within 1-2 seconds. They are getting that thanks to the IDE. They need their tests to compile and run within a few seconds, and they’re getting close to that.

I’m not disagreeing with you. In an ideal world all builds and tests would run within 2 seconds, like you’re suggesting. And yet, people are managing to ship software successfully, despite it taking more than 2 seconds. That suggests that maybe this 2 second thing isn’t a requirement and more of a nice to have. And that maybe, there is something to people relying on IDE feedback while coding.

In C++ it can be a module nowadays, which is similar to being a crate, yet it is faster, from my clang/vc++ experience.

> 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...

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.

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.

> 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.

> 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.

Reply on news.ycombinator.com