A possible new back end for Rust • Hacker News Board

Re: A possible new back end for Rust

#121

Post by pizlonator » Tue, Apr 21, 2020, 7:03 PM UTC

swagonomixxx wrote: post #92

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…

Devil's advocate: more diverse compiler tech will mean a more fragmented community and a larger probability of divergence across implementations. People think the C compiler community is dominated by GCC and Clang, and it is, but there are literally 1000s of implementations out there in the wild. Most are necessary, because we need code generated for some obscure processor architecture that's completely proprietary,…

Llvm is absolutely not the least effort for generating machine code. In many settings, it takes a fraction of the effort of integrating llvm to create a template compiler that goes straight to machine code. In many other cases, your best bet is to have your compiler emit C and then feed that to a C compiler of your choice.

It’s good to have divergence. Competition is good. Otherwise people stop trying new things.

Re: A possible new back end for Rust

#122

Post by chc » Tue, Apr 21, 2020, 7:03 PM UTC

jfkebwjsbx wrote: post #111

fluffything wrote: post #77

Earlier quoted context omitted.

Cranelift - the compiler toolchain being discussed in this post (previously known as Cretonne) - is actually completely written in Rust, being developed (obviously) by Rust programmers, that are members of the Rust community. Its development started at Mozilla, which still employs some of its developers to work on it full-time. So.. the claim that the Rust community is not big enough to achieve this is wrong, since t…

> LLVM is not fine: it is super _super_ slow Source? LLVM is fast for what it does. What people usually complain about is rustc being slow overall, not the LLVM passes.

This is true to some degree — Rust does more work than most programming languages, and that work will always take some time — but the Cranelift backend is also measurably faster than the LLVM one.

Re: A possible new back end for Rust

#123

Post by iamrecursion » Tue, Apr 21, 2020, 7:05 PM UTC

fluffything wrote: post #83

pjmlp wrote: post #6

Earlier quoted context omitted.

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 ?

Not at all. There’s an LLVM bitcode interpreter built on top of GraalVM, but the VM itself is heavily reliant on the internals of OpenJDK.

Re: A possible new back end for Rust

#124

Post by pizlonator » Tue, Apr 21, 2020, 7:05 PM UTC

cfv wrote: post #93

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…

I still remember when Clang bringing LLVM along was seen as SO OUT THERE and I'm just mentioning it because I find it weird to be old enough to see fads in system languages come and start to go. Just curious, do you have any examples of this "limitations" you speak of? Sounds like a very interesting read.

Llvm makes some questionable choices about how to do SSA, alias analysis, register allocation, and instruction selection. Also it goes all in on UB optimizations even when experience from other compilers shows that it’s not really needed. Maybe those choices are really fundamental and there is no escaping them to get peak perf - but you’re not going to know for sure until folks try alternatives. Those alternatives likely require building something totally new from scratch because we are talking about things that are fundamental to llvm even if they aren’t fundamental to compilers in general.

Re: A possible new back end for Rust

#125

Post by pizlonator » Tue, Apr 21, 2020, 7:09 PM UTC

Someone wrote: post #107

cfv wrote: post #93

Earlier quoted context omitted.

I still remember when Clang bringing LLVM along was seen as SO OUT THERE and I'm just mentioning it because I find it weird to be old enough to see fads in system languages come and start to go. Just curious, do you have any examples of this "limitations" you speak of? Sounds like a very interesting read.

