A possible new back end for Rust

https://jason-williams.co.uk/a-possible-new-backend-for-rust

by obl • 6 years ago

526 218 6 years ago

jason-williams.co.uk

pizlonator14• 6 years ago

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 be assumed that just because llvm has an optimization that this optimization is profitable anywhere but llvm or at all.

Final thought, someone should try this with B3. https://webkit.org/docs/b3/

pjmlp14• 6 years ago

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.

fluffything2• 6 years ago

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

edwintorok2• 6 years ago

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

ddevault3• 6 years ago

I use qbe, it's great. Here's a mostly feature-complete C11 compiler based on qbe:

https://git.sr.ht/~mcf/cproc

bluejekyll• 6 years ago

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

VHRanger• 6 years ago

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

ddavis• 6 years ago

It's unfair to rms to say that. He would be happy for corporations to use and contribute to any project associated with the GNU project (like GCC), if everyone wanted to play along in GPL land (which of course isn't reality).

wahern• 6 years ago

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.

yarrel• 6 years ago

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

pjmlp14• 6 years ago

Having a GCC monoculture wouldn't be much better.

Rochus3• 6 years ago

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

yjftsjthsd-h3• 6 years ago

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 option reduces monoculture issues by adding more options.

benibela• 6 years ago

There are non-llvm compilers.

FreePascal for example has its own x86, arm, mips, sparc and powerpc backends

swagonomixxx• 6 years ago

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, but you can create that "backend" in LLVM itself - it's a new target architecture instead of e.g x86.

The great thing about LLVM is that it's effectively the quickest (and probably the best) way to generate machine code without putting in too much effort, for a language. Whether that language be a research language or an existing industry language (say, C), that kind of establishment is hugely valuable.

A great example of a good monoculture is the Go monoculture. Sure, there's gccgo, but the proportion of people using that vs. the reference implementation is minimal, and that reduced fragmentation is actually a good thing for practitioners (which most engineers are, not PL researchers).

dmix• 6 years ago

What about the usecase provided in the blog post, where one is used for fast debugging/dev builds but you use LLVM for production releases? Basically: why not both?

I'm guessing this could create some divergence in terms of what is supported by the compiler but I'm curious how much that would matter in reality - for day-to-day serious project development. I'm not familiar with language dev at the compiler level, so I'm curious to hear if that's practical or sane.

pizlonator14• 6 years ago

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.

cfv• 6 years ago

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.

fnord123• 6 years ago

LLVM's MCJIT library is 17MB. If you have a language that you want to JIT and you thought you could embed your language like lua (<100k), Python (used to be ~250k but now <3M), you're looking at almost 20MB out of the gates. Not ideal!

Also if you want to use llvm as a backend for your project and expect to build llvm as part of a vendored package, the llvm libraries with debug symbols on my machine was about 3GB. Also not ideal.

Someone• 6 years ago

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 dynamically change compiled code. That doesn’t make it optimal for JavaScript, a language that’s highly dynamic and often is used in cases where compilation time can easily dwarf execution time.

pizlonator14• 6 years ago

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.

stjohnswarts3• 6 years ago

HN isn't the place to go for conservative opinions on compilers :)

enos_feedler• 6 years ago

We are also seeing MLIR emerging as a compiler framework and LLVM being a dialect of that. This is happening within the LLVM project itself. From this point, it may be easier to write compilers without bringing in all of LLVM with it.

amelius• 6 years ago

Does it support JIT compilation, i.e. specialization at runtime?

steveklabnik19• 6 years ago

Cranelift has a JIT, but I am not sure what the status of it is as a rustc backend.

Koshkin• 6 years ago

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

edwintorok2• 6 years ago

The semantics of C aren't very well defined, there is a lot of ambiguity in the form of undefined and implementation defined behaviour. This ambiguity is often needed to build an efficient optimizing compiler.

When you have a higher level language with more accurately defined semantics, running it all through C would risk introducing undefined behaviour.

With an IR you can control and define the semantics more closely to what your language needs.

ansible2• 6 years ago

I've got to wonder if any of the existing intermediate representations would be appropriate with other programming languages.

jfkebwjsbx4• 6 years ago

When you have a higher level language with more accurately defined semantics, running it all through C would risk introducing undefined behaviour.

No, it wouldn't. When you target C you need to write a proper backend for its abstract machine, rather than naively rewriting code, of course.

The C abstract machine is a fine IR, specially the later editions of the standard.

epage• 6 years ago

While a C backend is great for compatibility, is it a sufficient IL to express everything? For example, Rust has some extra guarantees with aliasing that I'm unsure if C or C extensions support yet that could offer greater optimizations (currently not fully being used due to bugs in the LLVM backend).

bregma• 6 years ago

