4 ms·

It’s not really that go is better designed for fast compilation - it is just a plain language where the compiler can just spit out vaguely optimized code, and c

by kaba0 3y ago

It’s not really that go is better designed for fast compilation - it is just a plain language where the compiler can just spit out vaguely optimized code, and call it a day. Rust’s unique feature itself fundamentally depends on extensive static analysis. It’s not a design choice, it is pretty much what Rust is - a low-level language without a GC that is still memory safe. The price for that is hefty compile times.

mirashii 3y ago
Profiling the compilation process suggests that this isn't the case. Rust's higher level passes are rarely the dominant part of execution time. Check out https://github.com/lqd/rustc-benchmarking-data/tree/main/results/round-16-self-profile-opt/flamegraph https://github.com/lqd/rustc-benchmarking-data/tree/main/res... and the other benchmarks in that repository for some data on how real world crates compilation times are spent. You'll find that backend code generation and optimization dominate most crates compile times. There are a few exceptions: particularly macro heavy crates, a couple crates with deeply nested types that hit some quadratic behavior in the compiler. But overall, the backend is still the largest piece.
- kaba0 3y ago
  Then there is an open niche for a “development mode”, that outputs barely optimized binaries with proper error handling, fast. (I do know about debug, etc). I think Zig is correct in having different modes.
  - littlestymaar 3y ago
    It already exists: It's called “debug” mode and it's what you get when you don't compile it in release mode. (The biggest problem with debug mode is how slow the unoptimized code is: for back-end stuff it doesn't matter, but for things like gamedev you want your dependencies to be compiled in release mode (fortunately the cargo allows you to specify that you want some deps to be compiled in release mode even when your project is compiled in debug mode).
  - insanitybit 3y ago
    That is what Cranelift is optimizing for.
- rayiner 3y ago
  The front end is time-consuming enough where replacing the backend with something lightweight like Go’s wouldn’t get you a 5-10x improvement, which is what I think you’d need to really move the needle on user perception. Moreover, a lot of the backend slowdown is due to front end choices monomophization which generates large amounts of intermediate code that must then be optimized away.
  - pcwalton 3y ago
    I doubt that a hypothetical version of Rust that avoided monomorphization would compile any faster. I remember doing experiments to that effect in the early days and found that monomorphization wasn't really slower. That's because all the runtime bookkeeping necessary to operate on value types generically adds up to a ton of code that has to be optimized away, and it ends up a wash in the end. As a point of comparison, Swift does all this bookkeeping, and it's not appreciably faster to compile than Rust; Swift goes this route for ABI stability reasons, not for compiler performance. What you would need to go faster would be not only a non-monomorphizing compiler but also boxed types. That would be a very different language, one higher-level than even Go (which monomorphizes generics).
    - mirashii 3y ago
      Just wanted to note Go does only a partial monomorphization, only monomorhpizes for gcshapes and not for all types. This severely limits the optimization potential and adds a runtime cost to dispatch, at least in its initial implementation. https://github.com/golang/proposal/blob/master/design/generics-implementation-dictionaries-go1.18.md https://github.com/golang/proposal/blob/master/design/generi...
