Live data from Hacker News

Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

feldera.com

51–60 of 89 posts

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#51
post #8

> despite having a 64-core machine with 128 threads, Rust barely puts any of them to work. Rust is fast in theory, but if in practice they can't even get their compiler to squeeze any juice from the CPU, then what's the value of that language from a software engineering viewpoint?

Compilation is inherently pretty hard to parallelise, and various design decisions around how Rust modules/creates work make it even harder (as demonstrated by achieving greater parallelism here with many smaller crates). There's no particular reflection on the performance of rust code here, it's really a design/algorithms problem.

[deleted]

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#52
post #45

The main issue here is: - in rust one semantic compilation unit is one crate - in C one semantic compilation unit is one file There are quite a bunch of benefits in the rust approach, but also drawbacks, like huge projects have to be split into multiple workspaces to maximize parallel building. Oversimplified the codegen-units setting tells the compiler into how many parts the compiler is allowed to split the a singl…

> Now it still seems strange (as in it looks like a performance bug) that most times rust was stuck in just one threat (instead of e.g. 8). Agreed, seems like there are some rustc performance bugs at play here.

I haven't dug into the details, but it may not even be a performance bug, depending on how you define 'bug': the Rust compiler is not fully parallel itself yet. That's a bug in the sense of something that needs to be improved and fixed, but isn't one in the sense of "unexpected bad behavior".

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#53
post #17

Earlier quoted context omitted.

> Compilation is inherently pretty hard to parallelise I don't agree. In a large project there is going to be a lot of stuff that can be compiled in parallel without problems.

And Rust's module design makes this significantly more complicated than in superficially-similar languages. That's why splitting it into modules brings drastic improvements - you are effectively giving the compiler clear boundaries across which it doesn't need to propagate as much information.

Splitting it into crates, not modules.

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#54
post #29
post #25

Earlier quoted context omitted.

Except the Rust ecosystem lacks the solutions we have in C++ land to compile fast and have easy paralelisation of builds. Because C and C++ communities for historical reasons embrace binary libraries, and binary component frameworks like COM, so while in theory a full build from scratch takes similar time as Rust, in practice that isn't the case. Also note that D, a language as complex as C++, with three compilers, o…

> Also note that D, a language as complex as C++ While D is complex, it's a different beast than Rust. I suspect think various checks, from lifetime to trait resolution, might make it more complex to parallelize than C++.

Rust is already able to do more fine-grained parallel compilation than C or C++, at least in the codegen step. The "codegen units" concept doesn't work for those languages.

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#55
post #45

Earlier quoted context omitted.

> Now it still seems strange (as in it looks like a performance bug) that most times rust was stuck in just one threat (instead of e.g. 8). Agreed, seems like there are some rustc performance bugs at play here.

I haven't dug into the details, but it may not even be a performance bug, depending on how you define 'bug': the Rust compiler is not fully parallel itself yet. That's a bug in the sense of something that needs to be improved and fixed, but isn't one in the sense of "unexpected bad behavior".

Makes sense. We'd appreciate some more eyeballs here for sure. Between HN and a Reddit thread, there are a few hypotheses floating around. I've shared a repro here for anyone interested: https://github.com/feldera/feldera/issues/3882

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#56
post #55

Earlier quoted context omitted.

I haven't dug into the details, but it may not even be a performance bug, depending on how you define 'bug': the Rust compiler is not fully parallel itself yet. That's a bug in the sense of something that needs to be improved and fixed, but isn't one in the sense of "unexpected bad behavior".

Makes sense. We'd appreciate some more eyeballs here for sure. Between HN and a Reddit thread, there are a few hypotheses floating around. I've shared a repro here for anyone interested: https://github.com/feldera/feldera/issues/3882

You may want to post on the Zulip, I think that's the way to get in touch with the team these days.

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#57
post #18
post #16

Earlier quoted context omitted.

C++ is fast in theory, but if they can't get C++ compiler (LLVM) to squeeze any juice from CPU, then what's the value of that language from a software engineering viewpoint. Hopefully, you can see why this reasoning is a problem. The main stumbling point being compilation speed != runtime speed.

I have been using make's -j flag to compile C++ projects with great success. The main point being, Rust focuses on the wrong type of optimizations.

I also use make -j for C++ with great success. And so I am also stuck with having to declare my functions in a separate file from where they're defined, and thus when stepping through code with a debugger or just a good source viewer that can jump to callers/callees, I never see the comments because they're in the header not the source. Not to mention the problems I run into when linking with a library that was compiled with different options or a different version of the source. And bending over backwards to implement concurrent algorithms to get decent runtime performance, and debugging the inevitable bugs that follow.

Rust focuses on a different set of optimizations. I'm still working out when I prefer the Rust set or the C++ set or the Python set. I want to love Rust, but when doing exploratory work with unfamiliar APIs, the slow recompile loop and need to get everything correct for each incremental experimental build I do to try to figure out how something works is pretty painful. I don't know how much better it gets with familiarity. Rust is very nice when I fully understand the problem I'm solving and the environment I'm working in, and I vastly prefer it to C++ for that. But I frequently dive into unfamiliar codebases to make modifications.

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#58
I have just went through this with a project of mine, though unfortunately the code wasn’t autogenerated, so I needed to do a lot of mind-numbingly boring search-and-replace commands. I have cobbled together a little utility that allowed to automate the process somewhat.

Mostly a throwaway code with a heavy input from Claude, so the docs are in the code itself :-)

But in case anyone can find it useful:

https://github.com/ayourtch/tweak-code

Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates

#59
I love Rust, but it seems like a really bad intermediate language if you have a compiler/transpiler which is sound. You don't need the type system from Rust telling you something's wrong.

That said, I could see how it would make writing the transpiler easier, so that's a win.

Post reply on HN