Modern compilers generally have a language-specific front and that generates an intermediate representation of the program logic, which is then transformed into an abstract representation (such as a single static analysis tree) for optimization. That is then transformed into an abstract machine description language, which gets further transformed by the back end into concrete machine instructions or assembly code.

Outside of the language-specific front end, compilers generally have no knowledge of the programming language itself. There is no technical advantage to transforming Rust into C when it comes to the middle and back ends, which form the bulk of the compiler.

There are no language-specific optimization opportunities. There are, of course, restrictions on what you can do in some languages that eliminate optimization opportunities, but you're not suddenly going to be able to take advantage of those opportunities by transforming your code into a langue that lacks the restrictions, because then you change the semantics of your code.

jfkebwjsbx4• 6 years ago

There is no technical advantage to transforming Rust into C

There is a key one: the ability to use any C compiler out there (including proprietary ones). This allows you to target all platforms out there.

steveklabnik19• 6 years ago

It's a sad thing that you've been downvoted for posting a thought. Others have already said the drawbacks of this idea, but there are also pros.

mratsim9• 6 years ago

Indeed. Time-to-market is an obvious one and esoteric platform support, and maybe also debuggability.

Ididntdothis2• 6 years ago

That’s how C++ started out but as far as I know this had lots of limitations in terms of optimization so they started writing native C++ compilers.

mratsim9• 6 years ago

I would be surprised if optimization was the actual goal. C++ is not faster than C.

stephencanon2• 6 years ago

If you're trying to implement a language with substantially different semantics from C (e.g. a substantially different memory model, or without UB) the semantics of C make it really unsuitable as an IR.

You can't use C's casts (undef for out of range float -> int conversions, for example), arithmetic (undef for signed overflow), or shift operators (implementation-defined behavior for signed right shifts, undefined behavior for left shifts into the signbit or shift counts not in [0, n)). You can work around these by defining functions with the semantics that your language needs, but they get gross pretty quickly (they are both much more verbose and more error-prone than having an IR with the semantics you really want, and they require optimizer heroics to reassemble them into the instructions you really want to generate). Alternatively, you can use intrinsics or compiler builtins, but then you're effectively locking yourself to a single backed anyway, and might as well use its IR.

The issues around memory models (especially aliasing, but also support for unaligned access, dynamic layouts, etc) are worse.

Even LLVM IR is too tightly coupled to the semantics of C and C++ to be easily usable as a really generic IR for arbitrary languages (Rust, Swift, and the new Fortran front end have all had some struggles with this, and they're more C-like than most languages). C is much worse in this regard.

raphlinus• 6 years ago

I agree 99.44%.

The behavior of shift operations on signed integers will be fixed in C++20 and C2x, as part of the effort to require twos complement representation. It is a massive potential source of UB in currently standardized C and C++.

All the other problems listed remain.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090...

[2] http://eel.is/c++draft/expr.shift#2

sambe2• 6 years ago

Doesn't Nim do that?

mhh__2• 6 years ago

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)

nimmer• 6 years ago

Yes, Nim uses C and GCC and this gave it very fast compile times and similar performance. It also runs on most devices supported by GCC.

jcranmer4• 6 years ago

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 it tends to be as bad or worse in most other languages.

* ABI control is poor. You can't come up with any way to return multiple register values, for example.

* Anything that's not a vanilla function isn't supported. No uparg function support (required for Pascal), multiple entry points (required for Fortran), or zero-cost exception handling (required for C++). Hell, even computed goto isn't actually supported.

And all of this is assuming you have strong control over how you expect implementation-defined behavior (e.g., sizeof(int)) to work.

StreamBright2• 6 years ago

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

bronson• 6 years ago

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

crad• 6 years ago

While it appears that cg_clif is faster to compile, does it provide any performance benefit compared to cg_llvm? Are the compiled binaries as fast as llvm compiled binaries? If not is the use-case for development purposes only?

__s• 6 years ago

Correct, cranelift is meant for faster development build cycles

https://github.com/bytecodealliance/wasmtime/blob/da02c913cc...

wscott• 6 years ago

From the article, it is pretty clear that the resulting code is not as optimized as the LLVM backend. I didn't see any claims of how much slower it would be, but clearly that will vary greatly. Fast to compile is still really handy while developing.

liquidify• 6 years ago

>"That’s Bjorn3, he decided to experiment in this area whilst on a summer vacation, and a year & half later single-handedly (bar a couple of PRs) achieved a working Cranelift frontend."

Is this guy human? This is amazing, and this guy should be given an award.

korpiq• 6 years ago

This feels welcome to me. I tend to think a language needs multiple independent implementations that only share the same source language spec, in order to really tear a clear spec apart from the quirks of any particular implementation.

