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

41–50 of 62 posts

Re: What part of Rust compilation is the bottleneck?

#41

Post by whateveracct »

davidmurdoch wrote: post #40
dermesser wrote: post #39

Earlier quoted context omitted.

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.

sounds like unfamiliarity. OCaml isn't a language a layman can read without prerequisites.

Re: What part of Rust compilation is the bottleneck?

#42

Post by davidmurdoch »

whateveracct wrote: post #41
davidmurdoch wrote: post #40

Earlier quoted context omitted.

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.

sounds like unfamiliarity. OCaml isn't a language a layman can read without prerequisites.

I found the idea pleasant, but not in actuality. So maybe it's an acquired taste? Haha

Re: What part of Rust compilation is the bottleneck?

#43

Post by whateveracct »

davidmurdoch wrote: post #42
whateveracct wrote: post #41

Earlier quoted context omitted.

sounds like unfamiliarity. OCaml isn't a language a layman can read without prerequisites.

I found the idea pleasant, but not in actuality. So maybe it's an acquired taste? Haha

oh it definitely is. A lot of Haskell can look like you describe, but it's perfectly legible if you have enough reps under your belt. I find normal languages hard to read nowadays.

Re: What part of Rust compilation is the bottleneck?

#44

Post by flohofwoe »

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…

> ...when the frontend is responsible for creating so much work for it.

That's the most important point I think. Clang compiling typical C code is very fast, but the same Clang compiling typical C++ code is very slow. Both use the same LLVM backend.

Re: What part of Rust compilation is the bottleneck?

#45

Post by sigsev_251 »

pjmlp wrote: post #32
kjksf wrote: post #30

Earlier quoted context omitted.

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.

> using LLVM backends

Wait, there is an LLVM based Go toolchain? I thought the Go crowd was known for their NIH obsession.

Re: What part of Rust compilation is the bottleneck?

#46

Post by sigsev_251 »

pjmlp wrote: post #26
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…

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.

Re: What part of Rust compilation is the bottleneck?

#47

Post by pjmlp »

sigsev_251 wrote: post #45
pjmlp wrote: post #32

Earlier quoted context omitted.

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.

> using LLVM backends Wait, there is an LLVM based Go toolchain? I thought the Go crowd was known for their NIH obsession.

TinyGo.

Re: What part of Rust compilation is the bottleneck?

#48

Post by IshKebab »

KingOfCoders wrote: post #11
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.

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.

Re: What part of Rust compilation is the bottleneck?

#49

Post by andenacitelli »

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

Re: What part of Rust compilation is the bottleneck?

#50

Post by pjmlp »

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

Post reply on HN