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

201–210 of 264 posts

Re: Rust compiler performance

#201

Post by kibwen »

panstromek wrote: post #145
kibwen wrote: post #70

Earlier quoted context omitted.

This is an oversimplification. Automatic polymorphization is blocked on several concerns, e.g. dyn safety (and redesigning the language to make it possible to paper over the difference between dyn and non-dyn safe traits imposes costs on the static use case), and/or obscure LLVM implementation deficiencies (which was the blocker for the last time I proposed a Swift-style ABI to address this). Procedural macros don't…

Just to clarify - polymorphization is not automatic dyn dyspatch or anything related. I'm talking about compile time optimization that avoids duplicating generic functions.

Yes, I bring up dyn because the most straightforward way to implement polymorphization would be to conceptually replace usages of T: Trait with dyn Trait.

Re: Rust compiler performance

#202

Post by eddd-ddde »

WhyNotHugo wrote: post #95
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,…

One of the issue why compile times are so awful is that all dependencies must be compiled for each project. 20 different projects use the same dependency? They each need to recompile it. This is an effect of the language not having a proper ABI for compiling libraries as dynamically loadable modules, which in itself presents many other issues, including making distribution of software a complete nightmare.

Dependencies must compile with the right features enabled. You can't possibly share the 2^n versions of every binary. ABI stability doesn't fix this.

Re: Rust compiler performance

#203

Post by kibwen »

Someone wrote: post #136
kibwen wrote: post #45

Earlier quoted context omitted.

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 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 something implies that you have succeeded to the point of having users at all, which is a good problem to have and one that nearly no language ever enjoys.

In the context of Oberon, let's also keep in mind that Rust is a bootstrapped compiler, and in the early days the Rust developers were by far the most extensive users of the language; nobody on Earth was more acutely affected by compiler performance than they were. They still chose to prefer runtime performance (to be competitive with C++) over compiler performance (to be competitive with Go), and IMO they chose correctly.

And as for the case of Oberon, its obscurity further confirms that prioritizing compiler performance at all cost is not a royal road to popularity.

Re: Rust compiler performance

#204

Post by eddd-ddde »

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…

When a platform has good support and is easy to onboard this is the inevitable result. It's just like the JavaScript ecosystem.

But this is not a downside. Just like I can start a new website project and not use a single dependency, I can start a new rust project and not install a single dependency.

To me the real value is in the tools and core language feature. I could probably implement my own minimal ad-hoc async IO framework if I wanted to, and shape it to my needs. No dependencies.

Re: Rust compiler performance

#205

Post by maccard »

jplusequalt wrote: post #199
sagarm wrote: post #132

Earlier quoted context omitted.

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

Rust has long compilation times because the borrow checker was a priority. They're very different languages.

Rust has long compilation times because it doesn't prioritise compilation times.

What does [0] have to do with the borrow checker?

[0] https://www.feldera.com/blog/cutting-down-rust-compile-times...

Re: Rust compiler performance

#206

Post by woodruffw »

fc417fc802 wrote: post #175
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…

If you have reproducible builds it's no different. Without those binaries are a nightmare in that you can't easily link a given binary back to a given source snapshot. Deciding to trust my upstream is all well and good but if it's literally impossible to audit them that's not a good situation to be in.

I think it’s already probably a mistake to think that a source distribution consistently references a unique upstream source repository state; I don't believe the crate distribution layout guarantees this.

(I agree that source is easier to review and establish trust in; the observation is that once you read the upstream source you’re in the same state regarding distributors, since build and source distributions both modify the source layout.)

Re: Rust compiler performance

#207

Post by zozbot234 »

kibwen wrote: post #200
zozbot234 wrote: post #126

Earlier quoted context omitted.

Why does it have to be soundly specified though? Why not just provide an unsafe feature that works the same as existing C/LLVM, and "leave no room for a lower-level language"? The safe featureset around it can always come later if the issues around how to specify it are worked out.

The difficulty is that `unsafe` doesn't mean "yolo", it means "there are memory safety invariants here that you, the programmer, must manually uphold", so we still need to consider what those invariants would be. I'm sure that Ralf Jung would be happy to talk more about this if anyone has any ideas for how to move forward: "With #111374, unsized locals are no longer blatantly unsound. However, they still lack an actu…

> However, they still lack an actual operational semantics in MIR -- and the way they are represented in MIR doesn't lend itself to a sensible semantics

That's an issue with how the MIR for this feature has been defined, not with the feature itself. The claim that the implementation should be reworked from the ground up is one that I might agree with, but the recent proposal to back out of an existing RFC suggests that the devs see alloca itself as problematic. And that's bad news if you intend to use alloca throughout as a foundation for your Swift-like ABI support...

Re: Rust compiler performance

#208

Post by windward »

MeetingsBrowser wrote: post #55
kibwen wrote: post #48

Earlier quoted context omitted.

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

A link to this dashboard is also in the article

https://perf.rust-lang.org/dashboard.html

Re: Rust compiler performance

#209

Post by akazantsev »

bnolsen wrote: post #123
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.

The answer there was to always write small standalone executable unit test sets and simulation for day to day coding. Avoiding template heavy pigs like QT or boost helps too.

> Avoiding template heavy pigs like QT

Well, you definitely have no experience with Qt.

Re: Rust compiler performance

#210

Post by windward »

maccard wrote: post #106
afdbcreid wrote: post #75

Earlier quoted context omitted.

What are incremental compile times with the C++ codebase? Also, does the line of code you count include dependencies (admitting, dependencies in Rust are a problem, but it's not related to compiler performance)?

About 15 seconds, because we carve it up into 100 or so dlls specifically for this case

15 seconds plus the months of developer time defining dll boundaries and writing pimpls
Post reply on HN