As an example, WebKit had an LLVM-based JavaScript optimizer in 2014 ( https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ ), but dropped it for another one in 2016 ( https://webkit.org/blog/5852/introducing-the-b3-jit-compiler... ) In broad strokes, LLVM chooses to optimize for generating good code for statically compiled code more than for, for example, memory usage, compilation speed, or ability to dynami…

Worth noting that B3’s biggest win was higher peak throughput. It generated better code than llvm. It achieved that by having an IR that lets us be a lot more precise about things that were important to our front end compiler.

It’s not even about what language you’re compiling. It’s about the IR that goes into llvm or whatever you would use instead of llvm. If that IR generally does C-like things and can only describe types and aliasing to the level of fidelity that C can (I.e. structured assembly with crude hacks that let you sometimes pretend that you have a super janky abstract machine), then llvm is great. Otherwise it’s a missed opportunity.

Re: A possible new back end for Rust

#126

Post by pizlonator » Tue, Apr 21, 2020, 7:11 PM UTC

bluGill wrote: post #34

bluejekyll wrote: post #33

Earlier quoted context omitted.

While the GP doesn’t state this as an advantage, the Rust community would benefit from a fully Rust toolchain.

Why? Other than to prove it can be done what is the point. If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources. There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe the…

Historically writing a compiler in the language that you’re promoting is a good way to really understand the limitations of your language.

I think this works so well because language designers tend to understand compilers better than they understand other software.

Re: A possible new back end for Rust

#127

Post by pizlonator » Tue, Apr 21, 2020, 7:12 PM UTC

fluffything wrote: post #83

pjmlp wrote: post #6

Earlier quoted context omitted.

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 ?

Not even remotely.

Re: A possible new back end for Rust

#128

Post by bluGill » Tue, Apr 21, 2020, 7:20 PM UTC

fluffything wrote: post #77

bluGill wrote: post #34

Earlier quoted context omitted.

Why? Other than to prove it can be done what is the point. If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources. There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe the…

Cranelift - the compiler toolchain being discussed in this post (previously known as Cretonne) - is actually completely written in Rust, being developed (obviously) by Rust programmers, that are members of the Rust community. Its development started at Mozilla, which still employs some of its developers to work on it full-time. So.. the claim that the Rust community is not big enough to achieve this is wrong, since t…

I didn't claim rust isn't big enough to do it. (that may well be true given the large effort that went into llvm over many years to make it a good optimizer - this is a different debate though and I'm not sure if it is true)

What I said was rust is better off focusing on problems that are not solved well by other people. A fast modern web browser (with whatever features is lacking) for example.

Re: A possible new back end for Rust

#129

Post by j88439h84 » Tue, Apr 21, 2020, 7:20 PM UTC

steveklabnik wrote: post #116

j88439h84 wrote: post #97

Earlier quoted context omitted.

> Rust's got a really intense stability policy. I know the code won't stop running, but I wonder how soon it stops being idiomatic. If it's not idiomatic, it's harder to maintain due to unfamiliar style and structure. Does Rust have measures to deal with this issue?

I think the closest thing is enforced rustfmt. I don't hack on the compiler though, so maybe there's some stuff that the team does that they don't broadcast super widely.

I don't mean the code of the Rust compiler, I mean code written in Rust becomes unidiomatic as the idioms change. How fast does that happen, is it a problem, is it being addressed?

Re: A possible new back end for Rust

#130

Post by bluGill » Tue, Apr 21, 2020, 7:24 PM UTC

sambe wrote: post #40

bluGill wrote: post #34

Earlier quoted context omitted.

Why? Other than to prove it can be done what is the point. If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources. There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe the…

Why phrase it as "other than to prove it can be done" if you already know there are good answers? I think the following obviously do apply: 1) much easier for Rust community to contribute to the compiler from end-to-end. 2) lower coordination cost with LLVM giving complete, Rust-focussed control over code generation/optimisation. Think about e.g. fixing noalias. 3) lower maintenance cost for LLVM integration/fork. It…

Because I don't think the possible good answers apply.

Sure it is harder to contribute to the backend, but does it matter? I've been doing c++ for years and never looked at the backend.

I'll grant lower coordination costs. However I believe they are not outweighed by the advantages of the other llvm contributions.

If they need to fork llvm that is a problem. Either merge it back in and be done (with some tests so whatever they need is not broke), or there is a compelling reason as llvm won't work with their changes.