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

51–60 of 224 posts

Re: A possible new back end for Rust

#51

Post by StreamBright »

jcranmer wrote: post #46
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).

C is a pretty lousy intermediate language: * It's missing several useful operators, such as classic bit manipulation (count trailing zero, byteswap), or even 8- and 16-bit arithmetic. Checked arithmetic is another useful one that's not present (or even really possible in C's ABI). * Signed integer overflow is UB. * Utterly no support for SIMD types. * Proper IEEE 754 floating-point control is kind of spotty, although…

Just out of curiosity, what would be a great intermediate language to transpile to (as of intermediate language)?

Re: A possible new back end for Rust

#52

Post by steveklabnik »

gok wrote: post #49
steveklabnik wrote: post #44

Earlier quoted context omitted.

While the type system does add to compile times, profiling generally doesn't show that it's the current limiting factor for compile times. Additionally, tools like rust-analyzer will give you type errors pretty much instantaneously, though of course that work is not finished. Also of note, this blog post isn't speculation; they posted numbers from actually doing it.

A 30% speedup is nothing to sneeze at, but it's not putting Rust within spitting distance of Go or C for similar amounts of code.

Absolutely. I don't see where anyone is claiming that.

Re: A possible new back end for Rust

#53

Post by craftinator »

phkahler wrote: post #45
CJefferson wrote: post #39

Earlier quoted context omitted.

Unfortunately not. For years people wanted gcc to output a nice parse tree for C++, which would have been plenty useful for open source text editors, but was banned by RMS as it would also be useful for closed source systems.

Not sure, but I think his concern was more about the introduction of opaque steps being introduced in the compiler and becoming something people depend on. A weak analogy might be nVidia drivers on linux, imagine a new arch where part of the toolchain is a closed blob. It turns out that hasn't happened yet with LLVM and allowing such things under LGPL may have worked.

I agree with this point of view; the three E's, Embrace, Extend, Extinguish, are already rampant in the compiler industry, and I see his choices as sacrificing ease of use for more transparency.

Re: A possible new back end for Rust

#54

Post by The_rationalist »

If I remember correctly, mozilla had layoff a few months ago and the developper(s) of cranelift were in the bag.

So is anybody currently paid to develop this backend? Without human resources I fail to see how this would keep up with truly supporting rust.

As an aside, while the goal of faster build time is an important one, for completeness sake, I must tell that the mentality of rustc developers to be backend agnostic (an ideal) come at the cost of preventing rustc from adopting most llvm attributes and this fact is at the advantage of c++.

Re: A possible new back end for Rust

#55

Post by The_rationalist »

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.

Who is Maxime?

Re: A possible new back end for Rust

#56

Post by [deleted] »

StreamBright wrote: post #51
jcranmer wrote: post #46

Earlier quoted context omitted.

C is a pretty lousy intermediate language: * It's missing several useful operators, such as classic bit manipulation (count trailing zero, byteswap), or even 8- and 16-bit arithmetic. Checked arithmetic is another useful one that's not present (or even really possible in C's ABI). * Signed integer overflow is UB. * Utterly no support for SIMD types. * Proper IEEE 754 floating-point control is kind of spotty, although…

Just out of curiosity, what would be a great intermediate language to transpile to (as of intermediate language)?

[deleted]

Re: A possible new back end for Rust

#57

Post by Waterluvian »

When writing a language like Rust, is the biggest challenge simply deciding what Rust's features and behaviors should be? And implementing the syntax and Rust -> LLVM compiler is really just a chore for the individuals who are super familiar with the implementation of these languages? Or is the technical implementation also genuinely challenging and non-obvious?

Re: A possible new back end for Rust

#58

Post by mratsim »

yjftsjthsd-h wrote: post #50
Rochus wrote: post #31

Earlier quoted context omitted.

Now it's called monoculture? Rather strange. But anyway: in your terms you're just replacing LLVM monoculture by Rust monoculture, isn't it?

Yes, it's a monoculture when the majority of all compiler work/research is happening on one compiler chain. (I feel like GCC is still competitive enough to keep up some competition, but Clang does have a lot of backing.) And yes, if we made a rust replacement and that somehow eclipsed all other compiler suites it would be a monoculture and be bad, but that's unlikely and creating an alternative to the most popular op…

LLVM has a library and modular approach which makes it easier for people to contribute just in their area of expertise instead of having to find their way in the hundred of thousands of line of GCC.

Re: A possible new back end for Rust

#59

Post by edflsafoiewq »

aw1621107 wrote: post #48
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.

I think you might be surprised just how much time is spent in codegen- and optimization-related code. For example, a bit over 75% of the time needed to compile the regex crate can be attributed to codegen- and optimization-related events, with a bit over 64% of that time spent in LLVM-related events specifically [0]. Granted, I'm not certain whether this is a release or debug build, but it does show that there is roo…

I wonder how much of it is just code style. A simple for-loop in C is probably going to be an iterator blob in Rust with an order of magnitude more code for the backend to chew through.

Re: A possible new back end for Rust

#60

Post by kevinmgranger »

Waterluvian wrote: post #57

When writing a language like Rust, is the biggest challenge simply deciding what Rust's features and behaviors should be? And implementing the syntax and Rust -> LLVM compiler is really just a chore for the individuals who are super familiar with the implementation of these languages? Or is the technical implementation also genuinely challenging and non-obvious?

The concept of lifetime management is relatively novel and uncharted territory, if I understand correctly. There's only some prior art. So implementing that must have been an adventure and a half.

And while I'm sure the folks who work on these languages are wonderfully intelligent people, let's dispel this notion that you need to be a super genius to implement a compiler or something like that!

It seems magical, like one of the hardest things you could program-- but take a look through crafting interpreters, if you will: http://craftinginterpreters.com/

"Nothing is particularly hard if you break it down into small jobs." - Henry Ford

Post reply on HN