I find Rust (the spec, though also the implemenration) quite safe and practical (a balance). It deserves some independent implementations to secure a long and stable future.

On the other hand, I want to use it on non-ARM embedded platforms, where current cross-compilation through C produces unusably big binaries. I dream this might increase hope for that, too, eventually.

thesuperbigfrog2• 6 years ago

> I find Rust (the spec, though also the implemenration) quite safe and practical (a balance). It deserves some independent implementations to secure a long and stable future.

Where is the Rust spec? Unless something happened really quickly that I was not aware of there is only the implementation.

steveklabnik19• 6 years ago

https://doc.rust-lang.org/stable/reference/ is the closest thing we have. It is not yet complete.

jlebar• 6 years ago

If there are any rust people here, you've probably considered that you can speed up your debug llvm builds by enabling some optimizations. SimplifyCFG comes to mind, but, like, you can experiment. I presume the reason you haven't is because you want to preserve debug info, and llvm isn't great at that when optimizations are on.

the8472• 6 years ago

You can customize the debug profile or create an intermediate profile between release and debug in your Cargo.toml. Debug info and optimization levels can be configured separately.

If by speed up you mean compile times and not runtime behavior then there's also some unstable compiler flag that allows adding specific llvm passes.

mttyng• 6 years ago

This is awesome. It doesn’t even seem that long ago when Boa was started! Man, time flies and people do great things. Kudos to the author and co-contributors for what Boa has become.

gok2• 6 years ago

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.

steveklabnik19• 6 years ago

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.

gok2• 6 years ago

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.

dtolnay2• 6 years ago

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 down at the moment; try later if it doesn't load.)

The blue part of each bar is time in the frontend, the purple part is time in LLVM. The largest bar (rustc) spans 105 seconds in LLVM out of 140 total, or 75% in LLVM. Many of the subcrates are even more dominated by LLVM time, for example look at rustc_metadata or rustc_traits where >95% of compile time is spent in LLVM.

tick_tock_tick• 6 years ago

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.

aw16211073• 6 years ago

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 room for significant wins by switching backends.

As for why C can compile quickly with an LLVM backend while Rust can't, I'm not sure. I've read in the past that rustc generates pretty bad LLVM IR to pass to the backend, and it takes time for LLVM to sort through that, but there's probably some other factors in there too.

[0] https://blog.rust-lang.org/inside-rust/2020/02/25/intro-rust...

edflsafoiewq3• 6 years ago

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.

pjmlp14• 6 years ago

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.

isatty• 6 years ago

From my (limited) experience, Haskell does not compile fast, especially if you’re doing something that needs lenses.

dgellow• 6 years ago

Haskell and Idris both have very slow compilation time.

tyrion• 6 years ago

Thanks for nice article! Hoping the author reads the comments, I would like to leave an, hopefully useful, feedback.

It would greatly improve the reading experience of your blog if you could make clickable the footnotes/references.

For example when you say:

I’ve taken the chart from the 2016 MIR blog post[3]

I have to scroll to the end of the page to find the blog post (and then scroll back to resume reading). If [3] were clickable it would be great. It would be even better if [MIR blog post] were an actual link itself.

Waterluvian4• 6 years ago

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?

kevinmgranger• 6 years ago

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

Waterluvian4• 6 years ago

I walked through the Java portion of Crafting Interpreters and indeed, they can be much simpler than you might imagine in your early years. I was more just paying a compliment than suggesting that maintainers are superhuman. Everyone who ships productive code is a wizard and you can be too!

I modified my original question to avoid a potential distraction from what I want to talk about. Thanks!

xscott• 6 years ago

Do you have any links for the prior art? I'm sincerely interested, thank you if you do. I'd also be interested in any articles (or even blog posts) that describe Rust's process for that from a compiler writer's point of view.

tadfisher• 6 years ago

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.

Waterluvian4• 6 years ago

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 doing borrow checking, out of bounds checking, etc.

steveklabnik19• 6 years ago

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 that have re-written massive parts of the compiler, and more ongoing. For example, non-lexical lifetimes required inventing an entire additional intermediate language, re-writing the compiler to use it, and making sure that everything kept working while doing so.

More recently, the compiler has been being re-done from a classic, multiple-pass architecture to a more Roslyn, "query-based" one. Again, this is being done entirely "in-flight", while keeping a project that's used by a lot of folks stable. The rust-analyzer has made this project even more interesting; a "librarification" strategy is being undergone to make the compiler more modular.

For some numbers on this kind of thing, https://twitter.com/steveklabnik/status/1211667962379276288/... and https://twitter.com/steveklabnik/status/1211717308143587334/...

Waterluvian4• 6 years ago

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!

j88439h842• 6 years ago

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?

