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

A possible new back end for Rust

jason-williams.co.uk

Post reply on HN
Print view View original

81–90 of 224 posts

Re: A possible new back end for Rust

#81

Post by andrewprock »

The thing that struck me most about the article was this quote from the Rust Survey (2019):

“Compiling development builds at least as fast as Go would be table stakes for us to consider Rust“

Go was designed from the ground up to have super fast compile times. In fact, there are some significant language issues related to that design decision.

Using one of the primary design goals that impacted language structure as "table stakes" is almost certainly going require a lot of effort with some serious unintended consequences.

Improving compilation times sounds good. Aiming high is good. But reaching "best of breed performance" is major initiative.

Re: A possible new back end for Rust

#82

Post by pjmlp »

VHRanger wrote: post #15
pizlonator wrote: post #2

This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm. I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t b…

Note that the LLVM monoculture came about because of how much of a pain GCC is to work with. And GCC being a pain to work with is a deliberate decision by Stallman to avoid his baby being expanded upon by corporations

Having a GCC monoculture wouldn't be much better.

Re: A possible new back end for Rust

#83

Post by fluffything »

pjmlp wrote: post #6
pizlonator wrote: post #2

This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm. I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t b…

This is also why I think it was great that Maxime eventually graduated into GraalVM. Another tool for compiler research using modern approaches with type safe languages.

Isn't GraalVM completely tied to LLVM bitcode, and therefore has all the same problems that LLVM has ?

Re: A possible new back end for Rust

#84

Post by est31 »

wahern wrote: post #72
VHRanger wrote: post #15

Earlier quoted context omitted.

Note that the LLVM monoculture came about because of how much of a pain GCC is to work with. And GCC being a pain to work with is a deliberate decision by Stallman to avoid his baby being expanded upon by corporations

That sentiment is about 10 years out-of-date. Today, GCC supports modules better than clang/LLVM, and has moved to a minimal C++ coding standard. And time has proven that clang and LLVM are no less a moving target than GCC--it turns out that simply writing things in C++ with OOP doesn't automatically guarantee API compatibility while preserving the ability to hack on the implementation.

GCC can't do runtime retargeting. This is a major drawback because suddenly you need your distro to think about your pet niche target. Suddenly you need your build system to choose the correct linker instead of just being able to use ldd. I'm a big fan of GNU and the GPL, but clang is much better in this regard.

Re: A possible new back end for Rust

#85

Post by tick_tock_tick »

dtolnay wrote: post #47
gok wrote: post #38

Novel compiler backends are a super cool idea, but I don't think it's going to help Rust compile speeds as much as this posts suggests. The complexity of Rust's type system puts a pretty high lower bound on compile times because of work the front end needs to do. Plain C compiles quickly even with an LLVM backend, for example.

Rustc normally spends way more time in LLVM than in the frontend. Rust parsing and type checking are very fast in comparison to LLVM's codegen. Here is a chart from last September showing where the time goes in compiling a large Rust codebase (rustc itself): https://gistpreview.github.io/?74d799739504232991c49607d5ce7... (Scroll down to the large horizontal bars once dependencies have been built.) (Sorry if GitHub is…

Rust is famous for throwing garbage IR at LLVM and hoping it cleans it all up. They've made a lot of progress but comparing the timing is very misleading when the work is intentionally offloaded to LLVM.

Re: A possible new back end for Rust

#86

Post by steveklabnik »

Waterluvian wrote: post #64
tadfisher wrote: post #61

Earlier quoted context omitted.

A language like Rust aims for "zero-cost abstractions", which means the features and behaviors of the language must be evaluated in the context of the implementation.

Let me attempt to unpack this into language I think I understand: It's up to Rust's compiler to verify all the contracts made, because in order for the binary to be "zero-cost", none of those checks are being done at runtime. If you looked at the output assembly, you would see what looks like very carefully written code that shows no explicit signs of protecting itself. Ie. there's no swaths of boilerplate assembly d…

You're not wrong, exactly, but I'm not 100% sure this is right. The way I would put it is this: Rust has made certain commitments about performance. This means that language changes have to be made in the context of how they are implemented, because releasing a language feature that causes a significant performance degradation would make it not a good fit by definition.

Re: A possible new back end for Rust

#87

Post by bronson »

Koshkin wrote: post #5

I've been wondering lately if the modern compilers should all be using C as the intermediate language (or some language-specific code optimization opportunities could be lost if they do that).

cfront demonstrated how this is a bad idea. And it was for C++, about as C friendly as you can get.

Re: A possible new back end for Rust

#88

Post by steveklabnik »

edflsafoiewq wrote: post #78
steveklabnik wrote: post #70

Earlier quoted context omitted.

We can compare them! https://godbolt.org/z/-Fzuqs (My screen is small so it's tough for me to read these results, to be honest...)

I believe that is the IR after the optimizer has chewed through it.

Oh duh. Should be obvious that you can drop the -O flags, at least.

Re: A possible new back end for Rust

#89

Post by pjmlp »

andrewprock wrote: post #81

The thing that struck me most about the article was this quote from the Rust Survey (2019): “Compiling development builds at least as fast as Go would be table stakes for us to consider Rust“ Go was designed from the ground up to have super fast compile times. In fact, there are some significant language issues related to that design decision. Using one of the primary design goals that impacted language structure as…

If you mean generics, D, Delphi, Ada and plenty of other languages prove you can have them and still be pretty fast.

Re: A possible new back end for Rust

#90

Post by pjmlp »

gok wrote: post #38

Novel compiler backends are a super cool idea, but I don't think it's going to help Rust compile speeds as much as this posts suggests. The complexity of Rust's type system puts a pretty high lower bound on compile times because of work the front end needs to do. Plain C compiles quickly even with an LLVM backend, for example.

Haskell, OCaml, SML, Idris also compile quite fast, with complex type systems.

Their secret? Multiple backends with different kinds of optimizations.

You don't need to compile for the ultimate release performance when in the middle of compile-debug-edit cycle.

Post reply on HN