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

Rust compiler performance

kobzol.github.io

Post reply on HN
Print view View original

81–90 of 264 posts

Re: Rust compiler performance

#81

Post by lsuresh »

vlovich123 wrote: post #9

I wonder if how much value there is in skipping LLVM in favor of having a JIT optimized linked in instead. For release builds it would get you a reasonable proxy if it optimized decently while still retaining better debugability. I wonder if the JVM as an initial target might be interesting given how mature and robust their JIT is.

LLVM optimizations are the overwhelming majority of the compilation bottleneck for us over at Feldera. We blogged about some of the challenges we faced here: https://www.feldera.com/blog/cutting-down-rust-compile-times...

We almost definitely need to build a JIT in the future to avoid this problem.

Re: Rust compiler performance

#82

Post by sapiogram »

maccard wrote: post #60
jplusequalt wrote: post #17

Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.

I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives. Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand li…

Thanks for actually including the slow repo in your comment. My results on a Ryzen 5900X:

* Clean debug build: 1m 22s

* Incremental debug build: 13s

* Clean release build: 1m 51s

* Incremental release build: 24s

Incremental builds were done by changing one line in creates/symbolicator/src/cli.rs.

It's not great, but it sounds like your experience was much worse for some reason.

Re: Rust compiler performance

#83

Post by lsuresh »

littlestymaar wrote: post #58
formerly_proven wrote: post #49

Earlier quoted context omitted.

No, language design decisions absolutely have a massive impact the performance envelope of compilers. Think about things like tokenization rules (Zig is designed such that every line can be tokenized independently, for example), ambiguous grammars (most vexing parse, lexer hack etc.), symbol resolution (e.g. explicit imports as in Python, Java or Rust versus "just dump eeet" imports as in C#, and also things whether…

This kind of comment is funny because it reveals how uninformed people can be while having a strong opinion on a topic. Yes grammar can impact how theoretically fast a compiler can be, and yes the type system ads more or less works depending on how it's designed, but none of these are what makes Rust compiler slow. Parsing and lexing are negligible fraction of compile time, and typing isn't particularly heavy in most…

Hard agree. Practically all the bottlenecks we run into with Rust compilation have to do with the LLVM passes. The frontend doesn't even come close. (e.g. https://www.feldera.com/blog/cutting-down-rust-compile-times...)

Re: Rust compiler performance

#84

Post by mellosouls »

panstromek wrote: post #26

The original title is: Why doesn't Rust care more about compiler performance?

(OP) I submitted this some time ago, and am pretty sure I would have submitted the title as is, so I'm guessing some manual or automatic editing since by the mods before the second chance here.

Re: Rust compiler performance

#85

Post by synthos »

Regarding AVX: could rust be compiled with different symbols that target different x64 instruction sets, then at runtime choose the symbol set that is the more performant for that architecture?

Re: Rust compiler performance

#86

Post by johnfn »

Animats wrote: post #56

This isn't a huge problem. My big Rust project compiles in about a minute in release mode. Failed compiles with errors only take a few seconds. That's where most of the debugging takes place. Once it compiles, it usually works the first time.

A minute is pretty bad. I understand it may work for your use case, but there are plenty of use cases out there where errors typically don't fail the compile and a minute iteration time is a deal killer. For instance: UI work - good luck catching an incorrect color with a compile error. Vite can compile 40,000 loc and display it on your screen in probably a couple of milliseconds.

Re: Rust compiler performance

#87

Post by johnfn »

> First, let me assure you - yes, we (as in, the Rust Project) absolutely do care about the performance of our beloved compiler, and we put in a lot of effort to improve it.

I'm probably being ungrateful here, but here goes anyway. Yes, Rust cares about performance of the compiler, but it would likely be more accurate to say that compiler performance is, like, 15th on the list of things they care about, and they'll happily trade off slower compile times for one of the other things.

I find posts about Rust like this one, where they say "ah, of course we care about perf, look, we got the compile times on a somewhat nontrivial project to go from 1m15s to 1m09s" somewhat underwhelming - I think they miss the point. For me, I basically only care if compile times are virtually instantaneous. e.g. Vite scales to a million lines and can hot-swap my code changes in instantaneously. This is where the productivity benefits come in.

Don't just trust me on it. Remember this post[1]?

> "I feels like some people realize how much more polish could their games have if their compile times were 0.5s instead of 30s. Things like GUI are inherently tweak-y, and anyone but users of godot-rust are going to be at the mercy of restarting their game multiple times in order to make things look good. "

[1]: https://loglog.games/blog/leaving-rust-gamedev/#compile-time...

Re: Rust compiler performance

#88

Post by uecker »

lsuresh wrote: post #83
littlestymaar wrote: post #58

Earlier quoted context omitted.

This kind of comment is funny because it reveals how uninformed people can be while having a strong opinion on a topic. Yes grammar can impact how theoretically fast a compiler can be, and yes the type system ads more or less works depending on how it's designed, but none of these are what makes Rust compiler slow. Parsing and lexing are negligible fraction of compile time, and typing isn't particularly heavy in most…

Hard agree. Practically all the bottlenecks we run into with Rust compilation have to do with the LLVM passes. The frontend doesn't even come close. (e.g. https://www.feldera.com/blog/cutting-down-rust-compile-times... )

While LLVM is known to be slow, not all LLVM-based languages are equally slow.

Re: Rust compiler performance

#89

Post by pornel »

swsieber wrote: post #80
kibwen wrote: post #45

Earlier quoted context omitted.

It's certainly possible to think of language features that would preclude trivially-achievable high-performance compilation. None of those language features that are present in Rust (specifically, monomorphized generics) would have ever been considered for omission, regardless of their compile-time cost, because that would have compromised Rust's other goals.

What about crates as the unit of compilation? I am genuinely curious because it's not clear to me what trade-offs there are around that decision.

It's a "unit" in the sense of calling `rustc` once, but it's not a minimal unit of work. It's not directly comparable to what C does.

Rust has incremental compilation within a crate. It also splits optimization work into many parallel codegen units. The compiler front-end is also becoming parallel within crates.

The advantage is that there can be common shared state (equivalent of parsing C headers) in RAM, used for the entire crate. Otherwise it would need to be collected, written out to disk, and reloaded/reparsed by different compiler invocations much more often.

Re: Rust compiler performance

#90

Post by kalaksi »

johnfn wrote: post #87

> First, let me assure you - yes, we (as in, the Rust Project) absolutely do care about the performance of our beloved compiler, and we put in a lot of effort to improve it. I'm probably being ungrateful here, but here goes anyway. Yes, Rust cares about performance of the compiler, but it would likely be more accurate to say that compiler performance is, like, 15th on the list of things they care about, and they'll h…

Isn't Vite for javascript though, which is, of course, a scripting language?

Btw, I've used QML and Dioxus with rust (not for games). Both make hot reloading the GUI parts possible without recompiling since that part is basically not rust (Dioxus in a bit more limited manner).

Post reply on HN