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

151–160 of 264 posts

Re: Rust compiler performance

#151

Post by kobzol »

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…

You have a fair point, I agree that while compiler performance is a priority, is is one of many priorities, and not currently super high on the list for many Rust Project developers. I wish it was different, but the only thing we can do is just do the work to make it faster :) Or support the people that work on it.

Re: Rust compiler performance

#152

Post by panstromek »

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.

This is somewhat true but also a bit misleading. Lot of the problems comes from how rust interacts with it, and how are rust projects structured. This ultimately shows up as time in LLVM, but LLVM is not entirely responsible for it.

Re: Rust compiler performance

#153

Post by kobzol »

synthos wrote: post #85

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?

I'm not sure how that works. You either let the compiler compile your whole program with AVX (which duplicates the binary) or you manually use AVX with runtime detection on selected places (which requires writing manual vectorization).

Re: Rust compiler performance

#154

Post by simonask »

ruuda wrote: post #139

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

I don't know, these things ebb and flow.

There's a bit of pushback against high-dependency project structures and compile times recently, and even niche crates like `unsynn` have garnered some attention as an alternative to the relatively heavy `syn` crate.

Re: Rust compiler performance

#155

Post by hobofan »

littlestymaar wrote: post #144
woodruffw wrote: post #113

Earlier quoted context omitted.

I don’t think it’s that much of a security nightmare: the basic trust assumption that people make about the packaging ecosystem (that they trust their upstreams) remains the same whether they pull source or binaries. I think the bigger issues are probably stability and size: no stable ABI combined with Rust’s current release cadence means that every package would essentially need to be rebuilt every six weeks. That’s…

No stable ABI doesn't mean the ABI changes at every release though.

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.

Re: Rust compiler performance

#156

Post by sureglymop »

littlestymaar wrote: post #52

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

Yes but are these the default? I want this to work pleasantly out of the box so we don't scare new users as quickly.

Re: Rust compiler performance

#157

Post by littlestymaar »

aloha2436 wrote: post #129
woodruffw wrote: post #113

Earlier quoted context omitted.

I don’t think it’s that much of a security nightmare: the basic trust assumption that people make about the packaging ecosystem (that they trust their upstreams) remains the same whether they pull source or binaries. I think the bigger issues are probably stability and size: no stable ABI combined with Rust’s current release cadence means that every package would essentially need to be rebuilt every six weeks. That’s…

> remains the same whether they pull source or binaries. I don't think that's exactly true, it's definitely _easier_ to sneak something into a binary without people noticing than it is to sneak it into rust source, but there hasn't been an underhanded rust competition for a while so I guess it's hard to be objective about that.

Pretty much nobody does those two things at the same time:

- pulling dependencies with cargo - auditing the source code of the dependencies they're building

You are either censoring and vetting everything or you're using dependencies from crates.io (ideally after you've done your due diligence on the crate), but should crates.io be compromised and inject malware in the crates' payload, I'm ready to bet nobody would notice for a long time.

I fully agree with GP that binary vs source code wouldn't change anything in practice.

Re: Rust compiler performance

#158

Post by littlestymaar »

hobofan wrote: post #155
littlestymaar wrote: post #144

Earlier quoted context omitted.

No stable ABI doesn't mean the ABI changes at every release though.

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.

Re: Rust compiler performance

#159

Post by teleforce »

cozzyd wrote: post #94
1718627440 wrote: post #69

Earlier quoted context omitted.

I think there is a massive difference in compile times between idiomatic C and C++, so its problematic to be lumping them together. But there is also some selection bias since large projects tend to migrate from C to C++.

C++ compile times are why I often stick to C, which compiles nearly instantly.

You can always upgrade to Dlang with modern features and conveniences that has comparable compilation time to C for the most parts (excluding CTFE).

Re: Rust compiler performance

#160

Post by kunley »

kobzol wrote: post #149
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.

For many use-cases yes, but there are crates bottlenecked on different things than the codegen backend. But I don't think that's the point. We could get rid of LLVM and use other backends, same as we could do other improvements. The point is that there are also other priorities and we don't have enough manpower to make progress faster.

Fair reply, thank you.
Post reply on HN