Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cranelift code generation comes to Rust

lwn.net

Post reply on HN
Print view View original

61–70 of 117 posts

Re: Cranelift code generation comes to Rust

#61

Post by devit »

zozbot234 wrote: post #47
CodesInChaos wrote: post #25

You can use different backends and optimization for different crates. It often makes sense to use optimized LLVM builds for dependencies, and debug LLVM or even Cranelift for your own code. See https://www.reddit.com/r/rust/comments/1bhpfeb/vastly_improv...

I would not expect this to work without issues, as Rust does not support a stable binary ABI across different compiler versions. How can we be sure that the two "codegen backends" will always be implementing the same binary ABI?

Presumably the LLVM and Cranelift backends in the same rustc version generate code with the same ABI, and it would be a bug if that wasn't the case.

Re: Cranelift code generation comes to Rust

#62

Post by PartiallyTyped »

zozbot234 wrote: post #47
CodesInChaos wrote: post #25

You can use different backends and optimization for different crates. It often makes sense to use optimized LLVM builds for dependencies, and debug LLVM or even Cranelift for your own code. See https://www.reddit.com/r/rust/comments/1bhpfeb/vastly_improv...

I would not expect this to work without issues, as Rust does not support a stable binary ABI across different compiler versions. How can we be sure that the two "codegen backends" will always be implementing the same binary ABI?

If you do the compilation locally, you know the structure of the ABI for the compiled code. You know that regardless of the backend you are using. At this stage, no functions with generics are compiled, only what is non-generic.

What is left is to account for the ABI in any monomorphizations that occur at the boundary, i.e. when your own structures monomorphize generic functions in the dependency.

When the compiler creates this monomorphic variant, and lowers down, it can provide the necessary details of the ABI.

Re: Cranelift code generation comes to Rust

#63

Post by aseipp »

zozbot234 wrote: post #47
CodesInChaos wrote: post #25

You can use different backends and optimization for different crates. It often makes sense to use optimized LLVM builds for dependencies, and debug LLVM or even Cranelift for your own code. See https://www.reddit.com/r/rust/comments/1bhpfeb/vastly_improv...

I would not expect this to work without issues, as Rust does not support a stable binary ABI across different compiler versions. How can we be sure that the two "codegen backends" will always be implementing the same binary ABI?

Because the ABI is defined and implemented by shared code in the runtime and compiler. There is no need for cross version compatibility between the two backends, only compatibility within the same version. This isn't particularly new either, FWIW. The Glasgow Haskell Compiler also has an unstable ABI that is not standardized, but LLVM compiled code interoperates seamlessly with code generated by the non-LLVM compiler backend (the mechanism by which that is achieved is likely different though.)

Re: Cranelift code generation comes to Rust

#64

Post by [deleted] »

zozbot234 wrote: post #47
CodesInChaos wrote: post #25

You can use different backends and optimization for different crates. It often makes sense to use optimized LLVM builds for dependencies, and debug LLVM or even Cranelift for your own code. See https://www.reddit.com/r/rust/comments/1bhpfeb/vastly_improv...

I would not expect this to work without issues, as Rust does not support a stable binary ABI across different compiler versions. How can we be sure that the two "codegen backends" will always be implementing the same binary ABI?

[deleted]

Re: Cranelift code generation comes to Rust

#65

Post by mort96 »

thesz wrote: post #22
vsnf wrote: post #21

Earlier quoted context omitted.

Is there any literature or guidelines on what to do if I'm willing to spend effectively unlimited CPU cycles in return for a more optimized final output?

Superoptimizers: https://en.wikipedia.org/wiki/Superoptimization Also, program distillation: https://www.researchgate.net/publication/220989887_Distillat...

Isn't it a bit weird that this isn't just the standard? Like imagine if Chrome was optimized with such a superoptimizer; let the optimizer spend a couple hours every month or so when cutting a new release. Surely that has to be worth it?

Re: Cranelift code generation comes to Rust

#66

Post by mort96 »

posix_monad wrote: post #30

Can anyone explain why Cranelift is expected to be faster than LLVM? And why those improvements can't also be applied to LLVM?

I've heard compiler writers complain that LLVM's API is inherently slow. Something about using runtime polymorphism everywhere. I don't know how much there is to this though, I haven't investigated it myself.

Re: Cranelift code generation comes to Rust

#67

Post by Filligree »

3836293648 wrote: post #54
Filligree wrote: post #37

Earlier quoted context omitted.

And there are faster linkers than the default. …why is it still the default?

Compatibility with niche usecases

That sounds like a good reason to keep the existing one as an opt-in possibility.

Re: Cranelift code generation comes to Rust

#68

Post by convolvatron »

Ericson2314 wrote: post #24

Really looking forward to the death of non-e-graph-based compilation :)

I've tried to look into this a couple times, including today. To me this looks alot like unification? but I don't really understand how operationally one gets from equivalence classes to instructions. is there an e-graphs for dummies writeup?

Re: Cranelift code generation comes to Rust

#69

Post by kapilsinha »

diggan wrote: post #11

Tried out the instructions from the article on a tiny Bevy project, and compared it to a "normal" build: > cargo build --release 23.93s user 22.85s system 66% cpu 1:09.88 total > cargo +nightly build -Zcodegen-backend 23.52s user 21.98s system 68% cpu 1:06.86 total Seems just marginally faster than a normal release build. Wonder if there is something particular with Bevy that makes this so? The author of the article…

Is that Bevy project open-source by any chance? I'd love to it out myself

Re: Cranelift code generation comes to Rust

#70

Post by kapilsinha »

Tehnix wrote: post #20

Very excited for Cranelift for debug builds to speed up development iteration - in particular for WASM/Frontend Rust where iteration speed is competing with the new era of Rust tooling for JS which lands in the sub 1 second builds sometimes (iteration speed in Frontend is crucial). Sadly, it does not yet support ARM macOS, so us M1-3 users will have to wait a bit :/

But usually, at least I don't build an executable while iterating. And if I do, I try to set up the feature flags so the build is minimal for the tests I am running
Post reply on HN