4 ms·

You say it is arrogant but is it untrue? Rust uses LLVM backend and it takes order of magnitude longer to compile compare to Go.

by geodel 11y ago

DannyBee 11y ago
It is untrue, given the same amount of work put into both (IE if they had spent their time doing llvm instead of their own ssa backend). Remember the SSA backend of Go was slower than the normal go compiler for the vast majority of it's life as well. In any case, people like to build shiny new things they think they can do better at, instead of fixing things that are, in actuality, probably better for what they want but need a little work. The truth is that there is no magic in building good compilers, so it's not like anyone comes along, waves a wand, and produces a compiler that is X times faster or better than anyone else's. I can think of a lot of good reasons to write their compiler in go, and not use LLVM. Technical reasons are ... not any of them :)
- geodel 11y ago
  > Remember the SSA backend of Go was slower than the normal go compiler for the vast majority of it's life as well. Go 1.7 in August will be first release with SSA backend. So I do not understand what is that vast majority of life besides development phase of 1 year or so. > In any case, people like to build shiny new things they think they can do better at, instead of fixing things that are, in actuality, probably better for what they want but need a little work. I agree with that. It could just be a comment on our society. > I can think of a lot of good reasons to write their compiler in go, and not use LLVM. Technical reasons are ... not any of them :) I think goroutine and segmented stacks support was mentioned as technical reason.
pcwalton 11y ago
The reasons why Rust is slower to compile are basically (a) typechecking takes longer; (b) LLVM does way way more optimization than Go's backend does. (b) applies even at -O0 because it has to go through LLVM IR to SelectionDAG to MachineInstrs, while Go 6g/8g pre-SSA can just go from AST to MachineInstrs. (We can't use FastISel at the moment because FastISel has no support for unwinding, among other minor reasons.) If Go adds all the optimizations that LLVM does, then I have no reason to believe that it won't end up just as slow as LLVM. There's active work to fix both (a) and (b): for (a) there are ideas for an O(1) unifier in typechecking, and for (b) we're working on MIR (which is now able to self-host) to do higher-level optimizations on a language-specific IR to avoid punting them to LLVM, where it may take more work to figure out. (For instance, we can do inlining on polymorphic functions, reducing the time complexity from O(number of instantiations) to O(1).) But the biggest wins will come from incremental compilation, which there's been a ton of progress on lately and might just fix the compilation time issues once and for all in practice.
- dilap 11y ago
  Well, Go still won't be paying for (a) right? So my non-expert, just-a-normal-programmer feeling is something still doesn't add up -- I feel like you could compile C++ with optimizations off, and it would still lose at compile time, and really lose at runtime, to Go. So somehow Go is compiling quickly and running fastishly. So "it doesn't do optimization is why it compiles fast" is confusing. Is the story that Go, as a simpler language, is able to compile to decently fast code w/ fewer compiler optimizations? I'm thinking along the lines of C++ zero-runtime-overhead template stuff is very-large-overhead w/o optimizations. I've only played a tiny bit with Rust, and it was a long time ago, but my experience is there was no "fast compile time, decent runtime" configuration available. Naturally, that's a really good configuration to have accessible if possible!
  - pcwalton 11y ago
    Yes, C++ is dependent on optimizations. It's not that C++ is a complex language and that Go is a simple language, though--in fact, due to GC metadata Go is on the whole probably more complex than C++ once you get to the LLVM IR level. C++ (like Rust) is runtimeless and has no data structures built-in, so every time you use a hash table (for example) the implementation of the hash table is compiled alongside your code. In Go, hash table operations compile to opaque runtime calls (I believe), to a runtime that is always optimized. This is faster for compile time, but it's slower for runtime, frequently much slower because containers benefit heavily from IPO. (For instance, SROA and inlining are a powerful combination, allowing for the length of a short-lived array to be promoted to an SSA register and thereby allowing vectorization, etc.) Go's compiler is not competitive with a mature backend like GCC or LLVM. It's "fastish" for the niche it's in, but there's no substitute for the nonstop 10+ years of optimization work that has gone into the flagship open source compilers. I don't see LICM in Go's source at all, for instance, and that's a really basic one. > I've only played a tiny bit with Rust, and it was a long time ago, but my experience is there was no "fast compile time, decent runtime" configuration available. Naturally, that's a really good configuration to have accessible if possible! There is -O1, but it has basically the same compile time as -O2, so it's not used in practice.

