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

131–140 of 264 posts

Re: Rust compiler performance

#131

Post by edflsafoiewq »

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

The point was language design influences compiler performance. Rust is heavily designed around "zero-cost abstraction", ie. generate tons of IR and let the backend sort it out. Spending all the time in LLVM passes is what you would expect from this.

Re: Rust compiler performance

#132

Post by sagarm »

jplusequalt wrote: post #128
maccard wrote: post #117

Earlier quoted context omitted.

I disagree that it’s unfair to compare the two. The performance difference between go and rust is far less than the difference between go and python, it has a garbage collector sure but it’s an example of a language designed for fast compilation time that achieves an order of magnitude faster compile times than rust

I think you're missing the point of my comparison. Rust has a lot more going on than Go, so it feels unfair.

Go has a lot less going on than Rust partially because compile times were a priority.

Re: Rust compiler performance

#133

Post by lsuresh »

actualwitch wrote: post #120
bbatha wrote: post #79

Earlier quoted context omitted.

> 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. Rust is in the process of building out the cranelift backend. Cranelift was originally built to be a JIT compiler. The hope is that this can become the debug build compiler. https://github…

I recently tried using cranelift on a monorepo with a bunch of crates, and it is nothing short of amazing. Nothing broke and workspace build time went from a minute and a half to a half of a second!

Was this for a release build or a debug build?

Re: Rust compiler performance

#134

Post by littlestymaar »

edflsafoiewq wrote: post #131
lsuresh wrote: post #83

Earlier quoted context omitted.

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

The point was language design influences compiler performance. Rust is heavily designed around "zero-cost abstraction", ie. generate tons of IR and let the backend sort it out. Spending all the time in LLVM passes is what you would expect from this.

Had you read the linked blog post, you'd have seen that here this isn't so much an issue with LLVM having too much work, but rustc being currently unable to split the work into parallelizable chunks before sending it to LLVM, and as such it takes a very long time not because LLVM has too much things to do, but because it does it in a single-threaded fashion, leaving tons of performance on the table.

> Rust is heavily designed around "zero-cost abstraction", ie. generate tons of IR and let the backend sort it out.

Those two aren't equivalent: Rust is indeed designed around zero-cost abstraction, and it currently generates tons of IR for the backend to optimize, but it doesn't have to, it could run some optimizations in the front-end so it generates less IR. In fact there has been ongoing work to do exactly this to improve compiler performance. But this required rearchitecturing the compiler in depth (IIRC Rust's MIR has been introduced for that very reason).

Re: Rust compiler performance

#135

Post by littlestymaar »

uecker wrote: post #88
lsuresh wrote: post #83

Earlier quoted context omitted.

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.

This isn't an issue with LLVM being slow, but of rustc not calling LLVM efficiently, read the linked blog post!

Re: Rust compiler performance

#136

Post by Someone »

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.

> would have ever been considered for omission, regardless of their compile-time cost, because that would have compromised Rust's other goals.

That basically says compiler speed isn’t a goal at all for Rust. I think that’s not completely true, but yes, speed of generated code definitely ranks very high for rust.

In contrast, Wirth definitely had the speed at which the Oberon compiler compiled code as a goal (often quoted as that he only added compiler optimizations if they made the compiler itself so much faster that it didn’t become slower because of the added complexity, but I’m not sure he was that strict)

http://www.projectoberon.net/wirth/CompilerConstruction/Comp..., section 16.1:

“It is hardly surprising that certain measures for code improvement may yield considerable gains with modest effort, whereas others may require large increases in compiler complexity and size while yielding only moderate code improvements, simply because they apply in rare cases only.

Indeed, there are tremendous differences in the ratio of effort to gain. Before the compiler designer decides to incorporate sophisticated optimization facilities, or before deciding to purchase a highly optimizing, slow and expensive compiler, it is worth while clarifying this ratio, and whether the promised improvements are truly needed.

Furthermore, we must distinguish between optimizations whose effects could also be obtained by a more appropriate formulation of the source program, and those where this is impossible.

The first kind of optimization mainly serves the untalented or sloppy programmer, but merely burdens all the other users through the increased size and decreased speed of the compiler.

As an extreme example, consider the case of a compiler which eliminates a multiplication if one factor has the value 1. The situation is completely different for the computation of the address of an array element, where the index must be multiplied by the size of the elements. Here, the case of a size equal to 1 is frequent, and the multiplication cannot be eliminated by a clever trick in the source program.”

Re: Rust compiler performance

#137

Post by kstrauser »

preciousoo wrote: post #24
jakkos wrote: post #21

Earlier quoted context omitted.

You can: https://github.com/mozilla/sccache

Oh this is amazing, looks simple to set up too. Thanks!

It's a game-changer, especially on my slower machines like Raspberry Pis. They can use every advantage they can get.

Re: Rust compiler performance

#138

Post by Ygg2 »

WhyNotHugo wrote: post #96
panstromek wrote: post #57

Earlier quoted context omitted.

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 tweak…

Macros themselves are a terrible hack to work around support for proper reflection. The entire Rust ecosystem would be reshaped in such fascinating ways if we had support for reflection. I'd love to see this happen one day.

You got it the other way around. Macros can implement (nearly) anything. Including some form of opt-in type introspection via derive macros.

They weren't a hack to get reflection. They are a way to codegen stuff easily.

Re: Rust compiler performance

#139

Post by ruuda »

The Rust ecosystem is getting slower faster than the compiler is getting faster. Libraries grow to add features, they add dependencies. Individually the growth is not so bad, and justified by features or wider platform support. But they add up, and especially dependencies adding dependencies act as a multiplier.

I started writing a post about this many years ago, but never finished it. I took a few slow-changing projects of mine that had a pinned Rust compiler, and then updated both the compiler and dependencies to the latest versions. Invariably, everything got slower to compile, even though the compiler update in isolation made things faster!

Re: Rust compiler performance

#140

Post by saghm »

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…

The lexer hack is a C thing, and Ive rarely heard anyone complain about C compiler performance. That seems more like an argument that the grammar doesn't have that much of an impact on compiler performance as other things.
Post reply on HN