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

161–170 of 264 posts

Re: Rust compiler performance

#161

Post by pjmlp »

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

Not only language.

Many of complaints towards Rust, or C++, are in reality tooling complaints.

As shown on other ecosystems, the availability of interpreters or image based tooling are great ways to overcome slow optimizating compilers.

C++ already had a go at this back in the early 90's with Energize C++ and Visual Age for C++ v4, both based on Common Lisp and Smalltalk from their respective owners.

They failed on the market due to the hardware requirements for 90's budgets.

Now slowly coming back with tooling like Visual C++ hot reload improvements, debugging optimised builds, Live++, Jupiter notebooks.

Rational Software started their business selling Ada Machines, the same development experience as Lisp Machines, but with Ada, lovely inspired on Xerox PARC experience with Mesa and Mesa/Cedar.

Haskell and OCaml, besides the slow compilers, have bytecode interpreters and REPLs.

D has the super fast dms, with ldc and gdc, for the optimised builds suffering from longer compile times.

So while Rust cannot be archited in a different way, there is certainly plenty of room for interpreters, REPLs, not compiling always from source and many other tooling improvements, within the same language.

Re: Rust compiler performance

#162

Post by jamesmunns »

jtrueb wrote: post #38

A true champion > when I started contributing to Rust back in 2021, my primary interest was compiler performance. So I started doing some optimization work. Then I noticed that the compiler benchmark suite could use some maintenance, so I started working on that. Then I noticed that we don’t compile the compiler itself with as many optimizations as we could, so I started working on adding support for LTO/PGO/BOLT, wh…

Kobzol is an absolutely wonderful person to work with. I also work in the Rust project, and any time I've interacted with him, he's been great.

Re: Rust compiler performance

#163

Post by dominicrose »

johnfn wrote: post #86
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.

Different programming languages have different qualities. For some tasks I like Ruby because it doesn't get in my way. But Ruby is built in C and so are JS VMs and web browsers etc (C/C++/Rust). A good LLM can convert Ruby code to Rust for a 10-100x performance boost, only multiplying the number of lines of code by 2. That makes Ruby a good programming language and Rust a good target language.

Re: Rust compiler performance

#164

Post by pm215 »

maccard wrote: post #105
sapiogram wrote: post #82

Earlier quoted context omitted.

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.

Sorry - my clean build was actually including the dependency fetching, which is a large part of it. My experience was in 2023 which if we go by article roughly scales with compiler performance to 5 minutes or so

I do wonder how much the fetch-source-and-build-all-dependencies approach contributes to the poor perception of compile times -- your very first experience of "how long did cargo take to build this project" will be terrible because it will include downloading and building a ton of dependencies...

Re: Rust compiler performance

#165

Post by krzat »

fngjdflmdflg wrote: post #107
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,…

This was a big reason for dart canceling its previous macros attempt (as I understand it). Fast compilation is integral for Flutter development - which accounts for a late percentage of dart usage - so after IIRC more than two years of developing it they still ended up not going through with that iteration of macros because it would make hot reload too slow. That degree of level-headedness and consideration is worthy…

Dart is a meh language but their focus on hot reload single handedly made it worth it's existence.

Re: Rust compiler performance

#166

Post by baalimago »

Seems to me that Rust has hit bedrock.

If there's no tangible solution to this design flaw today, what will happen to it in 20 years? My expectation is that the amount of dependencies will increase, as will the complexity of the Rust ecosystem at large, which will make the compilation times even worse.

Re: Rust compiler performance

#167

Post by zozbot234 »

baalimago wrote: post #166

Seems to me that Rust has hit bedrock. If there's no tangible solution to this design flaw today, what will happen to it in 20 years? My expectation is that the amount of dependencies will increase, as will the complexity of the Rust ecosystem at large, which will make the compilation times even worse.

It's OK; 20 years ought to be enough time to rewrite LLVM in Rust.

Re: Rust compiler performance

#168

Post by zozbot234 »

littlestymaar wrote: post #158
hobofan wrote: post #155

Earlier quoted context omitted.

It might as well. If there is no definition of an ABI, nobody is going to build the tooling and infrastructure to detect ABI compatibility between releases and leverage that for the off-chance that e.g. 2 out of 10 successive Rust releases are ABI compatible.

Why wouldn't they do exactly that if they decided to publish binary crates… Nobody does that right now because there's no need for that, but it doesn't mean that it's impossible in any way. Stable ABI is a massive commitment that has long lasting implications, but you don't need that to be able to have binary dependencies.

You can have binary dependencies with a stable ABI; they're called C-compatible shared libs, provided by your system package manager. And Cargo can host *-sys packages that define Rust bindings to these shared libs. Yes, you give up on memory safety across modules, but that's what things like the WASM Components proposals are for. It's a whole other issue that has very little to do with ensuring safety within a single build.

Re: Rust compiler performance

#169

Post by baalimago »

Why haven't Rust been forked by some bigger company, who have the time and resources to specialize it into something which fits better into a professional market? Yes I'm saying low compilation time -> high development RTT is a requirement for the professional market.

Re: Rust compiler performance

#170

Post by culebron21 »

c-cube wrote: post #93
jtrueb wrote: post #38

A true champion > when I started contributing to Rust back in 2021, my primary interest was compiler performance. So I started doing some optimization work. Then I noticed that the compiler benchmark suite could use some maintenance, so I started working on that. Then I noticed that we don’t compile the compiler itself with as many optimizations as we could, so I started working on adding support for LTO/PGO/BOLT, wh…

I'm worried this person is going to experience a Yak overflow, honestly.

What a wonderful term. I love it!
Post reply on HN