4 ms·

While I certainly agree that it would take time, I'm not so sure of 'decades' needed, I believe the scope of a Rust specific backend would be quite different fr

by gribbly 10y ago

While I certainly agree that it would take time, I'm not so sure of 'decades' needed, I believe the scope of a Rust specific backend would be quite different from that of a everything-but-the-kitchen-sink backend like LLVM. Also not sure that reaching optimization parity with LLVM is an absolute necessity, Clang/LLVM is not as good at optimizing as GCC but that hasn't rendered it unpopular. Looking at Go as a benchmark, the compiler seems to be improving the optimization at a good pace and supports X86, ARM, PPC, MIPS, S390 despite being relatively young language and also having recently rewritten the compiler.

pjmlp 10y ago
Go still doesn't quite match what most Java native compilers are capable of. For that you need to use gccgo. The main problem with this kind of effort is mostly political, as many developers don't make a difference between language and implementation, thus making it harder for a language like Rust to win the hearts of its target audience, e.g. C developers that micro-optimize code as they write it.
- geodel 10y ago
  Are there benchmarks for those compilers? I ask because Go is quite competitive to Oracle JDK. http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/go.html
  - pjmlp 10y ago
    Yes, but usually Java compilers still tend to win when the benchmark is done in such a way that the 2nd level JIT is allowed to do its work. Go usually wins in those benchmarks, where Java code is either interpreted or still compiled with the 1st level JIT. And as mentioned, this is only relevant with the reference compiler, gccgo is much better.
    - igouy 10y ago
      > allowed to do its work < It's not like the programs are run with -Xint :-) It's not like a panacea -- https://arxiv.org/abs/1602.00602 https://arxiv.org/abs/1602.00602
    - gribbly 10y ago
      >gccgo is much better. Actually I did a benchmark run not that long ago between Gccgo and Go with the latter winning most of the benchmarks, I believe this mainly has to do with Gccgo lacking escape analysis.
pcwalton 10y ago
> Also not sure that reaching optimization parity with LLVM is an absolute necessity, Clang/LLVM is not as good at optimizing as GCC but that hasn't rendered it unpopular. Clang/LLVM is essentially as good as GCC. It depends on the benchmark you're looking at. Getting up to LLVM parity would take years and years. > Looking at Go as a benchmark, the compiler seems to be improving the optimization at a good pace and supports X86, ARM, PPC, MIPS, S390 despite being relatively young language and also having recently rewritten the compiler. It will take years and years for Go to achieve LLVM's level of optimization (assuming that they want to; I suspect that they won't when it starts regressing compile times).
- gribbly 10y ago
  >It will take years and years for Go to achieve LLVM's level of optimization Looking at Rust vs Go over at 'benchmarksgame' (granted these are micro-benchmarks), Go seems to compare very well for tests that are mainly computational and thus avoid involving the GC very much (even beating Rust on a couple). http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... And let's not forget that Go hasn't really had any focus on optimizations up until the last release where SSA was introduced. Anyway, maybe I'm projecting as I would like to see a full Rust toolchain in Rust, and my (very possibly entirely wrong) impression is that Rust devs have been struggling with getting the full performance potential of Rust through LLVM.
  - pcwalton 10y ago
    The benchmarks game is one thing. Doing well on real code that isn't ridiculously microoptimized is quite another. It makes zero sense to write a new backend for Rust from scratch because Go does well on a few microbenchmarks. Go's compiler infrastructure is across the board worse than that of LLVM (in compile-time performance too; some of Go's algorithms have worse asymptotics than the more sophisticated ones in LLVM). LLVM doesn't do things like SROA and alias analysis just for fun. > my (very possibly entirely wrong) impression is that Rust devs have been struggling with getting the full performance potential of Rust through LLVM. I'm a Rust compiler dev and I have no idea what you're talking about. LLVM is working wonderfully for us. If we had done what Go did, we'd quite possibly have failed. I have a different proposal. Instead of reinventing the world for no reason, let's treat bugs in LLVM/rustc as bugs, and fix them.

by gribbly 10y ago

pjmlp 10y ago

Go still doesn't quite match what most Java native compilers are capable of. For that you need to use gccgo. The main problem with this kind of effort is mostly political, as many developers don't make a difference between language and implementation, thus making it harder for a language like Rust to win the hearts of its target audience, e.g. C developers that micro-optimize code as they write it.

geodel 10y ago
Are there benchmarks for those compilers? I ask because Go is quite competitive to Oracle JDK. http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/go.html
- pjmlp 10y ago
  Yes, but usually Java compilers still tend to win when the benchmark is done in such a way that the 2nd level JIT is allowed to do its work. Go usually wins in those benchmarks, where Java code is either interpreted or still compiled with the 1st level JIT. And as mentioned, this is only relevant with the reference compiler, gccgo is much better.
  - igouy 10y ago
    > allowed to do its work < It's not like the programs are run with -Xint :-) It's not like a panacea -- https://arxiv.org/abs/1602.00602 https://arxiv.org/abs/1602.00602
  - gribbly 10y ago
    >gccgo is much better. Actually I did a benchmark run not that long ago between Gccgo and Go with the latter winning most of the benchmarks, I believe this mainly has to do with Gccgo lacking escape analysis.

pcwalton 10y ago

> Also not sure that reaching optimization parity with LLVM is an absolute necessity, Clang/LLVM is not as good at optimizing as GCC but that hasn't rendered it unpopular. Clang/LLVM is essentially as good as GCC. It depends on the benchmark you're looking at. Getting up to LLVM parity would take years and years. > Looking at Go as a benchmark, the compiler seems to be improving the optimization at a good pace and supports X86, ARM, PPC, MIPS, S390 despite being relatively young language and also having recently rewritten the compiler. It will take years and years for Go to achieve LLVM's level of optimization (assuming that they want to; I suspect that they won't when it starts regressing compile times).

gribbly 10y ago
>It will take years and years for Go to achieve LLVM's level of optimization Looking at Rust vs Go over at 'benchmarksgame' (granted these are micro-benchmarks), Go seems to compare very well for tests that are mainly computational and thus avoid involving the GC very much (even beating Rust on a couple). http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... And let's not forget that Go hasn't really had any focus on optimizations up until the last release where SSA was introduced. Anyway, maybe I'm projecting as I would like to see a full Rust toolchain in Rust, and my (very possibly entirely wrong) impression is that Rust devs have been struggling with getting the full performance potential of Rust through LLVM.
- pcwalton 10y ago
  The benchmarks game is one thing. Doing well on real code that isn't ridiculously microoptimized is quite another. It makes zero sense to write a new backend for Rust from scratch because Go does well on a few microbenchmarks. Go's compiler infrastructure is across the board worse than that of LLVM (in compile-time performance too; some of Go's algorithms have worse asymptotics than the more sophisticated ones in LLVM). LLVM doesn't do things like SROA and alias analysis just for fun. > my (very possibly entirely wrong) impression is that Rust devs have been struggling with getting the full performance potential of Rust through LLVM. I'm a Rust compiler dev and I have no idea what you're talking about. LLVM is working wonderfully for us. If we had done what Go did, we'd quite possibly have failed. I have a different proposal. Instead of reinventing the world for no reason, let's treat bugs in LLVM/rustc as bugs, and fix them.