Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What part of Rust compilation is the bottleneck?

kobzol.github.io

Post reply on HN
Print view View original

51–60 of 62 posts

Re: What part of Rust compilation is the bottleneck?

#51

Post by pjmlp »

sigsev_251 wrote: post #46
pjmlp wrote: post #26

Earlier quoted context omitted.

Kind of, despite its slow builds fame, it is possible to have relative fast builds in C++ with monomorphization. By using binary libraries, external templates for common type sets, incremental compilation and linking, and nowadays (at least for VC++ already) modules. What Rust still lacks is having sound alternatives to LLVM, or someone supporting similar workflows in Rust. Using OCaml as an example, it is great to h…

Maybe cranelift will help with this. Faster compile times is one of its selling points.

That is something that I also look forward to.

Re: What part of Rust compilation is the bottleneck?

#52

Post by bluGill »

IshKebab wrote: post #48
KingOfCoders wrote: post #11

Earlier quoted context omitted.

I 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).

Giving up entirely on the compile time of "performance" builds can be bad too though, e.g. for people writing games, audio software, etc.

Only if you need to test the full game. If you can unit test algorithms and learn something then fast builds matter.

Re: What part of Rust compilation is the bottleneck?

#53

Post by zozbot234 »

choeger wrote: post #24

Monomorphization. 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 rest…

Monomorphization can be manually addressed in Rust by writing generic function impls as delegating to a single function where the generic pameters are partily or fully omitted - a kind of "polymorphization". This is a pretty common pattern, e.g. in the Rust std library. In more recent versions of Rust this can be expanded via the use of const generics, e.g. to express the size and alignment of a generic type parameter, where the implementation only depends on these. So this kind of "polymorphization" can be applied more broadly.

Re: What part of Rust compilation is the bottleneck?

#54

Post by sigsev_251 »

pjmlp wrote: post #50
KingOfCoders wrote: post #34

Earlier quoted context omitted.

Some see it as a compromising on types, I don't. After some years writing Scala code, trying to come up with even better types each day, Go to me is not a compromise but a relief. My love for types peaked when I was in my mid-40s, now that I'm 50+ I want simple things.

I am almost 50, and my point of view on Go from 2012 has hardly changed. http://lambda-the-ultimate.org/node/4554#comment-71504 At least it does generics now.

> At least it does generics now

Not in gccgo

Re: What part of Rust compilation is the bottleneck?

#55

Post by pornel »

andenacitelli wrote: post #49
ad-ops wrote: post #36

With 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 lon…

Woah, 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…

Rust 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).

Re: What part of Rust compilation is the bottleneck?

#56

Post by pornel »

chrismorgan wrote: post #22
jokethrowaway wrote: post #13

Over the years compile speed improved quite a bit (recently this: 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

I don’t find node_modules exceeding even a few hundred megabytes very often. But Rust target directories can easily reach multiple gigabytes.

Apart 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.)

Re: What part of Rust compilation is the bottleneck?

#57

Post by hobs »

kobzol wrote: post #20
hobs wrote: post #14

Earlier quoted context omitted.

Makes sense. In my opinion I would just generate fake flamegraphs then - they are much more readable and the format is dummy easy to fake.

Yeah, 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.

/shrug that's fair, with only like four things its not that much more readable.

Re: What part of Rust compilation is the bottleneck?

#58

Post by hun3 »

davidhyde wrote: post #6

If 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 appro…

As a workaround, split into multiple crates.

Disclaimer: I concur that this is merely a workaround, not the real fix

Re: What part of Rust compilation is the bottleneck?

#60

Post by pjmlp »

sigsev_251 wrote: post #54
pjmlp wrote: post #50

Earlier quoted context omitted.

I am almost 50, and my point of view on Go from 2012 has hardly changed. http://lambda-the-ultimate.org/node/4554#comment-71504 At least it does generics now.

> At least it does generics now Not in gccgo

Indeed, as you see on other remarks from me I am aware of it, my point was about the language as designed, not the implementations ecosystem.

TinyGo also doesn't do them.

Post reply on HN