4 ms·

One thing I especially appreciate about Go that's a huge win over other statically compiled languages is how phenomenally fast the compiler is. E.g., I just re

by jbarham 15y ago

One thing I especially appreciate about Go that's a huge win over other statically compiled languages is how phenomenally fast the compiler is. E.g., I just re-built the current RC release on my 2.67 GHz i5, and the whole build, including the C bootstrap environment and 300k+ LOC in the standard library, took under 30 seconds. Recompiling my projects of a couple of thousand lines is instantaneous. It really makes you re-think the classic edit-compile-edit cycle since the compile time is negligible.

chimeracoder 15y ago
>how phenomenally fast the compiler is This, more than anything else, is what's really got me interested in trying out Go when I have some time! I know it's not the most important thing in the world - my projects are generally such that compile times aren't a huge time suck - but it's still an exciting thought nevertheless.
rudiger 15y ago
A fast compile time is one of the stated goals, is it not? I ask because this seems like the kind of thing that's hard to do correctly unless it's explicitly stated as a design goal.
- 4ad 15y ago
  Yes, the projects at Google in C++ or Java took an absurd amount of time to compile, even with distributed compiler farms.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
knotty66 15y ago
I think the D compiler (dmd) is faster still. Granted, this is a couple of years old, but DMD was capable of compiling 340,000 lines of code in less than 7 seconds. http://www.digitalmars.com/d/archives/digitalmars/D/D_compilation_speed_vs._go_108831.html http://www.digitalmars.com/d/archives/digitalmars/D/D_compil...
beza1e1 15y ago
I wonder why people are so impressed by the compile times. Why it is fast, is obvious: 1. Do not use #include (especially in combination with C++ template instantiation) 2. Do not use a heavily optimizing compiler backend The first point is fixed in every other modern language as well, so it is only an advantage over C/C++. Go will become somewhat slower, because people want free lunch, so at some point i expect LLVM or GCC will be used as the official backend. Does anybody use TinyCC for his C programs?
- gillianseed 15y ago
  Well it's true that the Go compiler isn't comparable to GCC in terms of optimization but it's still quite new and is likely to improve quite a bit. As for Go supporting other compiler backends that's already happening with GccGo which is a Go frontend for GCC and yes it does generate much faster code than the official compiler (although it still lacks some key features last time I checked). I don't think we'll see GCC (or LLVM) as the official backend though, as they've stated that the reason they decided to do the whole compiler from scratch was that both gcc and llvm backends were considered too large and slow.
  - enneff 15y ago
    > although [gccgo] lacks some key features last time I checked Not anymore. Gccgo is "Go 1 complete" and will be supported as part of Go 1. You can even use the "go" tool with gccgo.
    - gillianseed 15y ago
      Thanks for the info, that's very nice. I can see this opening up a workflow where you develop against the standard compiler and then use GccGo for better performing final builds.
- 4ad 15y ago
  You are mistaken about #2, optimization pass is not very relevant in total build time, even for compilers that spend a relatively long time in the optimization pass. Go build times are fast because 1) the grammar is not ambiguous to yacc yielding an O(n) parser that doesn't require maintaining a symbol table, 2) Dependency resolution is handled in an unique way, objects pull their dependencies so if A depends on B, C depends on A, and D depends on C and B, D doesn't need to look for B, since C contains A, B, and C. This doesn't seem like much, but it is, build times scale linearly with the number of objects instead of O(n^2). The gc suite doesn't produce code as tight as gcc, but almost no code in the world is CPU bound, everything is I/O bound.
pjmlp 15y ago
This is just marketing. Any language with modules is equally fast, only languages the use the C #includes mechanism are slow, because each #include needs to be imported and processed each time it is seen. Turbo Pascal, Modula and Ada compilers were already running circles around C compilers back in the day.
- 4ad 15y ago
  It's absurd to claim it's marketing since in this exact thread people state they care about this things and appreciate the feature, a feature that can be quantitatively tested. Btw, The Plan 9 C compilers, which are also included with the Go distribution, also compile C as fast as the Go compiler compiles Go. Both compilers were written by Ken Thompson.
  - pjmlp 15y ago
    It is marketing, because it is sold as Go was the first language to have such fast implementations, which is not the case, but many refer to Go as if it was the first language having such a feature.
    - 4ad 15y ago
      Nobody ever claimed Go was the first language with a fast compiler, it was simply claimed that it builds much faster than C++ and Java. There are compilers faster than the Go compilers in terms of lines compiled per second. Even Python parses code faster than the Go compiler, however, Go builds large, real life projects, faster because it is the only implementation that scales linearly with the number of components, other scale O(n^2) Turbo Pascal, Modula, and Ada, which you bring into discussion may have had fast compilers, but the build process was still O(n^2), not O(n).
      - pjmlp 15y ago
        Numbers please

