4 ms·
If I remember properly, when Go was first developed, compilation time was one of the primary metric that Rob Pike et al were optimizing for, and drove major asp
by legutierr 11y ago
If I remember properly, when Go was first developed, compilation time was one of the primary metric that Rob Pike et al were optimizing for, and drove major aspects of its design. It shouldn't be surprising that Go blows other systems out of the water in this regard.
Here he is talking about it:
https://www.youtube.com/watch?v=rKnDgT73v8s#t=8m53 https://www.youtube.com/watch?v=rKnDgT73v8s#t=8m53
- pcwalton 11y agoMy point is that you pay a price for this: LLVM's optimization passes are much, much more sophisticated than those of the Plan 9 toolchain. In optimized builds of Rust, the LLVM optimization and compilation time tends to dominate, so having a simpler type system wouldn't really help. You could have a more C-like language that isn't so dependent on expensive optimization passes like multi-level inlining and SROA, granted, but I think most any high-level language—i.e. one that isn't a bare-metal language like C and Pascal—is going to have lots of opportunity for expensive optimizations.
- tormeh 11y agoIf optimization is the problem, then compilation at Go speed should be possible with -O0.
- DasIch 11y agoJust having the ability to perform such optimizations requires an architecture that is sure to have some overhead no matter which optimizations, if any, are actually executed.
- Jweb_Guru 11y agoRust could still have a toolchain like DMD devoted to fast compilation with minimal optimization. It just doesn't, yet (and likely won't for quite some time, since the present advantages of having a single toolchain are fairly significant and Rust doesn't have a formal specification yet).
- steveklabnik 11y agoMultirust makes working with multiple toolchains on *NIX pretty great, but no formal spec can be a pain. Ruby doesn't have a spec, yet has multiple implementations, so it's not the _end_ of the world...
- pcwalton 11y agoThere are C compilers out there that work like this (like, say, the Plan 9 C compiler) and they rarely ever get used in practice, because GCC and clang -O0 are fast enough. I think making a second compiler backend just to eliminate the IR generation step isn't going to be the solution we want in the long run.
- andrewchambers 11y agoI think they are only fast enough because developers have not been exposed to better. In general, I would like to see more aggressive build modes for CI servers, and less aggressive modes for dev.
- tarblog 11y agoAlso, I'm confused by the word "aggressive" here. Could you elaborate please?
- andrewchambers 11y agoAggressive optimization. I just mean on a build server time isn't as much of a factor as local development.
- pjmlp 11y ago> It shouldn't be surprising that Go blows other systems out of the water in this regard. For any developer that never used Turbo Pascal, Modula-2, Oberon compilers, just to cite a few examples among many possible ones. Those that did, can not comprehend why companies invested in languages like C and C++, which created this notion all compilers should be slow.
- insulanian 11y agoOh yes, Turbo Pascal (and even Delphi / Object Pascal) had a really fast compiler. Sigh... those were the days...