31–40 of 89 posts
> 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?
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.
Earlier quoted context omitted.
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.
> 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…
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.
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…
except the company had a straight forward solution to the problem
and it's not always possible in C++ land either
and COM isn't part of C/C++ but a microsoft specific extension which solves very different issues as it's for cross application communication while we here have compile time perf issues inside of a single library
> binary libraries
I'm not sure if you mean dynamic linking or binary objects but there is the thing:
- dynamic linking isn't the issue here as the issue has nothing to do with re-compilation and similar (where dynamic linking can help),
- binary object files on the other hand are also something rust has and uses, it just sets the boundaries in different places (crate instead of file) which makes development easier, can lead to better runtime performance etc. It just has the drawback that you sometimes have to split things into multiple crates.
> a language as complex as
how complex a language is to write has not too much to do with how complex it is to split a single code unit into multiple parts for parallel compilation. C, C++ and D mainly side steps this by making each file a compilation unit, while in rust it's each crate. But that isn't fundamentally better or worse, it's trade offs. It's trade offs.
> because Walter Bright did the right decisions on what to focus for development workflow.
and so did rust, just with different priorities and trade offs
and given that D is mostly irrelevant and rust increasingly more successful maybe it was pursing the more important priorities
Also the OP case is about release builds i.e. not the normal dev loop
neither does the splitting affect dev experience as it's all auto generated code
and if projects which aren't auto generated it's very normal to split out libraries etc. anyway, and weather you split them into their own module, file or crate doesn't matter too much as long as you keep code clean (as in not having supper entangled Spagetti code)
and I wouldn't even be sure if D does perform in any relevant way better in compiler time if you compare their performance with the end result after they split the crate
> 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…
Towards the end, the article says it takes 7s for linking using mold.
That'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 n…
The right way done by the likes of Oracle and SQL Server is to JIT compile their queries and stored procedures, with PGO data from query analyser.
Eminently pragmatic solution — I like it. In Rust, a crate is a compilation unit, and the compiler has limited parallelism opportunities, especially since rustc offloads much of the work to LLVM, which is largely single-threaded. It’s not surprising they didn’t see a linear speedup from splitting into so many crates. The compiler now produces a large number of intermediate object files that must be read back and link…
They mention that compiling one crate at a time (-j1) doesnt give the 7x slowdown, which rules out the object file/caching-in-rustc theories... I think the only explanation is the rustcs are sharing limited L3 cache.
It will give you a workspace with a bunch of crates that seems to exercise some of the same bottlenecks the blog post described.
Earlier quoted context omitted.
Towards the end, the article says it takes 7s for linking using mold.
Yeah, I read that part too late. In that case it seems that there's indeed a lot of overhead when building many crates from a cold-start, but it pays off in wall time and can probably save resources in incremental builds.