andrewprock2• 6 years ago

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.

pjmlp14• 6 years ago

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

andrewprock2• 6 years ago

I mean interface{}

https://golang.org/doc/effective_go.html#interfaces_and_type...

dwheeler4• 6 years ago

One cool advantage of having multiple compilers for a language is that you can use one as a check on the other.

For example, if you're worried that one of the compilers might be malicious, you can use the other compiler to check on it: https://dwheeler.com/trusting-trust

Even if you're not worried about malicious compilers, you can generate code, compiled it against multiple compilers, and sending inputs and see when they differ in the outputs. This has been used as a fuzzing technique to detect subtle errors in compilers.

steveklabnik19• 6 years ago

Yep! This is a very good property, and part of why mrustc is a big deal.

gbrown_2• 6 years ago

For example, if you're worried that one of the compilers might be malicious, you can use the other compiler to check on it: https://dwheeler.com/trusting-trust

This still requires the use of a use of trusted compiler though. Comparing two compilers arbitrarily shows if there is consensus, it does not give guarantees about correctness.

From the link.

    In the DDC technique, source code is compiled twice: once with a second
    (trusted) compiler (using the source code of the compiler’s parent), and then
    the compiler source code is compiled using the result of the first
    compilation. If the result is bit-for-bit identical with the untrusted
    executable, then the source code accurately represents the executable.

dwheeler4• 6 years ago

First, I forgot to disclose: I am the author of https://dwheeler.com/trusting-trust .

As discussed in detail in that dissertation, if you are using diverse double compiling to look for malicious compilers, the trusted compiler does not have to be perfect or even non-malicious. The trusted compiler could be malicious itself. The only thing you're trusting is that the trusted compiler does not have the same triggers or payloads as the compiler it is testing. The diverse double compiling check merely determines whether or not the source code matches the executable given certain assumptions. The compiler could still be malicious, but at that point the maliciousness would be revealed in its source code, which makes the revelation of any malicious code much, much easier.

You're absolutely right about the general case merely showing consistency, not correctness. I completely agree. But that still is useful. If two compilers agree on something, there is a decent chance that their behavior is correct. If two computers disagree on something, perhaps that is an area where the spec allows disagreement, but if that is not the case then at least one of the compilers is wrong. The check by itself won't tell you whirch one is wrong, but at least it will tell you where to look. In a lot of compiler bugs, having some sample code that causes the problem is the key first step.

pitaj• 6 years ago

Please don't quote with code blocks. Makes reading on mobile very difficult.

The quote reformatted:

In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Myrmornis• 6 years ago

There wouldn't be any surprises, or cognitive dissonance, from using very different paths for debug versus release builds?

On a small project, personally I use --release sometimes during development because the compile time doesn't matter that much and the resulting executable is much faster: if I don't use --release I can get a misleading sense of UX during development.

steveklabnik19• 6 years ago

This already happens a bunch, even with the current setups. It's very natural if you come from a compiled language, and not if you don't. The first step of someone saying "hey why is Rust slow?" is five people replying "did you use --release".

sfink• 6 years ago

Can confirm.

I had a graph traversal program written in Python. I ported it to Rust, and the runtime was identical -- 68.4 seconds, down to the tenth of a second. (Kinda blew my mind -- I had to triple check that I was running and timing what I thought I was!) I had a bit of a crisis of faith.

I poked at it a few times over the next week, then finally got on the IRC channel and quickly received the advice mentioned above. Same input, with --release: 6.2 seconds.

Leherenn2• 6 years ago

It's funny, because I do the exact opposite.

As a developer I usually have a pretty powerful machine, and I've found that debug mode is a good way to approximate slow computers, and something that is unbearably slow in debug will bother some users later on.

runevault• 6 years ago

This is an interesting idea, but I guess my one question is how much does the slowness of debug relate to HOW it will be slow in release? Since release optimizations can do pretty radical things to the assembly generated it feels like it wouldn't really be apples to apples.

WalterBright• 6 years ago

The D programming language has 3 compilers, one with LLVM (LDC) one with GCC (GDC) and one with the Digital Mars back end (DMC).

It's great to have all three, as they each have different characteristics in terms of speed, generated code, debug support, platform support, etc. Supporting these three also helps maintain proper semantic separation of code gen from front end.

stjohnswarts3• 6 years ago

Has the D community been growing or shrinking over the past decade or so? Staying relatively the same size?

stackzero• 6 years ago

+1 enjoyed how accessible this write up was

brokenbotnet• 6 years ago

Really great.

tester3• 6 years ago

How do they ensure that output of both compilers is correct?

e.g LLVM output is A, but the new one is B, how do they deal with different results between backends?

A possible new back end for Rust

Related Stories