zeroxfe 3y ago
> It’s not really that go is better designed for fast compilation One of the explicit goals, by Go's creators, was fast build times. I still remember Rob Pike introducing Go during an all-hands at Google, where he talked about the very long build times for C++ and Java in Google's monorepo, and then showed some promising demos. (Most of us rolled our eyes at it then, because it was just a "hello world", but it's quite impressive how the language has evolved and remained true to its goals.) > - it is just a plain language where the compiler can just spit out vaguely optimized code, and call it a day. It's a simple language, but I wouldn't call it plain, nor characterize the optimizers that way.
- kaba0 3y ago
  It is not faster at compilation than Java, which was not particularly designed for such. Also, as can be seen, go is not a well-designed language, having language warts we knew for 50 years. I would take the creators’ claims with a huge grain of salt.
  - mariusor 3y ago
    [flagged]
    - kaba0 3y ago
      So which of my statements do you take issue with? I do think highly of Rob Pike and Ken Thompson for their IT work, but they are simply not good at language design, which just shows that PL design is quite unlike working on an OS.
      - mariusor 3y ago
        Both statements, because unless otherwise qualified you're comparing apples to oranges when you say Java compiles as fast as Go. There's always going to be more overhead on running the Java bytecode on the JVM than there will be when running the native instructions generated by a compiler (even as "unoptimized" as Go is). And someone that makes that assertion with a straight face without this caveat is not someone that should be dissing Rob Pike about language design.

by kaba0 3y ago

mirashii 3y ago

Profiling the compilation process suggests that this isn't the case. Rust's higher level passes are rarely the dominant part of execution time. Check out https://github.com/lqd/rustc-benchmarking-data/tree/main/results/round-16-self-profile-opt/flamegraph https://github.com/lqd/rustc-benchmarking-data/tree/main/res... and the other benchmarks in that repository for some data on how real world crates compilation times are spent. You'll find that backend code generation and optimization dominate most crates compile times. There are a few exceptions: particularly macro heavy crates, a couple crates with deeply nested types that hit some quadratic behavior in the compiler. But overall, the backend is still the largest piece.

kaba0 3y ago
Then there is an open niche for a “development mode”, that outputs barely optimized binaries with proper error handling, fast. (I do know about debug, etc). I think Zig is correct in having different modes.
- littlestymaar 3y ago
  It already exists: It's called “debug” mode and it's what you get when you don't compile it in release mode. (The biggest problem with debug mode is how slow the unoptimized code is: for back-end stuff it doesn't matter, but for things like gamedev you want your dependencies to be compiled in release mode (fortunately the cargo allows you to specify that you want some deps to be compiled in release mode even when your project is compiled in debug mode).
- insanitybit 3y ago
  That is what Cranelift is optimizing for.
rayiner 3y ago
The front end is time-consuming enough where replacing the backend with something lightweight like Go’s wouldn’t get you a 5-10x improvement, which is what I think you’d need to really move the needle on user perception. Moreover, a lot of the backend slowdown is due to front end choices monomophization which generates large amounts of intermediate code that must then be optimized away.
- pcwalton 3y ago
  I doubt that a hypothetical version of Rust that avoided monomorphization would compile any faster. I remember doing experiments to that effect in the early days and found that monomorphization wasn't really slower. That's because all the runtime bookkeeping necessary to operate on value types generically adds up to a ton of code that has to be optimized away, and it ends up a wash in the end. As a point of comparison, Swift does all this bookkeeping, and it's not appreciably faster to compile than Rust; Swift goes this route for ABI stability reasons, not for compiler performance. What you would need to go faster would be not only a non-monomorphizing compiler but also boxed types. That would be a very different language, one higher-level than even Go (which monomorphizes generics).
  - mirashii 3y ago
    Just wanted to note Go does only a partial monomorphization, only monomorhpizes for gcshapes and not for all types. This severely limits the optimization potential and adds a runtime cost to dispatch, at least in its initial implementation. https://github.com/golang/proposal/blob/master/design/generics-implementation-dictionaries-go1.18.md https://github.com/golang/proposal/blob/master/design/generi...

zeroxfe 3y ago

> It’s not really that go is better designed for fast compilation One of the explicit goals, by Go's creators, was fast build times. I still remember Rob Pike introducing Go during an all-hands at Google, where he talked about the very long build times for C++ and Java in Google's monorepo, and then showed some promising demos. (Most of us rolled our eyes at it then, because it was just a "hello world", but it's quite impressive how the language has evolved and remained true to its goals.) > - it is just a plain language where the compiler can just spit out vaguely optimized code, and call it a day. It's a simple language, but I wouldn't call it plain, nor characterize the optimizers that way.

kaba0 3y ago
It is not faster at compilation than Java, which was not particularly designed for such. Also, as can be seen, go is not a well-designed language, having language warts we knew for 50 years. I would take the creators’ claims with a huge grain of salt.
- mariusor 3y ago
  [flagged]
  - kaba0 3y ago
    So which of my statements do you take issue with? I do think highly of Rob Pike and Ken Thompson for their IT work, but they are simply not good at language design, which just shows that PL design is quite unlike working on an OS.
    - mariusor 3y ago
      Both statements, because unless otherwise qualified you're comparing apples to oranges when you say Java compiles as fast as Go. There's always going to be more overhead on running the Java bytecode on the JVM than there will be when running the native instructions generated by a compiler (even as "unoptimized" as Go is). And someone that makes that assertion with a straight face without this caveat is not someone that should be dissing Rob Pike about language design.