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

251–260 of 264 posts

Re: Rust compiler performance

#251

Post by yencabulator »

dvt wrote: post #109
codr7 wrote: post #53

Earlier quoted context omitted.

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

I like Rust, but I think this post is unfairly downvoted. Rustaceans often annoyingly point out that "you can't use super-common-footgun X with Rust!" which, while true, they also omit the compromises made are immense (frankly, compiler performance is one of them).

Nah, bringing out this argument in any thread that dares to mention whatever the commenter dislikes is just plain old off-topic. Go threads get people complaining. Rust threads get people complaining. The complaining is not a great addition to the discussion.

Re: Rust compiler performance

#252

Post by yencabulator »

kunley wrote: post #112

The article is fine and has a lot of good points, but tries to avoid the main issue like a plague. So I will speak it here: The slowness comes mainly from LLVM.

The article briefly mentions Cranelift, though only as a link destination not by name. And that's a way to faster Rust builds, for sure! Currently only recommended for dev builds, not production.

Re: Rust compiler performance

#253

Post by pjmlp »

kibwen wrote: post #203
Someone wrote: post #136

Earlier quoted context omitted.

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

> That basically says compiler speed isn’t a goal at all for Rust No, it says that language design inherently involves difficult trade-offs, and the Rust developers consciously decided that some trade-offs were worth the cost. And their judgement appears to have been correct, because Rust today is more successful than even the most optimistic proponent would have dared to believe in 2014; that users are asking for so…

A few points, Wirth usually always bootstraped his compilers, writing just enough Assembly for the minimal version 0 of the language and go from there.

Secondly, as we all know it isn't grammar and semantics alone that sell compilers, it is someone heavily pushing for adoption, deep pockets companies willing to do everything for adoption, or some successful product on the market that makes learning the language unavoidable when reaching for said product.

Oberon had nothing of that.

C++ had being from UNIX's birthplace, quick adoption by C compiler vendors and UNIX clones, exactly because of that. While being pushed by IBM, Microsoft and Apple on their GUI OS frameworks.

Rust as great language as it is, if it had been some university language done as someone thesis, not tied to Mozzilla, and their efforts to fix Firefox security issues with their C++ codebase, most likely would not taken off.

Re: Rust compiler performance

#254

Post by pjmlp »

krzat wrote: post #165
fngjdflmdflg wrote: post #107

Earlier quoted context omitted.

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.

It only surprises anyone that never used Smalltalk or Common Lisp environments, thought.

Pity it is still something that failed in the mainstream beyond niche stuff like VC++ hot reload, Live++, JRebel, Web frontend development.

Re: Rust compiler performance

#255

Post by pjmlp »

cesarb wrote: post #108
CrendKing wrote: post #104

Earlier quoted context omitted.

Why can't Cargo have a system like PyPI where library author uploads compiled binary (even with their specific flags) for each rust version/platform combination, and if said binary is missing for certain combination, fallback to local compile? Imagine `cargo publish` handle the compile+upload task, and crates.io be changed to also host binaries.

> Why can't Cargo have a system like PyPI where library author uploads compiled binary Unless you have perfect reproducible builds, this is a security nightmare. Source code can be reviewed (and there are even projects to share databases of already reviewed Rust crates; IIRC, both Mozilla and Google have public repositories with their lists), but it's much harder to review a binary, unless you can reproducibly recrea…

Yet other ecosystems handle it just fine, regardless of security concerns, by having signed artifacts and configurable hosting as an option.

Re: Rust compiler performance

#256

Post by pjmlp »

jplusequalt wrote: post #61
maccard wrote: post #60

Earlier quoted context omitted.

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…

Yes, but Go is a higher level language than Rust. It feels unfair to compare the two. That's why I brought up C++ (as did the article).

You can bring in Ada, Delphi, D, Haskell, OCaml, C++ with modules if you prefer.

If you want languages with similar complexity to Rust, and with fast tooling approaches available to them, instead of the one single compiler.

Re: Rust compiler performance

#257

Post by pjmlp »

kibwen wrote: post #44
logicchains wrote: post #23

Earlier quoted context omitted.

There's a lot of things you can do in C++ to reduce compilation time if you care about it, that aren't possible with Rust.

You can absolutely do the same things in Rust, it's just that the culture and tooling of Rust encourages much larger compilation units than in C or C++, so you don't get the same sort of best-case nontrivial embarrassing-parallelism, forcing the compiler to do more work to parallelize. To address the tooling pressure, I would like to see Cargo support first-class internal-only crates, thereby deconflating the crate a…

You certainly cannot distribute binary libraries, including pre-expanded templates for common use cases.

Which is always my standard approach to fast build times in C++ projects.

Re: Rust compiler performance

#258

Post by pjmlp »

dhruvrajvanshi wrote: post #34
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.

I would love this in modern languages. For dev builds, I see JIT compilation as a better deal than debug builds because it's capable of eventually reaching peak performance. For performance sensitive stuff like games, it really matters to keep a nice feedback loop without making the game unusable by turning off all optimizations. AOT static binaries are valuable for deployments. No idea how expensive it would be to d…

That approach is what you get in Common Lisp, Eiffel, Oberon language family, Java, .NET, Julia (getting there), Haskell, OCaml, C++ (with something like ROOT or C++/CLI).

So if enough people care for Rust, it is also possible.

Re: Rust compiler performance

#259

Post by pjmlp »

windward wrote: post #213
Ygg2 wrote: post #147

Earlier quoted context omitted.

> For better and worse, the Rust project is a "show-up-ocracy" So it's an OSS project?

Linux and GCC are OSS projects but CPU companies pour work into their development because it's a strict requirement of being able to sell their products.

Just like Amazon, Microsoft and Google nowadays pour work into Rust.

Re: Rust compiler performance

#260

Post by pjmlp »

zozbot234 wrote: post #167
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.

Being optimistic, given that LLVM rivals the Linux kernel on daily contributions.
Post reply on HN