What part of Rust compilation is the bottleneck? • Hacker News Board

Re: What part of Rust compilation is the bottleneck?

#31

Post by kjksf » Sat, Mar 16, 2024, 12:18 PM UTC

GrumpySloth wrote: post #15

makapuf wrote: post #9

Earlier quoted context omitted.

That 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.

It’s not just Rust. Practically every compiler based on LLVM is slow. Swift, Zig, Clang. The Go compiler being written from scratch based on the Plan9 C compiler is a huge advantage.

Minor correction: Go compiler used to be a modification of Plan9 C compiler, then a Go port of that modification but then it was completely rewritten as a SSA-based compiler so today it has almost nothing to do with the original Plan9 code.

Re: What part of Rust compilation is the bottleneck?

#32

Post by pjmlp » Sat, Mar 16, 2024, 12:24 PM UTC

kjksf wrote: post #30

pjmlp wrote: post #27

Earlier quoted context omitted.

OCaml compiles just as fast without having to compromise on the type system.

But then you have to compromise on speed of generated code, poor support of windows, number of libraries and overall ecosystem, no ability to generate standalone executables and probably more but I tried OCaml only briefly so can't speak to all of its shortcomings.

OCaml optimizations are certainly better than Go compiler that hardly does inlining and only recently got some PGO support, and those that care about using LLVM or GCC backends have to compromise on fronteds that still don't do generics.

Go support on Windows is also not great, plugin package doesn't work, filesystem support assumes POSIX semantics, cgo requires installing mingw.

Re: What part of Rust compilation is the bottleneck?

#33

Post by binary132 » Sat, Mar 16, 2024, 12:27 PM UTC

I'll never forget my first experience with Rust: trying to build the compiler from source and OOMing my cloud VM. :)

Re: What part of Rust compilation is the bottleneck?

#34

Post by KingOfCoders » Sat, Mar 16, 2024, 12:33 PM UTC

pjmlp wrote: post #27

KingOfCoders wrote: post #7

One 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.

OCaml compiles just as fast without having to compromise on the type system.

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.

Re: What part of Rust compilation is the bottleneck?

#35

Post by xmcqdpt2 » Sat, Mar 16, 2024, 12:38 PM UTC

For 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.

Re: What part of Rust compilation is the bottleneck?

#36

Post by ad-ops » Sat, Mar 16, 2024, 12:48 PM UTC

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 longer, but it makes me hopeful for the future.

Re: What part of Rust compilation is the bottleneck?

#37

Post by margorczynski » Sat, Mar 16, 2024, 1:01 PM UTC

KingOfCoders wrote: post #34

pjmlp wrote: post #27

Earlier quoted context omitted.

OCaml compiles just as fast without having to compromise on the type system.

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.

From my experience this simplicity is something you pay the price along the way - development is harder (a good typing gives you a lot of hints about functionality and puts bounds on developers on how to use it) and more error prone (less stuff gets caught by the type checker, instead you find it out in runtime).

Of course it is good to be reasonable - some people completely fly off into the FP world and instead of actually building working stuff they think all day about some clever abstraction and types to model it.

Re: What part of Rust compilation is the bottleneck?

#38

Post by naasking » Sat, Mar 16, 2024, 1:08 PM UTC

KingOfCoders wrote: post #34

pjmlp wrote: post #27

Earlier quoted context omitted.

OCaml compiles just as fast without having to compromise on the type system.

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'd call that disillusionment with bad type systems, which are indeed unnecessarily complex. We have yet to achieve a typing "nirvana", but we're getting closer IMO.

Re: What part of Rust compilation is the bottleneck?

#39

Post by dermesser » Sat, Mar 16, 2024, 1:10 PM UTC

Alifatisk wrote: post #25

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…

May 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.

It'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).

Re: What part of Rust compilation is the bottleneck?

#40

Post by davidmurdoch » Sat, Mar 16, 2024, 1:19 PM UTC

dermesser wrote: post #39

Alifatisk wrote: post #25

Earlier quoted context omitted.

May 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.

It'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).

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