by jbarham 15y ago

chimeracoder 15y ago

>how phenomenally fast the compiler is This, more than anything else, is what's really got me interested in trying out Go when I have some time! I know it's not the most important thing in the world - my projects are generally such that compile times aren't a huge time suck - but it's still an exciting thought nevertheless.

rudiger 15y ago

A fast compile time is one of the stated goals, is it not? I ask because this seems like the kind of thing that's hard to do correctly unless it's explicitly stated as a design goal.

4ad 15y ago
Yes, the projects at Google in C++ or Java took an absurd amount of time to compile, even with distributed compiler farms.

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

knotty66 15y ago

I think the D compiler (dmd) is faster still. Granted, this is a couple of years old, but DMD was capable of compiling 340,000 lines of code in less than 7 seconds. http://www.digitalmars.com/d/archives/digitalmars/D/D_compilation_speed_vs._go_108831.html http://www.digitalmars.com/d/archives/digitalmars/D/D_compil...

beza1e1 15y ago

I wonder why people are so impressed by the compile times. Why it is fast, is obvious: 1. Do not use #include (especially in combination with C++ template instantiation) 2. Do not use a heavily optimizing compiler backend The first point is fixed in every other modern language as well, so it is only an advantage over C/C++. Go will become somewhat slower, because people want free lunch, so at some point i expect LLVM or GCC will be used as the official backend. Does anybody use TinyCC for his C programs?

gillianseed 15y ago
Well it's true that the Go compiler isn't comparable to GCC in terms of optimization but it's still quite new and is likely to improve quite a bit. As for Go supporting other compiler backends that's already happening with GccGo which is a Go frontend for GCC and yes it does generate much faster code than the official compiler (although it still lacks some key features last time I checked). I don't think we'll see GCC (or LLVM) as the official backend though, as they've stated that the reason they decided to do the whole compiler from scratch was that both gcc and llvm backends were considered too large and slow.
- enneff 15y ago
  > although [gccgo] lacks some key features last time I checked Not anymore. Gccgo is "Go 1 complete" and will be supported as part of Go 1. You can even use the "go" tool with gccgo.
  - gillianseed 15y ago
    Thanks for the info, that's very nice. I can see this opening up a workflow where you develop against the standard compiler and then use GccGo for better performing final builds.
4ad 15y ago
You are mistaken about #2, optimization pass is not very relevant in total build time, even for compilers that spend a relatively long time in the optimization pass. Go build times are fast because 1) the grammar is not ambiguous to yacc yielding an O(n) parser that doesn't require maintaining a symbol table, 2) Dependency resolution is handled in an unique way, objects pull their dependencies so if A depends on B, C depends on A, and D depends on C and B, D doesn't need to look for B, since C contains A, B, and C. This doesn't seem like much, but it is, build times scale linearly with the number of objects instead of O(n^2). The gc suite doesn't produce code as tight as gcc, but almost no code in the world is CPU bound, everything is I/O bound.

pjmlp 15y ago

This is just marketing. Any language with modules is equally fast, only languages the use the C #includes mechanism are slow, because each #include needs to be imported and processed each time it is seen. Turbo Pascal, Modula and Ada compilers were already running circles around C compilers back in the day.

4ad 15y ago
It's absurd to claim it's marketing since in this exact thread people state they care about this things and appreciate the feature, a feature that can be quantitatively tested. Btw, The Plan 9 C compilers, which are also included with the Go distribution, also compile C as fast as the Go compiler compiles Go. Both compilers were written by Ken Thompson.
- pjmlp 15y ago
  It is marketing, because it is sold as Go was the first language to have such fast implementations, which is not the case, but many refer to Go as if it was the first language having such a feature.
  - 4ad 15y ago
    Nobody ever claimed Go was the first language with a fast compiler, it was simply claimed that it builds much faster than C++ and Java. There are compilers faster than the Go compilers in terms of lines compiled per second. Even Python parses code faster than the Go compiler, however, Go builds large, real life projects, faster because it is the only implementation that scales linearly with the number of components, other scale O(n^2) Turbo Pascal, Modula, and Ada, which you bring into discussion may have had fast compilers, but the build process was still O(n^2), not O(n).
    - pjmlp 15y ago
      Numbers please