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.<p>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.<p>Final thought, someone should try this with B3. <a href="https://webkit.org/docs/b3/" rel="nofollow">https://webkit.org/docs/b3/</a>
One cool advantage of having multiple compilers for a language is that you can use one as a check on the other.<p>For example, if you're worried that one of the compilers might be malicious, you can use the other compiler to check on it: <a href="https://dwheeler.com/trusting-trust" rel="nofollow">https://dwheeler.com/trusting-trust</a><p>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.
>>"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."<p>Is this guy human? This is amazing, and this guy should be given an award.
The D programming language has 3 compilers, one with LLVM (LDC) one with GCC (GDC) and one with the Digital Mars back end (DMC).<p>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.
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.<p>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.<p>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.
The thing that struck me most about the article was this quote from the Rust Survey (2019):<p>“Compiling development builds at least as fast as Go would be table stakes for us to consider Rust“<p>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.<p>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.<p>Improving compilation times sounds good. Aiming high is good. But reaching "best of breed performance" is major initiative.
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?
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'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).
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.
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?
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.
Thanks for nice article!
Hoping the author reads the comments, I would like to leave an, hopefully useful, feedback.<p>It would greatly improve the reading experience of your blog if you could make clickable the footnotes/references.<p>For example when you say:<p>> I’ve taken the chart from the 2016 MIR blog post[3]<p>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.
How do they ensure that output of both compilers is correct?<p>e.g LLVM output is A, but the new one is B, how do they deal with different results between backends?
There wouldn't be any surprises, or cognitive dissonance, from using very different paths for debug versus release builds?<p>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.