6 ms·

Not sure how much is due to this, but LLVM has gotten much slower in recent releases, probably due to improved optimizations. I would not be surprised if down

by gribbly 10y ago

Not sure how much is due to this, but LLVM has gotten much slower in recent releases, probably due to improved optimizations. I would not be surprised if down the line, the Rust devs decided to write their own Rust backend rather than relying on LLVM.

qznc 10y ago
At least for development a custom fast backend would be great. For production code you still want all the optimizations you can get, which means LLVM.
wyldfire 10y ago
Writing different backends for each supported target would either be taking on a lot of work or shedding some targets.
- coldtea 10y ago
  >Writing different backends for each supported target would either be taking on a lot of work or shedding some targets. Do any non statistical outliers care about non amd64 and ARM?
  - soulbadguy 10y ago
    OpenPower,xeon phi for one; Even within the amd64 and arm families, there are enough variations (AArch vs qualcomm) and evolutions (SSE3 to SSE4) to make the task of developing a new and performant backend from scratch very resource consuming Also while taken individually most of the non amd64/arm platforms might not be significant, combine together they still represent a big share of the pie, doubly more so in the embedded world which rust (tries?) to target.
    - coldtea 10y ago
      Xeon yeah, haven't thought of that. For OpenPower, let IBM do it :)
  - bzbarsky 10y ago
    For a browser? 1/3 or more of desktop Windows users are on 32-bit Windows, last I checked. So you definitely care at least about ix86 of some form.
    - wyldfire 10y ago
      What's a browser got to do with it?
      - coldtea 10y ago
        I guess the parent thinks or implies that since Rust was created to help Mozilla build a next-gen rendering engine, platforms with browsers is the only domain they care about supporting.
        Manishearth 10y ago
        > platforms with browsers is the only domain they care about supporting. What? No. It means that platforms with browsers are part of the domain Rust cares about supporting. Not the only domain. You asked for non-outliers, bz gave an example of browsers. There's plenty of work to make Rust work on embedded platforms where no browsers operate, and some of this is being done by Rust contributors employed by Mozilla. No need to assume that Rust is only focused to the needs of browsers.
        bzbarsky 10y ago
        No, I mean that platforms with browsers are a domain that Rust _must_ support for the use case Mozilla is developing it for. That doesn't preclude desiring support for other platforms, but is a minimum bar.
      - bzbarsky 10y ago
        In the specific context of Rust, being able to build a browser is a large part of the point. That means supporting platforms where people use browsers.
  - klodolph 10y ago
    "Statistical outliers" are more important than their frequency suggests. Architecture lock-in shifts political power away from developers and to CPU vendors.
pjmlp 10y ago
That would be a good way for removing the C++ dependency on their toolchain, but it would take decades to achieve parity with the quality of LLVM optimisers and supported ISAs (which are a subset of gcc ones). C and C++ optimisers weren't that good in the 80 and 90's even against junior Assembly developers, the 40 years of compiler research in optimizing C and C++ code that made them what they are nowadays.
- 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.
geodel 10y ago
Very unlikely. Rust party line is optimization is critical, compile speed desirable.

by gribbly 10y ago

qznc 10y ago

At least for development a custom fast backend would be great. For production code you still want all the optimizations you can get, which means LLVM.

wyldfire 10y ago

Writing different backends for each supported target would either be taking on a lot of work or shedding some targets.

coldtea 10y ago
>Writing different backends for each supported target would either be taking on a lot of work or shedding some targets. Do any non statistical outliers care about non amd64 and ARM?
- soulbadguy 10y ago
  OpenPower,xeon phi for one; Even within the amd64 and arm families, there are enough variations (AArch vs qualcomm) and evolutions (SSE3 to SSE4) to make the task of developing a new and performant backend from scratch very resource consuming Also while taken individually most of the non amd64/arm platforms might not be significant, combine together they still represent a big share of the pie, doubly more so in the embedded world which rust (tries?) to target.
  - coldtea 10y ago
    Xeon yeah, haven't thought of that. For OpenPower, let IBM do it :)
- bzbarsky 10y ago
  For a browser? 1/3 or more of desktop Windows users are on 32-bit Windows, last I checked. So you definitely care at least about ix86 of some form.
  - wyldfire 10y ago
    What's a browser got to do with it?
    - coldtea 10y ago
      I guess the parent thinks or implies that since Rust was created to help Mozilla build a next-gen rendering engine, platforms with browsers is the only domain they care about supporting.
      - Manishearth 10y ago
        > platforms with browsers is the only domain they care about supporting. What? No. It means that platforms with browsers are part of the domain Rust cares about supporting. Not the only domain. You asked for non-outliers, bz gave an example of browsers. There's plenty of work to make Rust work on embedded platforms where no browsers operate, and some of this is being done by Rust contributors employed by Mozilla. No need to assume that Rust is only focused to the needs of browsers.
      - bzbarsky 10y ago
        No, I mean that platforms with browsers are a domain that Rust _must_ support for the use case Mozilla is developing it for. That doesn't preclude desiring support for other platforms, but is a minimum bar.
    - bzbarsky 10y ago
      In the specific context of Rust, being able to build a browser is a large part of the point. That means supporting platforms where people use browsers.
- klodolph 10y ago
  "Statistical outliers" are more important than their frequency suggests. Architecture lock-in shifts political power away from developers and to CPU vendors.

pjmlp 10y ago

That would be a good way for removing the C++ dependency on their toolchain, but it would take decades to achieve parity with the quality of LLVM optimisers and supported ISAs (which are a subset of gcc ones). C and C++ optimisers weren't that good in the 80 and 90's even against junior Assembly developers, the 40 years of compiler research in optimizing C and C++ code that made them what they are nowadays.

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.

geodel 10y ago

Very unlikely. Rust party line is optimization is critical, compile speed desirable.