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

51–60 of 264 posts

Re: Rust compiler performance

#51

Post by bobbylarrybobby »

jadbox wrote: post #40

Not related to the article, but after years of using Rust, it still is a pain in the ass. While it may be a good choice for OS development, high frequency trading, medical devices, vehicle firmware, finance software, or working on device drivers, it feels way overkill for most other general domains. On the other hand, I learned Zig and Go both over a weekend and find they run almost as fast and don't suffer from memo…

Not to be that guy who comes to Rust’s defense whenever Go is mentioned, but... Rust protects from a much larger class of errors than just memory safety. For instance, it is impossible to invalidate an iterator while iterating over it, refer to an unset or invalid value, inadvertently merely shallow copy a variable, or forget to lock/unlock a mutex.

Re: Rust compiler performance

#52

Post by littlestymaar »

In my experience working on medium-sized Rust projects (hundreds of thousands of LoCs, not millions), incremental compilation and mold pretty much solved the problem in practice. I still occasionally code on my 13 years old laptop when traveling and compilation time is fine even there (for cargo check and debug build, that is, I barely ever compile in release mode locally).

What's painful is compiling from scratch, and particularly the fact that every other week I need to run cargo clean and do a full rebuild to get things working. IMHO this is a much bigger annoyance than raw compiler speed.

Re: Rust compiler performance

#53

Post by codr7 »

bobbylarrybobby wrote: post #51
jadbox wrote: post #40

Not related to the article, but after years of using Rust, it still is a pain in the ass. While it may be a good choice for OS development, high frequency trading, medical devices, vehicle firmware, finance software, or working on device drivers, it feels way overkill for most other general domains. On the other hand, I learned Zig and Go both over a weekend and find they run almost as fast and don't suffer from memo…

Not to be that guy who comes to Rust’s defense whenever Go is mentioned, but... Rust protects from a much larger class of errors than just memory safety. For instance, it is impossible to invalidate an iterator while iterating over it, refer to an unset or invalid value, inadvertently merely shallow copy a variable, or forget to lock/unlock a mutex.

If only these were common problems that were difficult to otherwise avoid.

Re: Rust compiler performance

#54

Post by kristoff_it »

> Speaking of DoD, an additional thing to consider is the maintainability of the compiler codebase. Imagine that we swung our magic wand again, and rewrote everything over the night using DoD, SIMD vectorization, hand-rolled assembly, etc. It would (possibly) be way faster, yay! However, we do not only care about immediate performance, but also about our ability to make long-term improvements to it.

This is an unfortunate hyperbole from the author. There's a lot of distance between DoD and "hand-rolled assembly" and thinking that it's fair to put them in the same bucket to justify the argument of maintainability is just going to hurt the Rust project's ability to make a better compiler for its users.

You know what helps a lot making software maintainable? A Faster development loop. Zig has invested years into this and both users and the core team itself have started enjoying the fruits of that labor.

https://ziglang.org/devlog/2025/#2025-06-08

Of course everybody is free to choose their own priorities, but I find the reasoning flawed and I think that it would ultimately be in the Rust project's best interest to prioritize compiler performance more.

Re: Rust compiler performance

#55

Post by MeetingsBrowser »

kibwen wrote: post #48
MeetingsBrowser wrote: post #37

Earlier quoted context omitted.

The original comment is mostly inline with the article. All the easy local optimizations have been done. Even mostly straightforward compiler wide changes take a team of people multiple years to land. Re-architecting the rust compiler to be faster is probably not going to happen.

> Re-architecting the rust compiler to be faster is probably not going to happen. This is a statement without the weight of evidence. The Rust compiler has been continually rearchitected since 1.0, and has doubled its effective performance multiple times since then.

I'm going off of what is in the article.

> The second way forward is performing massive changes and/or refactorings to the implementation of the compiler. However, that is of course challenging, for a number of reasons.

> if you change one thing at the “bottom” layer of the compiler, you will then have to go through hundreds of places and fix them up, and also potentially fix many test cases, which can be very time-consuming

> You can try to perform the modifications outside the main compiler tree, but that is almost doomed to fail. Or, you will need to do the migration incrementally, which might require maintaining two separate implementations of the same thing for a long time, which can be exhausting.

> this is a process that takes several years to finish. That’s the scale that we’re dealing with if we would like to perform some massive refactoring of the compiler internals

There are other easier paths to improving the build times for common developer workflows.

Re: Rust compiler performance

#56

Post by Animats »

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.

Re: Rust compiler performance

#57

Post by panstromek »

kibwen wrote: post #45
norir wrote: post #27

Compiler performance must be considered up front in language design. It is nearly impossible to fix once the language reaches a certain size without it being a priority. I recently saw here the observation that one can often get a 2x performance improvement through optimization, but 10x requires redesigning the architecture. Rust can likely never be rearchitected without causing a disastrous schism in the community,…

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.

There are many more mundane examples of language design choices in rust that are problematic for compile time. Polymorphization (which has big potential to speed up compile time) has been blocked on pretty obscure problems with TypeId. Procedural macros require double parsing. Ability to define items in function bodies prevents skipping parsing bodies. Those things are not essential, they could pretty easily be tweaked to be less problematic for compile time without compromising anything.

Re: Rust compiler performance

#58

Post by littlestymaar »

formerly_proven wrote: post #49
littlestymaar wrote: post #42

Earlier quoted context omitted.

You're conflating language design and compiler architecture . It's hard to increment on a compiler to get massive performance improvement, and rearchitecture can help, but you don't necessarily need to change anything to the language itself in that regard. Roslyn (C#) is the best example of that. It's a massive endeavor and would need significant fundings to happen though.

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 cases (with the exception of niches crates who abuse the Turing completeness of the Trait system). You're not going to make big gains by changing these.

The massive gains are to be made later in the pipeline (or earlier, by having a way to avoid re-compiling pro macros and their dependencies before the actual compilation can even start).

Re: Rust compiler performance

#59

Post by zozbot234 »

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.

The JVM is not a very meaningful target for Rust since it does not use C-like flat memory addressing and pointer arithmetic. It's as if every single Java object and field is sitting in its own tiny memory segment/address space. On the one hand, this makes it essentially transparent to GC, which is a key property for Java; OTOH, it means that compiling C-like languages to the JVM is usually done by reimplementing "memory" as a JVM array of byte values.

Re: Rust compiler performance

#60

Post by maccard »

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 lines of rust took close to 10 minutes. Incremental changes to the project were still closer to a minute at the time. I’ve never worked on a 5m+ LOC project in rust, but I can only imagine how long it would take.

On the flip side, I also submitted some patches to a golang program of a similar size [1] and it was faster to clone, install dependencies and clean build that project than a single file change to the rust project was.

[0] https://github.com/getsentry/symbolicator

[1] https://github.com/buildkite/agent

Post reply on HN