You say it is arrogant but is it untrue? Rust uses LLVM backend and it takes order of magnitude longer to compile compare to Go.

by geodel 11y ago

You say it is arrogant but is it untrue? Rust uses LLVM backend and it takes order of magnitude longer to compile compare to Go.

DannyBee 11y ago

It is untrue, given the same amount of work put into both (IE if they had spent their time doing llvm instead of their own ssa backend). Remember the SSA backend of Go was slower than the normal go compiler for the vast majority of it's life as well. In any case, people like to build shiny new things they think they can do better at, instead of fixing things that are, in actuality, probably better for what they want but need a little work. The truth is that there is no magic in building good compilers, so it's not like anyone comes along, waves a wand, and produces a compiler that is X times faster or better than anyone else's. I can think of a lot of good reasons to write their compiler in go, and not use LLVM. Technical reasons are ... not any of them :)

geodel 11y ago
> Remember the SSA backend of Go was slower than the normal go compiler for the vast majority of it's life as well. Go 1.7 in August will be first release with SSA backend. So I do not understand what is that vast majority of life besides development phase of 1 year or so. > In any case, people like to build shiny new things they think they can do better at, instead of fixing things that are, in actuality, probably better for what they want but need a little work. I agree with that. It could just be a comment on our society. > I can think of a lot of good reasons to write their compiler in go, and not use LLVM. Technical reasons are ... not any of them :) I think goroutine and segmented stacks support was mentioned as technical reason.

pcwalton 11y ago

The reasons why Rust is slower to compile are basically (a) typechecking takes longer; (b) LLVM does way way more optimization than Go's backend does. (b) applies even at -O0 because it has to go through LLVM IR to SelectionDAG to MachineInstrs, while Go 6g/8g pre-SSA can just go from AST to MachineInstrs. (We can't use FastISel at the moment because FastISel has no support for unwinding, among other minor reasons.) If Go adds all the optimizations that LLVM does, then I have no reason to believe that it won't end up just as slow as LLVM. There's active work to fix both (a) and (b): for (a) there are ideas for an O(1) unifier in typechecking, and for (b) we're working on MIR (which is now able to self-host) to do higher-level optimizations on a language-specific IR to avoid punting them to LLVM, where it may take more work to figure out. (For instance, we can do inlining on polymorphic functions, reducing the time complexity from O(number of instantiations) to O(1).) But the biggest wins will come from incremental compilation, which there's been a ton of progress on lately and might just fix the compilation time issues once and for all in practice.

dilap 11y ago
Well, Go still won't be paying for (a) right? So my non-expert, just-a-normal-programmer feeling is something still doesn't add up -- I feel like you could compile C++ with optimizations off, and it would still lose at compile time, and really lose at runtime, to Go. So somehow Go is compiling quickly and running fastishly. So "it doesn't do optimization is why it compiles fast" is confusing. Is the story that Go, as a simpler language, is able to compile to decently fast code w/ fewer compiler optimizations? I'm thinking along the lines of C++ zero-runtime-overhead template stuff is very-large-overhead w/o optimizations. I've only played a tiny bit with Rust, and it was a long time ago, but my experience is there was no "fast compile time, decent runtime" configuration available. Naturally, that's a really good configuration to have accessible if possible!
- pcwalton 11y ago
  Yes, C++ is dependent on optimizations. It's not that C++ is a complex language and that Go is a simple language, though--in fact, due to GC metadata Go is on the whole probably more complex than C++ once you get to the LLVM IR level. C++ (like Rust) is runtimeless and has no data structures built-in, so every time you use a hash table (for example) the implementation of the hash table is compiled alongside your code. In Go, hash table operations compile to opaque runtime calls (I believe), to a runtime that is always optimized. This is faster for compile time, but it's slower for runtime, frequently much slower because containers benefit heavily from IPO. (For instance, SROA and inlining are a powerful combination, allowing for the length of a short-lived array to be promoted to an SSA register and thereby allowing vectorization, etc.) Go's compiler is not competitive with a mature backend like GCC or LLVM. It's "fastish" for the niche it's in, but there's no substitute for the nonstop 10+ years of optimization work that has gone into the flagship open source compilers. I don't see LICM in Go's source at all, for instance, and that's a really basic one. > I've only played a tiny bit with Rust, and it was a long time ago, but my experience is there was no "fast compile time, decent runtime" configuration available. Naturally, that's a really good configuration to have accessible if possible! There is -O1, but it has basically the same compile time as -O2, so it's not used in practice.