7 ms·
What part of Rust compilation is the bottleneck?
- hobs 3y agoGood article, just throwing out there that flamegraphs would be exactly what you need for visualizing this stuff.
- foota 3y agoIt looks like the profile they're build on already supports those, I think the intention here is to present a sort of at a glance view that could be quickly analyzed.
- hobs 3y agoMakes sense. In my opinion I would just generate fake flamegraphs then - they are much more readable and the format is dummy easy to fake.
- kobzol 3y agoYeah, I actually generated these small charts out of a flamegraph, because it contains too much information and isn't easily split into three distinct parts. And once you condense the information into just 3 blocks, then using a flamegraph doesn't really add any further value, IMO.
- hobs 3y ago/shrug that's fair, with only like four things its not that much more readable.
- yu3zhou4 3y agoFWIW Jakub has more blog posts on his website which are also really interesting https://kobzol.github.io/ https://kobzol.github.io/
- AndrewDucker 3y agoCould LLVM be speeded up by passing it the data in a more efficient structure? Or by slimming down the data it's passed in some way?
- Sharlin 3y agoIt’s well known that the LLVM IR bytecode generated by rustc is terribly verbose – Rust constructs mostly get lowered very naively to a buttload of redundant IR, to be then pruned and condensed by the backend. This is by design, as it helps keep the frontend as simple and fast as possible, but there are certainly cases where it would be a net benefit to move some of the complexity to rustc in order to lighten LLVM’s workload.
- davidhyde 3y agoIf you make a small change to your application, the Rust compiler does a significant amount of rework. That is, it recompiles a lot of code that it has already compiled before. There are valid technical reasons for this because of how LLVM works or that the linker needs to rewrite all addresses. Yes, incremental compilation is a thing but it’s too coarse IMO. To me it seems that taking an extremely fine grained approach to compilation would improve the ergonomics of the iterative hack-and-run method of writing software. Some sort of local database of diffs or some such.
- makapuf 3y agoDepends on your target; if you have tiny compilation units you won't be able to optimize /inline on a broad target, that's why single unit compilation is an option (that may or may not improve the resut)
- davidhyde 3y agoThis is true but what is really happening is that the frontend and backend cannot communicate intent effectively because of they way they are separated. The frontend doesn’t know what is important for optimisation because that’s not its job and the backend only sees the code the front gives it (never a wholistic view). So the easiest (and slowest) approach is to do everything over and over again. Increasing Codegen units (multi unit compilation) is just the user taking a risk that splitting things up will not affect performance optimisations. Nothing smart about it. If you had tiny compilation units and the frontend understood their significance to the backend then it would be able to build a graph of dirty code to be recompiled when a small piece of it changes.
- yxhuvud 3y agoOne problem they really need to address though is that as soon as you put everything in a single compilation unit, then compilation is single threaded and dog slow. Compilation units maybe make sense for C and C++, but for other languages they are just a way to structure the compilation. It should be automatic, and just better all around.
- 3y ago
- KingOfCoders 3y agoOne reason for me moving from Rust to Go was compilation speed. Go is a simpler language, so apples to oranges, but Go compiles so fast, which to me makes development very different.
- makapuf 3y agoThat is definitely true, but from the article it's the backend that takes time, not the frontend where the language itself resides. If you compile go from llvm, it maybe as long as rust.
- KingOfCoders 3y agoI wonder why we do not split up compilation more - especially for web developer. Rust does this a little with "check", C with "-O". I want fast compilation for my dev cycle or for unit tests, I want slow compilation with optimizations, escape analysis, correctness etc. for production (the distinction between a compiler and linter is also not clear, some compiles do what linters do in other languages).
- jokethrowaway 3y agoWe do, you have profile configuration for dev or for release You can get pretty big differences in terms of compile speed / binary size
- IshKebab 3y agoGiving up entirely on the compile time of "performance" builds can be bad too though, e.g. for people writing games, audio software, etc.
- bluGill 3y agoOnly if you need to test the full game. If you can unit test algorithms and learn something then fast builds matter.
- GrumpySloth 3y ago
- jokethrowaway 3y agoOver the years compile speed improved quite a bit (recently this: https://blog.rust-lang.org/2023/11/09/parallel-rustc.html https://blog.rust-lang.org/2023/11/09/parallel-rustc.html made quite the difference) If we can squeeze more performance that's great but the largest concern I have around compilation is with the size of the target directory It can balloon up to node_modules levels
- kobzol 3y agoThere have been some recent improvements to this, but yeah, it can be still quite large. There is a WIP development of a garbage collector in Cargo that could help with this.
- chrismorgan 3y agoI don’t find node_modules exceeding even a few hundred megabytes very often. But Rust target directories can easily reach multiple gigabytes.
- pornel 3y agoApart from incremental compilation cache, a large chunk of it is debug information. Lowering debug info precision helps a lot (although it’s still suspiciously large.)
- choeger 3y agoMonomorphization. For every generic function f, rustc will generate as many instances as there are type instances (shape instances? Does the Compiler distinguish between different kinds of references that all get compiled to pointers?). This feature has a cost. Compare to OCaml's uniform object representation that enables comparatively blazing compilation performance but pays a prize in performance and weird FFI restrictions (integers with a tag bit). Btw. It's misleading to say "it's the backend" when the frontend is responsible for creating so much work for it.
- Alifatisk 3y agoMay I take the opportunity to ask, what’s the reason for Metas somewhat heavy use of Ocaml? What’s the appeal? You already pointed out the insane compilation perf.
- dermesser 3y agoIt's a pleasant and practical language to write, yet fairly safe. Imagine the safety of Rust but looking more like Python (or Haskell...), the concurrency of Go (since V5), and without a borrow checker (but a GC instead).
- davidmurdoch 3y agoI watch some intro to OCAML videos, got excited about the languages features, then tried reading some real OCAML (Tezos, which was touted as the star of idiomatic OCAML projects - can't find the site that listed it now), and I found it so incredibly dense, hard to read, and almost completely devoid of meaningful naming and comments. It felt similar to reverse-engineering minified code to me.
- whateveracct 3y agosounds like unfamiliarity. OCaml isn't a language a layman can read without prerequisites.
- binary132 3y agoI'll never forget my first experience with Rust: trying to build the compiler from source and OOMing my cloud VM. :)
- xmcqdpt2 3y agoFor libraries, the article shows most of the time being spent in "front end" phases. Isn't that a bit misleading, as the library will eventually have to be included in the final program's binary? The code generation phase isn't exactly attributable to any one module.
- ad-ops 3y agoWith all the recent improvements to compilation speed (nightly, cranelift, mold-linker), Rust has become much more pleasant. Trivial and incremental changes to a medium sized crate like rust-analyzer (~200k loc) takes around 2.5s and a small Axum project takes around 0.5s. These are my very subjective hobby benchmarks running archlinux on an AMD 9 7940HS. Of course the initial build or the release build take much longer, but it makes me hopeful for the future.
- andenacitelli 3y agoWoah, 200k LoC is considered medium? I work at a Series A startup and our entire product (which is actually much more than a CRUD app) is only in the high tens of thousands, so that’s just a funny thought for me. My theory is that because Rust is a low level language you tend to miss out on higher level primitives that promote more code reuse. Another theory is that Rust is mature but not quite as mature as something like Java, so there are fewer mature dependencies for you to delegate your work to. Thoughts on what’s accurate? For context, I’ve written a bit of Rust myself, but am definitely a beginner.
- pornel 3y agoRust is very good at code reuse. Generics and cross-crate inlining enable zero-(runtime)cost abstractions, meaning there’s usually no perf downside to using 3rd party code instead of your own. Strict type system, standardized error checking, thread safety in interfaces, and built in tooling for API documentation makes using libraries relatively easy. The ecosystem is pretty large now, and has a culture of respecting semver, and focus on safety and reliability. Cargo makes adding dependencies easy (the most common complaint is that it’s too easy, and people use too many dependencies).
- paulddraper 3y agoYou know Series A is early stage, right?
- ivanjermakov 3y agoI would love to see more categorized frontend breakdown. Just type check, borrow check and metadata don't show the full picture.
- nbittich 3y agoBuild time should be instantaneous, just like in go or C. Instead, simple hello world in bevy / egui, can takes forever to build. Even after the first build, build time is noticable for every change . You already have to struggle with the borrow checker, adding the build time to that makes rust the worst dev experience for anything that requires adding dependencies to your project. I've been using rust for 3 years as my main programming language for hobby projects, but now I've decided to switch to C and Go until there is relevant improvements in Rust.