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

141–150 of 264 posts

Re: Rust compiler performance

#141

Post by littlestymaar »

nicoburns wrote: post #92
pornel wrote: post #89

Earlier quoted context omitted.

It's a "unit" in the sense of calling `rustc` once, but it's not a minimal unit of work. It's not directly comparable to what C does. Rust has incremental compilation within a crate. It also splits optimization work into many parallel codegen units. The compiler front-end is also becoming parallel within crates. The advantage is that there can be common shared state (equivalent of parsing C headers) in RAM, used for…

> Rust has incremental compilation within a crate. It also splits optimization work into many parallel codegen units. Eh, it does, but it's not currently very good at this in my experience. Nothing unfixable AFAIK (and the parallel frontend can help (but is currently a significant regression on small crates)), but currently splitting things into smaller crates can often lead to much faster compiles.

Yes the actual implementation is far from what could be, but the argument was that it's not a language design issue, but an implementation one.

Re: Rust compiler performance

#142

Post by littlestymaar »

CrendKing wrote: post #104
kibwen wrote: post #97

Earlier quoted context omitted.

> This is an effect of the language not having a proper ABI for compiling libraries as dynamically loadable modules No, this is a design decision of Cargo to default to using project-local cached artifacts rather than caching them at the user or system level. You can configure Cargo to do so if you'd like. The reason it doesn't do this by default is because Cargo gives crates great latitude to configure themselves vi…

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.

That would work for debug builds (and that's something that I would appreciate) but not for release, as most of the time you want to compile for the exact CPU you're targeting not just for say “x86 Linux” to make sure your code is optimized properly using SIMD instructions.

Re: Rust compiler performance

#143

Post by dgb23 »

90s_dev wrote: post #62
kristoff_it wrote: post #54

> Speaking of DoD, an additional thing to consider is the maintainability of the compiler codebase. Imagine that we swung our magic wand again, and rewrote everything over the night using DoD, SIMD vectorization, hand-rolled assembly, etc. It would (possibly) be way faster, yay! However, we do not only care about immediate performance, but also about our ability to make long-term improvements to it. This is an unfort…

Yeah but it's Zig. Rust is for when you want to write C but have it be easier . Zig is when you want it to be harder than C, but with more control over execution and allocation as a trade off.

I had almost the exact opposite experience.

Re: Rust compiler performance

#144

Post by littlestymaar »

woodruffw wrote: post #113
cesarb wrote: post #108

Earlier quoted context omitted.

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

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.

Re: Rust compiler performance

#145

Post by panstromek »

kibwen wrote: post #70
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…

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.

Re: Rust compiler performance

#146

Post by kobzol »

AndyKelley wrote: post #72
Rusky wrote: post #67

Earlier quoted context omitted.

The tokenizer is not really a good demonstration of the differences between these styles. A more representative comparison would be the later stages that build, traverse, and manipulate tree and graph data structures.

OK, parser then: https://github.com/rust-lang/rust/tree/1.87.0/compiler/rustc... (main logic seems to be in expr.rs) vs https://github.com/ziglang/zig/blob/0.14.1/lib/std/zig/Parse... Again, for those who wish to form their own opinions.

I think a reasonable comparison would have to be DoD Rust parser vs current Rust parser. Comparing across languages isn't very useful, because Zig has very different syntax rules, and doesn't provide diagnostics near the same level as Rust does. The Rust compiler (and also its parser) spends an incredible amount of effort on diagnostics, to the point of actually trying to parse syntax from other languages (e.g. Python), just to warn people not to use Python syntax in Rust. Not to mention that it needs to deal with decl and proc macros, intertwine that with name resolution, etc. etc. This all of course hurts parsing performance quite a lot, and IMO would make it both much harder to write the whole thing in DoD, and also the DoD performance benefits would be not so big, because of all the heterogeneous functionality the Rust frontend does. Those are of course deliberate decisions of Rust that favor other things than compilation performance.

Re: Rust compiler performance

#147

Post by Ygg2 »

estebank wrote: post #20
MeetingsBrowser wrote: post #13

Earlier quoted context omitted.

Why not both? If I had to choose though, I would choose compilation speed. Buying an SSD to double my storage is much more cost effective than buying a bulkier processor to halve my compilation times.

> Why not both? For better and worse, the Rust project is a "show-up-ocracy": the work that gets done is the one that volunteers (or paid employees from a company donating their time to the project) spend time doing. It's hard in open source projects to tell people "this is important and you must work on it", but rather you have to convince people that it is important and have to hope they will have the time, inclina…

> For better and worse, the Rust project is a "show-up-ocracy"

So it's an OSS project?

Re: Rust compiler performance

#148

Post by moooo99 »

dgb23 wrote: post #143
90s_dev wrote: post #62

Earlier quoted context omitted.

Yeah but it's Zig. Rust is for when you want to write C but have it be easier . Zig is when you want it to be harder than C, but with more control over execution and allocation as a trade off.

I had almost the exact opposite experience.

I share this impression. I’ve never worked much with low level languages with the exception of a few university assignments. I did last years advent of code in Zig and was quite productive and never really struggled with the language that much. Meanwhile, rust makes things a lot more complicated on my current project.

The main benefit of rust over zig seems to be the maturity. Rust has had a decade+ to stabilize and build an ecosystem while Zig is still a very new language

Re: Rust compiler performance

#149

Post by kobzol »

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.

Re: Rust compiler performance

#150

Post by [deleted] »

zozbot234 wrote: post #102
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…

AIUI, "Swift-style" ABI mechanisms are heavily dependent on alloca (dynamically-sized allocations on the stack) which the Rust devs have just proposed backing out of a RFC for (i.e. give up on it as an approved feature for upcoming versions of Rust) because it's too complex to implement, even with existing LLVM support for it.

[deleted]
Post reply on HN