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

71–80 of 224 posts

Re: A possible new back end for Rust

#71

Post by steveklabnik »

Waterluvian wrote: post #67
steveklabnik wrote: post #66

Earlier quoted context omitted.

First of all, deciding features and behaviors is not simple. :) There are a number of technical implementation challenges in the compiler. It is a large project, and Rust's got a really intense stability policy. The compiler was bootstrapped very early, when the rate of change of the language itself was still "multiple things per day." This introduced significant architectural debt. There have been multiple projects…

Using the word "simply" is a quirk of mine. I'm very much trying to express that I think it's by far the hardest part. Thanks for your response!

It's all good :) You're welcome!

Re: A possible new back end for Rust

#72

Post by wahern »

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

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.

Re: A possible new back end for Rust

#73

Post by Rochus »

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…

So if we join forces and create a reusable compiler backend so not every compiler writer has to implement the same optimizers and code generators over and over again, then this is bad because it's a monoculture? How strange is that?

To me, it sounds more like political propaganda from a few idealists who want to justify why - instead of participating in a joint project - they want to develop everything themselves from scratch in their favourite technology. For this there is, nota bene, also a common term: "Not invented here" syndrome.

Re: A possible new back end for Rust

#74

Post by [deleted] »

edwintorok wrote: post #11
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…

Worth mentioning other alternative small backends: http://c9x.me/compile/

[deleted]

Re: A possible new back end for Rust

#75

Post by yarrel »

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

"Expanded upon" is a funny way of saying "incorporated into systems that removed their users' freedom".

Re: A possible new back end for Rust

#76

Post by jcranmer »

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)?

Of ones I'm a familiar with, LLVM IR is probably the best, although it has other issues of its own (in particular, floating point is done even worse than C). I'm not aware of any language which is going to beat a retargeting compiler's processor-agnostic IR.

But even the "better C" languages tend to not really attempt to expand C structurally. The changes amount to fixing the egregious semantics (fixed-size types, no int-promotion, define signed overflow, etc.), add vector types and other operators, maybe tweak ABI a little bit, and add a whole lot of syntactic sugar. And those languages that explore beyond C's limited structural repertoire do so at the cost of C's specificity.

That said, ever since the last time someone asked me this kind of question, I've been trying to design a portable assembly language.

Re: A possible new back end for Rust

#77

Post by fluffything »

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…

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 they have already done it..

The reason they are doing it, is that LLVM is not fine: it is super _super_ slow. People want Rust to compile instantaneously, and are willing to pay people full time to work on that.

D, for example, compiles much faster than C and C++, and does this by having their own backend for unoptimized builds. I don't know how big the D community is, so I can't compare its size to the Rust community, but they did it, and it payed of for them big time, so I don't see why it wouldn't pay off for Rust as well.

Re: A possible new back end for Rust

#78

Post by edflsafoiewq »

steveklabnik wrote: post #70
edflsafoiewq wrote: post #59

Earlier quoted context omitted.

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.

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.

Re: A possible new back end for Rust

#79

Post by mhh__ »

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)?

Firstly the programming language itself, then something like LLVM IR. This is an answer to a slightly different question but rewriting into the same language (i.e. C++ to C++ then LLVM) can make debugging much simpler and implementing features and specific optimizations much more feasible if you don't have control over the backend.

IR's should be terse, simple and dumb. I'm not sure any "real" programming language fits that.

Re: A possible new back end for Rust

#80

Post by mhh__ »

sambe wrote: post #41
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).

Doesn't Nim do that?

Just because you shouldn't doesn't mean you can't.

(C itself is not specified very thoroughly but C - a C implementation - is, in the sense that it only does one thing for a given line of code)

Post reply on HN