Are there any performance implications for the final binary because you’re splitting it up into thousands of crates?
Loss of inlining
Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
11–20 of 89 posts
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#12> back of the envelope calculation for how long it should take: 25 min / 128 = 12 sec (or maybe 24 sec since hyper-threads aren't real cores). Yet it takes 170s to compile everything.
I'd aim for this linear speedup for compiling (sans overhead to compile a small crate), but the linking part won't be faster, maybe even slower. Maybe a slightly bigger envelope can tell you how much performance is there to extract and the cost of using "too many" crates (which I'm not even sure it's too many, maybe your original crate was too big to ease incremental compilation?)
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#13> We're using rustc v1.83, and despite having a 64-core machine with 128 threads, Rust barely puts any of them to work. > That’s right — 1,106 crates! Sounds excessive? Maybe. But in the end this is what makes rustc much more effective. > What used to take 30–45 minutes now compiles in under 3 minutes. I wonder if this kind of trick can be implemented in rustc itself in a more automated fashion to benefit more projec…
1106 crates? Are they sure this is not a Javascript project?
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#14> We're using rustc v1.83, and despite having a 64-core machine with 128 threads, Rust barely puts any of them to work. > That’s right — 1,106 crates! Sounds excessive? Maybe. But in the end this is what makes rustc much more effective. > What used to take 30–45 minutes now compiles in under 3 minutes. I wonder if this kind of trick can be implemented in rustc itself in a more automated fashion to benefit more projec…
1106 crates? Are they sure this is not a Javascript project?
They compile their customers' SQL to Rust code. Hence the preponderance of crates. It's a somewhat unique scenario.
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#15> Given that we now fully utilize 128 threads or 64 cores for pretty much the entire compile time, we can do a back of the envelope calculation for how long it should take: 25 min / 128 = 12 sec (or maybe 24 sec since hyper-threads aren't real cores). Yet it takes 170s to compile everything.
Amdahl’s Law would like to have a word.
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#16> 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?
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.
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#17> 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.
> 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.
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#18> 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?
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.
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#19That's a cool project.
But I wonder if generating rust is the best approach. On the plus side, you can take advantage of the rich type and type checking system the compiler has. On the other hand, you're stuck with that compiler.
I wonder if the dynamic constraints can be expressed and checked through some more directly implemented mechanism. It should be both simpler to express exactly the constraints you want (no need to translate to a rust construct that rustc will check as desired), and, of course, should be a lot more efficient. Feldera may have no feasible way to get away from generated rust, but a potential competitor might avoid the issue. (That's not to say the runtime shouldn't/couldn't be implemented in rust. I'm just talking about the large amounts of generated rust.)
Re: Cutting down Rust compile times from 30 to 2 minutes with one thousand crates
#20The 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…
Agreed, this is the underlying main issue. I've faced it before with generated C++ code too, and after long and painful refactorings what ultimately helped the most was to just split the generated code into multiple compilation units to allow for parallel compilation. It comes with the drawback of potentially instatiating (and later throwing away) a lot more templates though