The rust parallel compiler is something that is being worked on (or was being worked on at some point) - are people in favour of this idea of parallelising as many things as possible? Interesting to hear peoples opinions.
#Rust parallel compiler
cinder nacelle
barren tartan
If it helps compile time, sure, although I do build sometimes on a 2core server, which I don't want getting much slower
grizzled cove
The rust parallel compiler is something that is being worked on (or was being wo...
I mean, duh, people want things to be faster 
lapis venture
I've personally not had a problem with compile times on my dev machine (lots of cores). I have a bigger problem with them on CI with single threaded VMs 
split horizon
the Rust compiler is already parallelized to a good degree, but the fact of the matter is that the compiler still spends most of the time in codegen
since individual crates undergo codegen separately (and the final bin, staticlib, cdylib or dylib crate drives some of the codegen for things like generic code and #[inline]), it's naturally parallel to some extent
if you have at least 12 dependencies on a 12-thread processor, the compilation process will just be parallel and concurrent without any sort of additional synchronization overhead: the OS scheduler and I/O manager will do the heavy lifting in a lightweight fashion, and Cargo will orchestrate the concurrent build process
in general, with individual crates being compilation units (same build process role as individual .c/.cpp files in C/C++), splitting up your code into multiple crates has a positive effect on compile times
proud jacinth
the Rust compiler is already parallelized to a good degree, but the fact of the ...
Not really, actually
Currently rustc isn't really parallel at all, the only "parallelism" comes from cargo spawning multiple rustc instances, each crate is entirely serial in its processing
And codegen is the one of the few things that actually is parallelized right now
lapis venture
Monomorphisation could probably benefit from parallelism. I remember that being kinda slow on some projects
split horizon
Currently rustc isn't really parallel at all, the only "parallelism" comes from ...
that's exactly the point I'm making: rustc itself won't benefit nearly as much from its own parallelism as people would expect it to
it would only marginally gain performance when the amount of remaining crates to compile drops below the amount of threads in the system
proud jacinth
No, parallelism allows rust to be parallel over a single crate
Meaning that each individual crate's compilation is faster
split horizon
in theory, yes
in practice, if 12 crates are compiling in parallel on a machine with 12 threads, that (ideally) puts it at 100% CPU usage
it doesn't help if you create more threads in every process
they'd just be competing for CPU time with each other
lapis venture
Depends on the dependency pipeline. If cargo could know the pipeline and how many crates it expects will be at each point, then it can tell rustc to use a different num of threads
ocean bridge
Monomorphisation could probably benefit from parallelism. I remember that being ...
very slow in things like warp
lapis venture
Yup...
final igloo
split horizon
last time I used hardware of that sort, I couldn't really get Rust up and running because the browser froze for several hours way before I could navigate to the Rustup installer download page
webtech is horrid
kindred berry
it would only marginally gain performance when the amount of remaining crates to...
if rust could compile huge blocker crates like syn or proc_macro2 in parallel it would probably make a noticably difference
split horizon
it could, but only if those kick in fairly lately in the build process
Cargo could start compiling large crates first based on some heuristic or even manual configuration, which may reduce the chance that they're gonna end up last in the build queue with no other jobs to work on the other cores at the same time
proud jacinth
Parallel rustc would allow running procs in parallel, if that's what you're meaning
s/would/could/
kindred berry
let me compile a project or mine really quick with --timings
split horizon
other than that, there's a fundamental limitation to how much you can improve performance by implementing concurrency in individual tasks
kindred berry
proud jacinth
Yah, but luckily lots of the things that rustc does are super easy to parallelize
proud jacinth
Lotta for loops and things that are generally unrelated to each other
kindred berry
if syn was 3 times as fast, I would have saved probably more than 10% of the entire compile time
also fully blocking crates in at the end, would be nice if those were faster
and if tokio wasn't so slow, hyper could have started a lot earlier
split horizon
this makes sense, I never thought about how much time Cargo spends blocking on other crates
kindred berry
this shows really well how cargo parallelizes a lot which makes things bearable, but we're far from always being maxed out, many bottlenecks
proud jacinth
Parallel compilation essentially aims to lower the per-crate compile time
Which ideally increases overall throughput
split horizon
syn's actually one of the best examples you could get, you can't just reorganize the build to extract initial metadata from the crate, supply it to concurrent build jobs and let codegen run as a separate story
so lots of crates just sit around waiting for another rustc instance to explain them what a Punctuated is
proud jacinth
Yep, pretty much
kindred berry
you have this chain
proc-macro2 build script -> proc-macro2(build) -> proc-macro2 -> quote -> syn -> tokio-macros -> tokio -> hyper -> axum -> my crate
no matter how many cores you have, this will be the bottleneck
and fun fact, since these were almost chained, it wouldn't have made a big difference whether I had just those crates or 100 others, this was my compile time
proud jacinth
Yah, on a hyper-ideal level rustc would actually know what crates are, but I don't know how conceivable that is
That'd allow running everything within one process where all resources would be shared as efficiently as possible
Only the things actually needed for the final binary would be further processed
kindred berry
I would have saved over 2 seconds if proc-macro2 didn't need a build script :(
kindred berry
you have this chain
`proc-macro2 build script` -> `proc-macro2(build)` -> `proc...
this is a fun TIL, I knew that there were blocking crates and all, but I wasn't aware that my compile times could not have been really faster even with twice as many cores
until rustc gets more parallel that is 
proud jacinth
Yah, compilation is ultimately (right now) limited by the dependency tree
That's why a lot of times you'll end up sitting on the very last crate (the current one) being compiled while nothing else happens
kindred berry
the dependency tree, also known as proc-macro2 -> quote -> syn
kindred berry
That's why a lot of times you'll end up sitting on the very last crate (the curr...
yes, at the end everything slows down since it slowly becomes one
there are two highly parallel batches, pre-syn, where many small crates that don't transitively depend on syn get compiled, then everything slows down and waits for syn, after which the post-syn batch gets started where everything speeds up again
syn is definitely the most influential crate for build times
proud jacinth
It's not really fair to blame syn
kindred berry
I'm not "blaming" syn
proud jacinth
Any crate that lots of things depend on will have this effect
kindred berry
well, I'm blaming syn but not in a negative way
proud jacinth
It's the leftpad effect, kinda
kindred berry
syn is a very good crate, and the rust ecosystem would be worse without it, but it's a very interesting case study about scheduling and build times