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

71–80 of 117 posts

Re: Cranelift code generation comes to Rust

#71

Post by doctor_phil »

kapilsinha wrote: post #69
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

Bevyengine is open source and very findable by most search engines.

Here is a direct link: https://github.com/bevyengine/bevy

Re: Cranelift code generation comes to Rust

#73

Post by kibwen »

mort96 wrote: post #65
thesz wrote: post #22

Earlier quoted context omitted.

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?

Doing a full-fledged release-this-to-millions-of-users build of Chrome or Firefox already takes on the order of 24 hours (or at least it did when last I checked a few years ago).

Re: Cranelift code generation comes to Rust

#74

Post by kapilsinha »

doctor_phil wrote: post #71
kapilsinha wrote: post #69

Earlier quoted context omitted.

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

Bevyengine is open source and very findable by most search engines. Here is a direct link: https://github.com/bevyengine/bevy

Ah yep I'm aware of that. Bevy is a framework/engine that devs built on top of. I was referring to the project that OP has built on top of Bevy

Re: Cranelift code generation comes to Rust

#75

Post by remorses »

mort96 wrote: post #65
thesz wrote: post #22

Earlier quoted context omitted.

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?

I am pretty sure the existing release process already takes much more than 2 hours.

Re: Cranelift code generation comes to Rust

#76

Post by thechao »

weinzierl wrote: post #7
chrisaycock wrote: post #5

This article provides an excellent overview of the latest in speed of optimizer vs quality of optimization . In particular, copy-and-patch compilation is still the fastest approach because it uses pre-compiled code, though leaves little room for optimization. Cranelift uses e-graphs to represent equivalence on the IR. This allows for more optimizations than the copy-and-patch approach. Of course, the most optimized o…

From what I understand, the big advantage of the e-graphs approach is, that the quality of the output is (within limits) a function the time and memory given. The more memory, the more nodes can be generated in the e-graph and the more time for search, the better the selected node. It might never be as fast as copy-and-patch or as good as LLVM or GCC, but this flexibility is a value in itself.

When we first reviewed the equality saturation paper, we thought there was one major pro, and one major con: [pro] phase-ordering invariant; [con] at the time there was no (believable) way to extract the transformed graph in a non-hand-wavy-way.

Personally, I think e-graphs should be combined with Massalin superoptimization — they're natural "duals" — and just turn the whole exercise into a hill-climbing process. You can tune the total effort by the set of passes used, the amount of time to drive the graph to saturation, and the method (and time) for graph extraction.

Re: Cranelift code generation comes to Rust

#77

Post by kibwen »

Filligree wrote: post #37
__s wrote: post #9

Earlier quoted context omitted.

Those numbers are the entire compile time, parsing/typecheck/MIR+MIR optimization/linking Don't have numbers handy, so hard to say how much faster Cranelift is making the codegen portion, but gets into Amdahl's Law

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

Because the linker provided by the system itself is the one that's guaranteed to be the most broadly compatible. For a toolchain to begin distributing an alternative linker is a lot of work on every supported platform (future versions of Rust may sidestep this issue by making LLD the default on certain platforms, which they get "for free" by dint of shipping alongside LLVM). But also, because there are about ten people on planet Earth qualified to write a production-grade linker, which is why LLD still isn't broadly recommended yet.

Re: Cranelift code generation comes to Rust

#78

Post by tekknolagi »

convolvatron wrote: post #68
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?

If by instructions you mean machine instructions, you don't; it's used for internal optimization passes only.

Re: Cranelift code generation comes to Rust

#79

Post by Filligree »

mort96 wrote: post #65
thesz wrote: post #22

Earlier quoted context omitted.

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?

Is it just a couple hours? Even just ordering the optimisation passes is already an NP-complete process, so I could easily imagine superoptimisers would take trillions of years for a large program...

Re: Cranelift code generation comes to Rust

#80

Post by MaxBarraclough »

mort96 wrote: post #65
thesz wrote: post #22

Earlier quoted context omitted.

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?

I'm not a compiler engineer, but I think it's a diminishing returns issue. Modern optimising compilers are already impressive, and they get more impressive year on year, but only quite slowly. We don't see compilers producing code that runs 30% faster than the code generated last year, for instance.

Such improvements can happen with compiler updates, but not when the starting point is a compiler that's already of decent quality. I recall some GPU driver updates from ATi (years ago) delivered pretty drastic performance improvements, but I believe that's because the original drivers were rather primitive.

(Perhaps a drastic improvement to autovectorisation could give a 30% boost, or better, but this would apply only to certain programs.)

You could grant a compute budget 100x the typical build set-up, but no one has built a production-ready compiler to take advantage of that, and if they did I suspect the improvements would be unimpressive. They may also run into a 'complexity ceiling' issue, as the compiler would presumably be even more complex than today's ordinary optimising compilers, which are already enormous.

As Filligree says, superoptimisers tend to only be practical for very short programs. They can't be applied to monstrous codebases like Chromium.

Post reply on HN