4 ms·

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 com

by 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.
- dilap 11y ago
  I appreciate the detailed replies! I guess complex is an ambiguous word. Let's just agree that template-heavy "modern" C++ needs more optimizations turned on to get decent performance. So more optimizations => longer compiler times. (Not to even mention all of the parsing the headers multiple times, plus generating multiple versions of the code for all of the various type specializations!) From the other replies, I feel like there's more to it than just optimizations though -- but as just a compiler-user, not a compiler-writer, I'm out of my depth and just reading tea leaves. :) Reading those tea leaves, I'll be sadly surprised if the Go compiler ends up slow and happily surprised if a C++ compiler ever ends up as fast. (I don't know enough about Rust to make any predictions. ;) (PS. No disagreement that C++ has a higher performance ceiling than Go; of course hand-rolled asm still goes higher than that (ever tried running x264 w/o the assembly bits? it's painfully slow).)
sievebrain 11y ago
Is the story that Go, as a simpler language, is able to compile to decently fast code w/ fewer compiler optimizations? Sort of. But it's also that you're making bad comparisons. C++ has an include based compilation model and heavy reliance on template specialisation that means it'll never be fast. What you should instead be comparing it to is Java, which is also a simple language, only slightly more complex than Go. However, that comparison is rarely made, because it'd show that compiling fast is not so special a trick ... Java also compiles extremely fast at every level, that's why it's possible to use a JIT compiler with it at all. Given that "compiles fast" is Go's number one claim to fame, the reluctance to compare to the most popular compiled language is the elephant in the room.
- nickpsecurity 11y ago
  What did it take to fo that in Java? When I tried Java on a Pent3, it took a few seconds to compile. The BASIC and Wirth languages could do tens of thousands of lines a second on same machine. Then they consistently ran faster than Java. The only elephant in the room is the bloated, insecure platform sitting on many servers. Competition showed one could do much more with less CPU, memory, or money invested in tooling itself.
  - pcwalton 11y ago
    HotSpot's sea of nodes IR is far beyond anything Turbo Pascal did in terms of balancing compile time and runtime. It's not even comparable. Few people are as consistently right in their field as Cliff Click is with JITs and language runtimes.
    - nickpsecurity 11y ago
      Dude is brillaint and did great work. Yet, the Oberons and Pascals compiled so fast my finger was barely off the key when they were done. Even the C/C++ editors werent that fast for Java. Allowed rapid iteration while maintaining mental flow. When done, you turn all the options on with that or a slower compiler to get fastest, production version. This has been true going back to the old, Ceres workstations where commenters here that used them reported instant compiles on CPU's with tens of MHz.
dgacmu 11y ago
Go wins at compile time in part because its import system avoids a ton of the redundant work that C++ includes bring with them. So, yes, go would compile lot faster than C+l -O0, but that's a language difference, not a compiler difference.

by dilap 11y ago

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.

dilap 11y ago
I appreciate the detailed replies! I guess complex is an ambiguous word. Let's just agree that template-heavy "modern" C++ needs more optimizations turned on to get decent performance. So more optimizations => longer compiler times. (Not to even mention all of the parsing the headers multiple times, plus generating multiple versions of the code for all of the various type specializations!) From the other replies, I feel like there's more to it than just optimizations though -- but as just a compiler-user, not a compiler-writer, I'm out of my depth and just reading tea leaves. :) Reading those tea leaves, I'll be sadly surprised if the Go compiler ends up slow and happily surprised if a C++ compiler ever ends up as fast. (I don't know enough about Rust to make any predictions. ;) (PS. No disagreement that C++ has a higher performance ceiling than Go; of course hand-rolled asm still goes higher than that (ever tried running x264 w/o the assembly bits? it's painfully slow).)

sievebrain 11y ago

Is the story that Go, as a simpler language, is able to compile to decently fast code w/ fewer compiler optimizations? Sort of. But it's also that you're making bad comparisons. C++ has an include based compilation model and heavy reliance on template specialisation that means it'll never be fast. What you should instead be comparing it to is Java, which is also a simple language, only slightly more complex than Go. However, that comparison is rarely made, because it'd show that compiling fast is not so special a trick ... Java also compiles extremely fast at every level, that's why it's possible to use a JIT compiler with it at all. Given that "compiles fast" is Go's number one claim to fame, the reluctance to compare to the most popular compiled language is the elephant in the room.

nickpsecurity 11y ago
What did it take to fo that in Java? When I tried Java on a Pent3, it took a few seconds to compile. The BASIC and Wirth languages could do tens of thousands of lines a second on same machine. Then they consistently ran faster than Java. The only elephant in the room is the bloated, insecure platform sitting on many servers. Competition showed one could do much more with less CPU, memory, or money invested in tooling itself.
- pcwalton 11y ago
  HotSpot's sea of nodes IR is far beyond anything Turbo Pascal did in terms of balancing compile time and runtime. It's not even comparable. Few people are as consistently right in their field as Cliff Click is with JITs and language runtimes.
  - nickpsecurity 11y ago
    Dude is brillaint and did great work. Yet, the Oberons and Pascals compiled so fast my finger was barely off the key when they were done. Even the C/C++ editors werent that fast for Java. Allowed rapid iteration while maintaining mental flow. When done, you turn all the options on with that or a slower compiler to get fastest, production version. This has been true going back to the old, Ceres workstations where commenters here that used them reported instant compiles on CPU's with tens of MHz.

dgacmu 11y ago

Go wins at compile time in part because its import system avoids a ton of the redundant work that C++ includes bring with them. So, yes, go would compile lot faster than C+l -O0, but that's a language difference, not a compiler difference.