Rust – Faster compilation with the parallel front-end in nightly
blog.rust-lang.org
blog.rust-lang.org
Glad to see this progress.
From a quick tokei, looks like 49kloc of Rust.
When using local disks, a 10k LoC project takes ~5 seconds to build
When using network FS, the same project takes ~23 seconds to build
strip = "debuginfo"
FWIW it does break debuggers since you won't have the symbols. Just comment it out when you need a build that has all of that info.
Also Java style of tiny classes and tiny files.
It’s an issue on both the implementation side and the thing-being-implemented
I would have thought Rust would be better on both fronts.
How many lines are the Rust codebases and their dependencies?
async-stripe takes over two minutes to build due to codegen. We're considering switching to dolladollabills.
Our core API server takes a minute to build, and we have about a dozen services and command line apps, a bunch of little shared library crates, two desktop apps, and a Bevy app.
Our Github actions docker build takes ~10 minutes if you don't include the tests, but we're starting to shave off more time. (Our monorepo is 105589 Rust LOC total)
I thought this was a joke. That has to be one of the best library names I've ever seen.
Ooohh interesting. We also use async-stripe, definitely going to have to check out dolladollabills though. Also in the Rust monorepo camp, our proof release takes ~5 mins from clean, tests are about 6 mins. We’ve invested a bit of effort getting our build-time down: don’t build in a docker container, we just copy the final artefact in-this wiped the most time of our builds. More parallel codegen units too.
Rust’s unique feature itself fundamentally depends on extensive static analysis. It’s not a design choice, it is pretty much what Rust is - a low-level language without a GC that is still memory safe. The price for that is hefty compile times.
Check out https://github.com/lqd/rustc-benchmarking-data/tree/main/res... and the other benchmarks in that repository for some data on how real world crates compilation times are spent. You'll find that backend code generation and optimization dominate most crates compile times. There are a few exceptions: particularly macro heavy crates, a couple crates with deeply nested types that hit some quadratic behavior in the compiler. But overall, the backend is still the largest piece.
I think Zig is correct in having different modes.
What you would need to go faster would be not only a non-monomorphizing compiler but also boxed types. That would be a very different language, one higher-level than even Go (which monomorphizes generics).
https://github.com/golang/proposal/blob/master/design/generi...
One of the explicit goals, by Go's creators, was fast build times. I still remember Rob Pike introducing Go during an all-hands at Google, where he talked about the very long build times for C++ and Java in Google's monorepo, and then showed some promising demos. (Most of us rolled our eyes at it then, because it was just a "hello world", but it's quite impressive how the language has evolved and remained true to its goals.)
> - it is just a plain language where the compiler can just spit out vaguely optimized code, and call it a day.
It's a simple language, but I wouldn't call it plain, nor characterize the optimizers that way.
Also, as can be seen, go is not a well-designed language, having language warts we knew for 50 years. I would take the creators’ claims with a huge grain of salt.
why do you think so? Their goal was to be much faster, but I can't find much benchmarks..
Unless you meant that Java's AOT compilation is faster than Go's?
Also, there are single-pass compilers that produce machine code, they are not fundamentally slower than a byte code generator. Of course extensive optimizations will be more expensive.
1. The compiler could ship binary artifacts, which would avoid all compilation of build scripts/ proc macros, and allow those to be compiled with performance optimizations enabled. This would be huge on its own.
2. Cranelift could potentially improve backend codegen compile times significantly as well.
3. Link times are still suboptimal, mold is promising here.
We can definitely still get significant wins out of the compiler.
Pretty sure compile times can get cut in half (or better) with those changes.
Also, mold was designed as an alternative to gold / lld, therefore it would require to be open-source and free on their main platform: linux.
It's AGPL on Linux now, and they sell commercial licenses for companies that won't touch that license, and they were contemplating earlier making mold only available under a non-free source available license like BSL, so there's no "requirement" as such that it be free and open source, even on Linux.
Do you have any data on this ? Maybe that's industry dependent, but I hardly know any Windows (not even talking about macOS, that's almost nil) developers outside of video games and web dev. 100% of Rust devs I know use Linux, to keep on the subject.
This is not a knock on Rust—I doubt it’s possible to do what Rust does—including zero overhead abstractions—in a fast compiling language. Go certainly pays a performance penalty with things like boxed generics.
But sure, twice as fast isn't fast, it's just faster. My point is that we're not at the point of serious diminishing returns, there's tons of stuff left to do.
It is a knock on Rust. The circumstances of Rust's state of existence in 2023, as a language created in this millennium but not in the last decade, are absurd.
> I doubt it’s possible to do what Rust does—including zero overhead abstractions—in a fast compiling language
People packaging releases for software written in Rust and others who are passive consumers and finding themselves downloading some project repo to compile from source for whatever reason (e.g. because the creators don't do binary releases themselves) don't need the Rustlang toolchain to do the things that active contributors to a given project (who want type system diagnostics, etc.) need from it.
I'd call this oversight a massive lack of imagination on the part of TPTB, but that would be wrong, because there is no need to imagine the differences between these use cases. They exist. An adequate toolchain for dealing with projects written in Rust—despite the deliberate decisions made during language design that led to these problems—does not.
Sorry, could you be more vague?
Anyway, your post seems to be about packaging software? Or something? Confusing since that has nothing to do with the language...
Yes, I can, since "2023", "this millennium", and "in the last decade" are all concrete, well-defined things.
I've been told that the Cranelift team (at least for the time being) doesn't have the intention on focusing on the optimizer to a degree where it would be competitive with LLVM's optimizers (which would also be a huge effort). So if you want faster compile times you would have to take significant performance hits (which for a lot of code compiled in CI is not a trade-off that people are willing to take).
(1) and (3) are still very significant, fwiw.
That being said, I definitely find the trade-off worth it. Though, I've never been the kind of programmer that desires the constant iteration and feedback of something like "REPL driven development".
Rust has a massive advantage, which is having a 'sanctioned' package manager and built-time capabilities. A huge part of Rust's slowdown is due to:
a) Having to compile build scripts
b) Those build scripts being built without optimizations (100s of times slower at runtime)
If cargo + crates.io supports pre-built dependencies that is a massive optimization.
This isn't theoretical or optimistic, it's just a fact - we can already see this by compiling build and proc macro crates with optimizations, it's just not the default and they still have to be compiled once. IF you remove that compilation time, again, it's not theoretical, it's turning N time spent on those deps into 0 time spent.
There is easily a 200% performance win available, just from the known optimizations that are on the table.
I'm hopeful something like watt (https://github.com/dtolnay/watt) will land in Cargo that'll allow us to ship pre-compiled wasm blobs for proc-macros so we can just have sandboxed binaries.
When you export a generic function in C++, every file that pulls it in has to re-parse it, and every instantiation has to re-type-check it. C++20 modules should help with the first part, but they can't help with the second (and neither can concepts). Further, separate translation units can wind up duplicating the same instantiations, which the linker has to deduplicate.
When you export a generic function in Rust, by the time it gets pulled in somewhere else, it takes the form of pre-parsed, pre-type-checked MIR. It can also be pre-optimized, so type-independent optimization work is shared between instantiations. The compiler can also tell, before instantiation, which type parameters a function does not actually depend on, and essentially erase them ("polymorphization"). Further, Rust's compilation model reduces the redundant duplicate instantiations C++ does, both by using larger translation units and by automatically sharing any instantiations in dependencies with their dependents (though you can do this by hand in C++).
(Incidentally, these differences also apply to inline functions- in C++ you wind up putting their definitions in headers and recompiling them from scratch over and over; in Rust they are shared MIR form.)
Rust makes the problems easier to fix, IMHO. So, maybe even with same (or slightly longer) compile times, you'll hopefully have faster time to delivery.
In fact, in my experience, Rust has faster time to delivery than any other language I've used. It takes forever to compile, but I have so many fewer runtime bugs that have to be caught (hopefully) by testing, that it still comes out ahead, overall (again, for me and my various projects).
I also find write-time to not be as slow as others complain about, except when it comes to async/futures where it is, indeed, pretty rough. But, if I sit and think about how many times I have to flip back and forth between my code and some library code to try and guess what exceptions it may or may not throw in other languages or whether something could be null or not, I find that the dev times aren't so much better in these other languages as people sometimes claim.
Sure, if you're a fulltime JavaScript dev with 10 years of experience, you might remember things like that calling the Array constructor with 0 or >1 arguments creates an array with those values, but if you call it with exactly 1 number, it will create an empty array with that capacity. But, since I have to switch between many languages regularly, my time to delivery is significantly reduced by nonsense like that. Likewise, it's reduced by NPEs in Java, double-frees in C++, Kotlin's inane idea to use exceptions for errors and coroutine control-flow, etc, etc.
The fact that my only complaint is that compile times are slower than I'd like should be seen as high praise.
This is a HN thread about a blog post about how compile times have become dramatically better thanks to newly introduced parallelism in an area that was completely single threaded.
> However, at this point the compiler has been heavily optimized and new improvements are hard to find. There is no low-hanging fruit remaining. But there is one piece of large but high-hanging fruit: parallelism.
From discussions I've seen, there's not much high-hanging fruit left either, short of rewriting the entire compiler for better incremental compilation.
Incremental matters more than clean build times because (A) you're likely to do a lot more of them (B) they break developer flow more than waiting on CI does (C) at least in theory, you can always add more cores to your CI and get reasonable speedups, less so for incremental.
Why not? If I add a new struct with `#[derive(serde::Serialize)]` I'll benefit from serde being compiled with optimizations.
> they break developer flow more than waiting on CI does
Eh, depends.
It might not get 10x better, but 3x isn't outside the realm of possibility. Just swapping the LLVM backend for cranelift can cut compile times in half.
The low-hanging fruit is gone but there are lots of hard but likely-significant improvements left on the table.
Don't hesitate to be brutally honest — nothing can shock me as my go-to compiler is GHC.
Here's the code: https://github.com/grapl-security/grapl/tree/main/src/rust
I seem to remember that caching was really, really bad.
Finished dev [optimized + debuginfo] target(s) in 16m 58s
What improvements are you expecting?
To balance / explain my point:
- my day work is Java / Kotlin with Gradle. Now, we can talk about glacial compilation times
- on my open source Rust project, we try to minimise dependencies, don't use macros (apart derive[Debug, Clone] etc...), and have a very moderate generics usage
If you take the time to `cargo build` my project, I'll be happy to have feedbacks on compilation times
I just did a clean build `cargo build`, 19 minutes 44 seconds.
I added 1 line (`dbg!("foo")`) and it took 14.76s
- cloc shows that there are ~70,000 lines of Rust
- with `cargo tree`, I see that the project depends on ~600 crates
In my toy project:
- cloc shows that there are ~40,000 lines of Rust
- with `cargo tree`, I see ~40 crates
I don't know the scope of grapl, but 600 (transitives) crates seems a lot to me. Maybe that explains why this particular build is so long. I haven't managed to build it (seems to have prerequisites on proto buffer stuff).
Naturally more crates means more time on compilation. Grapl is a pretty large project, lots of services that do different things, so it isn't too surprising that it has a lot of dependencies relative to what I assume is a more tightly scoped project.
For example, Grapl talks to multiple different databases, AWS services, speaks HTTP + JSON and gRPC (with protobuf), has a cli, etc etc.
Optimized: 1m 25s
cargo build 42.55s user 4.35s system 748% cpu 6.269 total
cargo build --release 99.38s user 4.13s system 267% cpu 38.660 total
(I can really recommend this box for Rust. I got it in August, should have waited for M3...)
Kudos for making hurl, it looks super-userful!
(I'm not suggesting that it's doing anything wrong. I'm just wondering if borrow checking establishes invariants that the back-end depends on for more than correctness, such that you couldn't do speculative back-end work that you would discard on a borrow checking error.)
AFAIK there are some optimization like the infamous `noalias` optimization (which took several tries to get turned on[1]) that uses information established during borrow checking.
I'm also not sure what the relation with NLL (non-lexical lifetimes) is, where I would assume you would need at least a primitive borrow-checker to establish some information that the backend might be interested in. Then again, mrustc compiles Rust versions that have NLL features without a borrow-checker, so it's again probably more on the optimization side than being essential.
Also the slowness is not because of lifetime checking. `cargo check` is very fast compared to `cargo build`.
mrustc gets past not having a borrow checker by compiling invalid programs that would have otherwise had compiler errors. This, at best, results in runtime segfaults etc.
Just like you don't need to validate syntax if you just assume you're only ever fed valid syntax.
Nothing wrong with that, just want to clarify for people.
> $ RUSTFLAGS="-Z threads=8" cargo build --release
Id expect the stabilized default to be number of cores. No idea where this effort is at but at one point they were going to use jobserver to coordinate across cargo's rustc invokations at which point cargo's job count will be used which defaults to number of cores (and supports counting down from that with negative numbers.
Very exciting as this is the one pain point for me personally so any and all progress is much appreciated
Also, these days it's possible to use cheat codes aka ChatGPT to flounder through almost all the difficult Rust problems that might have been show stoppers a few years ago. It's looking pretty great on that side of the fence.
It makes a huge difference.
For what it's worth, I'm working on a project with about 1000 dependencies and incremental debug build time is about 4 seconds on my laptop.
That's already pretty good.
Number of dependencies likely won't affect incremental build times except for linking and replacing it might offer some good gains for incremental builds.
Default linker is quite a bit slower.
And on my Macbook Air M2, where I actually develop, these things happen fast enough to call them instant. Perhaps I'm a bit spoiled there due to the excellent hardware. As a comparison, a Typescript project I'm working on using a more powerful Macbook always takes about 5-10 seconds to build.
I don't doubt that actually large Rust projects take a long time to build, though, but even these small and mid-sized were rather slow to build a few years ago.
You can follow my Dockerfile of my project as an example on how to do it
Ok, I guess I wait a bit longer before using `-Z threads` ;)
Rust has the opportunity to be serious, not lost like gcc.
It's not the language itself. It's not the safety and other attributes. And it certainly can't be the adoption (currently low % according to StackOverflow [0]).
It's how hyped Rust is. It's how effusive every blurb and sound bite seems to be. Glowing articles frequently make the front page of HN. Famous for penetration into Linux kernel development. What is this mechanism? Who is behind it? Is this veritable storm of hitting me on the head with Rust-this-Rust-that coordinated behind the scenes by some powerful entity? A hyperactive grassroots cheerleader squad? Does it infect C/C++ programmers who've dared to sample it once, turning them into noisy advocates, a la addictive drugs or parasitic fungi? Is Rust merely the It-Thing at the moment that people are mimetically/socially driven to latch onto?
We didn't see this with Lua, Ruby (that was mainly RoR anyways), Python, Swift, C#, certainly not newer-spec C and C++, or any of the others, even Java back in the day.
I don't know Rust, maybe it's deserving of the adulation. But I gotta say, the Rust marketing machine is one of the most superlative campaigns in IT I've ever seen.
[0] https://survey.stackoverflow.co/2022#most-popular-technologi...
Footnote: Some folk seem to be taking offense at my question where none is offered. I'm not for or against Rust, merely ambivalent & curious. Seen many of these waves come through, Rust is definitely the current wave, and the biggest so far! That is something I wish to learn from.
The other arguments (memory safety et al.) are sort of on the side imo; I really enjoy writing, reading and running rust because the developer experience is just so solid.
When I say "developer experience" I mean the crates system and cargo, not necessarily the language itself (which I find a bit ugly to be frank).
No, and have never been. C and later C++ are (were) just _that_ prominent, that most people never heard of the alternatives (except for Pascal and/or ADA, Objective-C and maybe D).
Nowadays there is Zig (most people have heard about that, I guess), Carbon, Cppfront, Odin, Jai, Vale, Austral (and some more I've forgotten about).
Objective-C requires a runtime, it's not a systems language because of that, I think Pascal is also requiring a runtime but that's not important right now.
D is a great example, I tried very hard to make D work and it just didn't.
I was even trying to use D-Langs own mailing list frontend (written in D) and it was nearly impossible for an outsider.
Contrast that to Rust, and aside from picking the right toolchain (nightly or stable); "cargo build" after following the quickstart on the internet will build practically all rust projects. With the minor caveat that if there are any bindings to system libraries then you need those too (libssl-dev for debian being a common requirement for openssl-sys for example).
Please don't take that as an offence, but please name at least 5 or 10 (which aren't "just" compiled to JS, I've actually forgotten about them ;). I've only heard about Elixir and Verse (yes, because of SPJ) which actually are somewhat used "in the wild".
But my point is exactly that Rust _is_ really an outsider by being significantly better than the (many or not so many does not matter that much ;) alternatives to C++.
Cedar, Ada, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Component Pascal, Object Pascal, Turbo Pascal, Delphi, Active Oberon, OCaml, Objective-C, Oberon-07
I bet you can manage yourself to find out when the other ones came into the world of computing.
NeXTSTEP drivers were written in Objective-C, macOS DriverKit is named in homage to the original NeXTSTEP DriverKit.
Metal is written in Objective-C, with C++14 as basis for Metal Shading Language.
As for adoption, moving goalposts, I thought we were talking about system languages being created, not about taking the computer market by storm.
It's the most loved language, by a wide margin, and has been for several years.
PS: and to be honest, I love programming in Rust. So I will defend it tooth and nail even if I can't use it in my day-to-day work at the office.
I'll echo your point about loving programming in Rust. I've programmed and continue to program in other languages (Java, PHP, Go), but nothing gives me the same joy as programming in Rust. I know it'll run the first time and likely work correctly as well. And what's more, it'll be faster than any code I could have written in another language.
Not everyone will feel this way, certainly. They, like GP, might come to this bizarre conclusion that noone could like Rust this much, and therefore there is a shadowy cabal promoting Rust for unknown reasons. I don't think there's much we can say to convince them otherwise.
But one thing I do when I see folks complaining that they've never seen such promotion on HN ever. I click on their profile to check how old their account is. Invariably it's 2016 or later. Which means they never saw the cycles of Ruby, JS and Go promotion. This will come and go. In a few years we'll be complaining about, I don't know, the relentless promotion of Mojo.
Provided that was the account they've been using since they started on HN ;)
i.e. JS allow webpages to do stuff without needing to reload the page every time. It basically lets you make mods for the browser! Like JQuery was really useful at the time and not now because everybody browser implemented their methods.
i.e. Ruby (Rails), IIUC it was super easy to do CRUD sites without spending as much time on the tedious plumbing/infrastructure stuff.
Nothing is perfect, but Rust is definitely more pleasant to work with (for me at least) than C++, JS, TS, Python, Go, or anything else I’m likely to get a job using. I do think it’d be fun to work in a Clojure or Elixir shop, but I’m still hobby-level on those, so probably it’s just the perception of green grass.
"...among users that respond to StackOverflow surveys."
It definitely did that to me. I remember trying out Rust and was amazed at how much abuse I'd put up with from C++ for all these years. Now I just want to try out Rust in a large enterprise project to see if it will just be replaced with a different kind of abuse...
Yes, that is a big part of it.
From my very subjective impression, having attended many Rust meetups with a constant influx of newcomers, I would say the two biggest groups that are really longing for Rust are:
- C (and sometimes C++) programmers that are looking for a breath of fresh air with modern tooling (e.g. package management) that isn't the result of decades of patchwork upon patchwork
- People that would like to work "close to the metal", but in the past were too tormeted by C/C++/Go segfaults(/other memory issues) to approach the subject. (That's also the group that I fall in)
> We didn't see this with Lua, Ruby (that was mainly RoR anyways), Python, Swift, C#, certainly not newer-spec C and C++, or any of the others, even Java back in the day.
I'm pretty sure we saw a similar hype with Ruby. If you go back ~10 years in the HN archives, you will see about as many "... in Ruby" posts as you see today with Rust. All the other languages listed are too old (I would guess "too old" means predating widespread social media), or have something obvious that alienates a big chunk of developers (e.g. Swift and .NET languages being essentially single-OS languages).
> A hyperactive grassroots cheerleader squad?
If anything the opposite. In the early days of Rust there existed the self-aware inside joke of the "Rust Evangelism Strike Force". Once people actually tried to meme to much with that (e.g. brigading subreddits), that was strongly rejected from inside the "community".
You're just seeing a project with genuine excitement behind it.
Rust feels like the language that in 1990 I was promised I would have in the year 2000.
I've been waiting a long time for a language that's fast, safe and allows me to dabble in functional-style programming.
At least Pascal syntax is fashionable again, across all newer languages.
I don't think that's part of marketing, unless you'd see for example a furniture company deciding to use a higher quality wood for their new tables as "marketing" because the tables will be nicer and customers will like that.
Rust gets a lot, a lot of small things right. The things you usually use as an excuse as to why one language or another is better - I found Rust does much more of them in a good way. In most other languages you can have let's say good package management but not fast iterator expressions, or you have compile-time iterator expressions but they are ass to write and package management does not exist, or you have both but all other features are missing, and etc.
Arguably, because Rust is also verbose and sometimes a bit ceremony-heavy, it's not a perfect language, which is why I use C# daily (which is similar and familiar enough with the tooling, package management and critical features like generics and async). But when I need lean and mean applications, there is simply no reason to pick anything but Rust except maybe out of curiosity.
Previously, I'd been involved in writing up samples of a CLI tool in each of Golang, Ruby, Haskell, C++, Python, Java, Clojure. From there we would select one language ecosystem to marry ourselves to and move forward. Every single one left us wanting in terms of either team capability/emotional levels, language expressiveness, distribution, speed, tooling, package management, etc. And I learned here that Rust seems to have each of these down pat to satisfactory degrees.
Next time I'm faced with birthing yet another CLI tool, I thinks I'm gonna try Rust first.
I often see comments like this on hn, but In my experience golang works great and I'm writing real time systems with it.
I think this is an error of perspective. The hype for Python and Ruby in the mid-2000s was off the charts. And the corporate marketing blitz for Java in the 90s was so beyond extreme that it will never be replicated in the space of programming languages.
Rust has zero marketing budget. The vocal adulation is a result of a confluence of coincidental factors that will never be replicated: an open-source, volunteer-run project from perhaps the only company with the proper combination of funding, technical chops, and open-source cachet to pull it off; an industry landscape that has so long rejected some of the best ideas from academic languages (e.g. tagged unions and pattern matching) that any language who can successfully express them to a non-academic audience will be seen as visionary; a specific niche (safe systems programming) whose exemplar never took off in the realm of FOSS, and who has failed to appeal to most segments of industry for whatever reason, with a ripe potential audience eager for a modern champion; slow-moving competitors in the systems space who had become complacent from lack of competition, and who are prevented from effectively competing at the safety niche without breaking backwards compatibility; a relatively friendly production-ready compiler backend in LLVM that suddenly makes competing in the high-performance cross-platform systems space at all feasible; an audience of newly-minted web devs looking to dip their toes into the systems space without needing to offer the traditional pound of flesh; a focus on standardized tooling that makes onboarding easy and going back to other languages painful; and a totally fortuitous, somewhat accidental, fairly brilliant realization that safe systems programming could be possible in the first place, thanks to a novel combination of affine types and region-based memory management, that worked so well that it took even the creators by surprise. Rust is lightning in a bottle.
Likewise the famous Gang of Four book, target at the enterprise space, also uses Smalltalk alongside C++, for the same reason.
Also Visual Age for Smalltalk was the ".NET" of OS/2.
Rust does a ton of things better than C++ as other people here are mentioning. For example, at my 20-man C++ shop, we have around 2 people's worth of full-time cmake work, that is, just maintaining the build system. This work would largely go away if it was a Rust codebase.
I think so. Sociological phenomenon initially bootstrapped by a small number of "influencers". Same with golang 10 years back. Same with frameworks (angular, react). Do you remember the hype around "XML revolution" around 2000? It was arguably bigger than rust's.
Somebody has to write a book on the history of software cults - it will make a fun read. :-)
This isn't to say it lacks any technical debt, but that the language feels very transparent and thoughtful. Contrary to say, a language built by a big company(.NET, Go) or built by strong opinions(Python). Rust in comparison feels modest in its delivery but ambitious in its design.
Its terrible reasoning for picking a language to write a project in, but Rust feels trustworthy I think.
I mean every language has some amount of "marketing" - people speaking at conferences, etc., but it's not like you're getting product advertising here in the form of commercials on TV or advertisements on the side of web pages. I think what you're seeing here is genuine interest.
Unless you're implying that HN itself has some sort of algorithm bias to push Rust posts to the top?
You haven't tried a cordless drill? Well, alright. You don't have to. You can survive without one. But rather than ask others what the big deal is at this point, why don't you just try one the next time you have to screw a picture to the wall. Borrow one if you don't want to commit to owning. Figure out for yourself whether having a charger and having to swap batteries is worth it. Maybe you'll decide it isn't. Maybe you'll be disgusted that you have to buy a new drill every 10 years while your 40 year old corded model still works fine.
But don't be too shocked if everybody else makes the leap. Sometimes the shiny new fad really is the future.
And you can still keep your corded drill around for those times when it really is the better tool for the job.
> But won't this steal resources from the top-level file parallelism?
It won’t. rustc uses jobserver protocol to coordinate parallelism with cargo, so the total amount of threads doing compilation of the whole project doesn’t exceed CPU count.
This, however, doesn't apply to the code generation phase with LLVM which is already parallelizable at the codegen unit level (the number of codegen units is configurable), but that's the “back-end”, whereas this new parallelization applies to the “front-end” of the compiler.
Sort of, it's managed at the crate level and not file or module indeed, but the compiler then splits crates into smaller chunks called “codegen units”.
See: https://doc.rust-lang.org/rustc/codegen-options/index.html#c...
> This flag controls the maximum number of code generation units the crate is split into. […] When a crate is split into multiple codegen units, LLVM is able to process them in parallel. […] The default value is 16 for non-incremental builds. For incremental builds the default is 256 which allows caching to be more granular.
> This, however, doesn't apply to the code generation phase with LLVM which is already parallelizable at the codegen unit level (the number of codegen units is configurable), but that's the “back-end”, whereas this new parallelization applies to the “front-end” of the compiler.
> When you compile a Rust program, Cargo launches multiple rustc processes, compiling multiple crates in parallel.